Bóvedas de Obsidian

Obsidian lee Markdown plano, así que una exportación por defecto ya se abre en una bóveda. Hay tres construcciones que se resuelven de forma distinta allí que en GitHub — los paneles, los anclajes de encabezado y las imágenes — y --obsidian cambia las tres a la vez.

acs2md space convert by-key DEVOPS --output-dir ~/vault --obsidian --inline-tags

Apunta una bóveda a ~/vault y la exportación se comporta como notas escritas a mano.

Qué establece el preajuste

Es un preajuste, no un candado: una opción explícita siempre gana.

# Conserva las imágenes en base64, pero aplica el resto del preajuste
acs2md space convert by-key DEVOPS --output-dir ~/vault --obsidian --image-sidecars=false
 
# Conserva las citas con emoji en lugar de los callouts
acs2md space convert by-key DEVOPS --output-dir ~/vault --obsidian --panel-style=emoji

El preajuste también linealiza las secciones de diseño multicolumna de Confluence a Markdown secuencial en lugar de una tabla HTML. Obsidian no interpreta el Markdown que hay dentro de un bloque HTML sin procesar, de modo que una columna con encabezados o enlaces mostraría su código Markdown. Las columnas se apilan en vez de quedar una al lado de la otra: ese es el precio de que se rendericen.

Qué se renderiza

Todo lo siguiente es correcto en la bóveda exportada. Las filas con una opción la necesitan; el resto no necesita nada.

Imágenes

Este es el caso que parece un error de conversión en lugar de un ajuste.

Por defecto las imágenes se incrustan como URI de datos en base64. Eso es Markdown válido y se renderiza correctamente en GitHub y en VS Code. Pero una URI de datos coloca la imagen entera en una sola línea — una captura corriente de Confluence supera con creces los 100 KB de texto — y el Live Preview de Obsidian deja de aplicar decoraciones a las líneas que superan cierta longitud. El widget de imagen no llega a construirse, así que la nota muestra el código en bruto en lugar de la imagen:

![image-20240930-142031.png](data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…)

--obsidian, o --image-sidecars por su cuenta, escribe cada imagen en attachments/<page-id>/ junto a la página y la enlaza de forma relativa:

![image-20240930-142031.png](attachments/5814878215/image-20240930-142031.png)

Medido sobre una página real, convertida de las dos formas:

La exportación es autónoma en ambos casos: los bytes están en disco, no detrás de una URL de Confluence que exige credenciales. Lo que cambia es la longitud de línea. En todo un espacio además se deduplica: una captura reutilizada en diez páginas se guarda una vez en lugar de diez.

Los hrefs se codifican en porcentaje, de modo que un adjunto cuyo nombre contenga espacios o paréntesis sigue produciendo un enlace que funciona.

Las marcas de formato se eliminan por defecto

Ese valor por defecto encaja con las canalizaciones de RAG y de indexación para búsqueda, que es para lo que se eligió. Para una bóveda que van a leer personas, casi siempre es lo contrario de lo que quieres. Los enlaces y el código en línea se conservan siempre, en cualquier caso.

Para una bóveda de lectura:

acs2md space convert by-key DEVOPS --output-dir ~/vault \
  --obsidian \
  --inline-tags \
  --exclude-marks=false

Qué no obtiene Obsidian

Limitaciones honestas, ninguna de las cuales rompe el renderizado:

• Wikilinks entre notas más allá de las inline cards. [[Nota]] se genera para las inline cards internas mediante --wikilinks; los enlaces normales pasan a ser rutas Markdown relativas con --rewrite-links. Ambos navegan y ambos alimentan el grafo.
• Embeds. No se emite la transclusión ![[archivo]].
• Resaltado nativo. No se genera ==texto==. El color de fondo de Confluence se renderiza como <span style>, que Obsidian muestra como HTML.

Resolución de problemas

Consulta también

• Convertir espacios — todas las opciones que acepta space convert
• Sincronización e incremental — cómo mantener una bóveda al día sin reconvertirlo todo
• Extensiones y macros — qué macros de Confluence sobreviven a la conversión