Obsidian в Word: полное руководство по экспорту на 2026 год

Если ты живёшь в Obsidian, проблема тебе уже знакома. Ты три месяца собирал исследовательскую заметку, набитую синтаксисом самого Obsidian — вещами вроде:

[[Project Plan]]        → link to another note
![[diagram.png]]        → embedded image
> [!note] Key insight   → callout block

А потом коллега просит версию в Word — и каждый из этих нестандартных элементов ломается.

Я столкнулся с этой проблемой в первый раз, когда нужно было передать техническое исследование на 40 страниц заказчику, который не собирался прикасаться к Obsidian. То, что в хранилище смотрелось аккуратно, в Word вывалилось кашей из литеральных квадратных скобок и пустых плейсхолдеров от картинок. После той конвертации и ещё нескольких с тех пор я выработал воркфлоу, который реально держится. Это руководство его документирует — шаг предобработки, который большинство пропускает, три особенности Obsidian, которые действительно важны, и что делать, когда картинки или выноски отказываются работать.

Почему Markdown из Obsidian непереносим (и что именно ломается)

Obsidian хранит заметки как обычные .md-файлы, и поэтому считается, что экспортировать в Word — дело тривиальное. Это не так — потому что Obsidian расширяет стандартный Markdown фичами, которые ни один универсальный конвертер не понимает.

Вот четыре расширения, из-за которых срывается почти каждый экспорт:

Стандартные Markdown-конвертеры — Pandoc, большинство онлайн-инструментов — воспринимают [[...]] как литеральный текст, а ![[...]] как непонятный токен. То, что ты видишь в Obsidian в отрендеренном виде, — это превью, а не исходник. Именно это различие лежит в корне почти всей боли в духе «почему у меня сломался экспорт».

Есть ещё более тонкий момент: пути к вложениям. Obsidian разрешает ![[image.png]], прошаривая хранилище в поисках подходящего файла, независимо от папки. Стандартному Markdown нужен явный относительный путь. Если твоё хранилище держит вложения в 99 Attachments/, а заметка живёт в 10 Projects/, ссылку на картинку придётся переписать, иначе ни один конвертер её не найдёт.

Перед экспортом: шаг предобработки, который тебя спасает

Самое большое улучшение надёжности в моём воркфлоу пришло из 5 минут предобработки до запуска любого конвертера. Пропусти этот шаг — и потом потратишь 30 минут на чистку Word-файла.

Шаг 1: проверь настройки вложений

Открой Settings → Files and links. Запомни два значения:

• Default location for new attachments — куда складываются новые картинки/PDF
• New link format — как Obsidian записывает пути (Shortest path when possible, Relative path to file или Absolute path in vault)

Если стоит Shortest path when possible (дефолт Obsidian), экспорт сломается для любой заметки, чьи вложения лежат не в той же папке. Перед экспортом переключи на Relative path to file. Эта настройка действует только вперёд — уже существующие ссылки сохраняют старый формат, пока их не перезапишут. Шаг 2 ниже занимается этой перезаписью.

Шаг 2: конвертируй wikilinks в стандартные Markdown-ссылки

У Obsidian есть встроенный переключатель для этого: Settings → Files and links → Use [[Wikilinks]] → OFF. Когда он выключен, новые ссылки пишутся как [Note Name](Note-Name.md). Но это касается только новых ссылок.

Чтобы переписать уже существующие [[wikilinks]] в заметке, есть два варианта:

1. Вручную, для небольших экспортов — Cmd/Ctrl+F в заметке, ищешь каждый [[ и переписываешь. Нормально для заметки на 5 страниц.
2. Community-плагин для крупных хранилищ — открой Settings → Community plugins и поищи термины вроде «link converter» или «markdown links». В экосистеме есть несколько плагинов, которые массово конвертируют wikilinks (и встроенные вложения ![[...]]) в стандартный синтаксис Markdown — либо в текущем файле, либо во всей папке. Выбирай тот, что обновлялся недавно и у которого счётчик установок внушает доверие.

После перезаписи встроенные вложения будут выглядеть как ![image.png](path/to/image.png). Проверь вывод — если в названии папки вложений есть пробелы, закодируй их URL-кодом (My%20Vault/attachment.png), иначе конвертер молча выбросит картинку.

Шаг 3: реши, что делать с выносками

Выноски Obsidian (> [!note], > [!warning] и т.д.) ценны внутри хранилища, но в Word эквивалента у них нет. Есть три варианта, в порядке возрастания трудозатрат:

• Смириться с понижением — они отрендерятся как обычные цитаты. Сам тип выноски (note/warning/tip) теряется, но содержимое остаётся. Для большинства передач заказчику — приемлемо.
• Переписать важные — заменить > [!warning] Critical на > **⚠️ Critical:** перед экспортом. Читаемо в обоих местах.
• Доработать в Word — превратить цитаты в оформленные блоки через Quick Styles Word. Оправданно только ради по-настоящему отполированных документов.

Я использую вариант 2 для всего, что меньше 20 страниц, и вариант 1 для всего остального.

Шаг 4: экспортируй Dataview-блоки как статический контент

Если в заметке есть Dataview-запросы, они экспортируются как код запроса, а не как таблица результатов. Перед экспортом запусти запрос в Obsidian, скопируй отрендеренный вывод и вставь его как статическую Markdown-таблицу вместо блока кода. Да, это вручную. Нет, чистого способа это обойти нет — Dataview рендерит на клиенте, поэтому исходный файл по-настоящему не содержит данных.

Четырёхшаговый воркфлоу экспорта

После предобработки сама конвертация уже простая.

1. Скопируй заметку (не экспортируй на месте)

Продублируй целевую заметку и её вложения во временную папку вне хранилища. Ты не хочешь, чтобы правки из предобработки (переписанные ссылки, замены выносок) загрязняли твоё основное хранилище. Я держу для этого на рабочем столе папку под названием _export-staging/.

2. Расплющи пути к вложениям

Перемести все картинки, на которые есть ссылки, в ту же папку, что и .md-файл, и обнови ссылки до простых имён файлов: ![diagram](diagram.png) вместо ![diagram](../../99 Attachments/diagram.png). Большинство конвертеров плохо справляется с путями, которые «поднимаются» по папкам.

3. Запусти конвертер

Загрузи подготовленный .md-файл в конвертер Markdown to Word от MarkFlow. Он поддерживает GitHub Flavored Markdown (GFM) — включая таблицы, чек-листы и сноски — а это покрывает каждую стандартную фичу, которую Obsidian отдаёт после предобработки. Картинки встраиваются инлайн, блоки кода сохраняют подсветку синтаксиса, а заголовки маппятся на стили заголовков Word, так что панель навигации в итоговом DOCX работает.

Если в заметке есть формулы LaTeX ($E=mc^2$ или $$...$$), убедись, что выбранный тобой конвертер сохраняет их как уравнения Word, а не сплющивает в простой текст. Для заметок, плотно набитых формулами — лабораторные журналы, академические черновики, — это решающая фича. Если Word не финальная цель и тебе просто нужен файл, которым можно поделиться, то конвертация Markdown в PDF полностью обходит капризы рендеринга уравнений в Word.

4. Доведи в Word

Открой DOCX и примени шаблон Word, если он у тебя есть. Стили заголовков из Markdown чисто ложатся на встроенные Заголовок 1/2/3 в Word, так что переоформить весь документ — это операция в один клик через Design → Document Formatting. Перед отправкой проверь три вещи:

• Оглавление — вставь его через References → Table of Contents, чтобы убедиться, что все заголовки подцепились правильно
• Размер картинок — Obsidian показывает картинки в естественном размере, Word может их раздуть. Выдели всё и измени размер, если нужно
• Гиперссылки — все внешние ссылки должны быть живыми; внутренние [[wikilinks]] должны быть либо разрешены, либо удалены

Особые случаи именно Obsidian

Несколько сценариев встречаются достаточно часто, чтобы упомянуть их отдельно.

Ежедневные заметки и шаблоны

Если ты экспортируешь ежедневную заметку, которая использует {{date}} или переменные templater, экспорт происходит после того, как Obsidian их подставил — так что экспортированный .md содержит настоящую дату, а не плейсхолдер. Никакой особой обработки не нужно. Исключение — если ты экспортировал прямо из файловой системы, не открывая заметку в Obsidian; тогда нераскрытые шаблоны просочатся наружу. Сначала открой заметку, дай Obsidian её отрендерить, и только потом экспортируй.

Canvas-файлы

Canvas-файлы Obsidian (.canvas) — это JSON, а не Markdown, и ни один Markdown-конвертер их не возьмёт. Для канвасов рабочий вариант — сделать скриншот канваса на нужном уровне зума, сохранить его как PNG, а затем встроить эту картинку в заметку-обёртку на Markdown, которую ты и экспортируешь. Некоторые community-плагины также предлагают прямую функцию «export canvas as image», если приходится делать это достаточно часто, чтобы оправдать установку.

Диаграммы Mermaid

Ограждённые блоки кода с тегом mermaid рендерятся как диаграммы внутри Obsidian. Большинство онлайн-конвертеров Markdown в Word либо рендерят их как картинки (хорошо), либо оставляют как сырой код (плохо). MarkFlow рендерит Mermaid в инлайн-SVG перед конвертацией, и Word отображает его как редактируемое изображение. Если твой целевой конвертер не поддерживает Mermaid, запасной вариант — экспортировать диаграмму как PNG из режима просмотра Obsidian и заменить блок кода обычным встраиванием картинки.

Сноски

Хорошая новость — синтаксис сносок Obsidian ([^1] и определение [^1]: text) это стандартный GFM, и он чисто конвертируется во встроенную фичу сносок Word. Предобработки не требует.

Теги и frontmatter

YAML-frontmatter (блоки --- в начале заметки) конвертеры, как правило, выбрасывают. Если во фронтматтере лежит информация, которую твоему читателю нужно увидеть (автор, дата, статус), перенеси её в тело как обычный абзац перед экспортом. Инлайн-теги вроде #project/research обычно выживают как простой текст — что нормально в большинстве случаев и неловко в других. Прогони поиском с заменой и убери их, если Word-документ будут читать люди вне Obsidian.

Когда ручная конвертация обыгрывает автоматизацию

Буду честен: для одной заметки на 2-3 страницы с минимальным форматированием самый быстрый воркфлоу — скопировать из режима чтения Obsidian и вставить в Word. Режим чтения Obsidian рендерит HTML, а Word вставляет HTML как форматированный контент с неожиданно хорошей точностью. Таблицы приходят живыми, жирное/курсив выживает, заголовки маппятся на стили заголовков Word.

У этого подхода «вставка из режима чтения» три слабых места:

1. Картинки — они вставляются как ссылки на файлы в твоём хранилище, которые ломаются в тот момент, когда файл покидает твою машину
2. Блоки кода — подсветка синтаксиса теряется, моноширинный шрифт непоследователен
3. Выноски и Mermaid — та же поломка, что и при стандартном экспорте

Итого: короткие заметки без кода и картинок → вставка. Что-то длиннее или техничнее → четырёхшаговый воркфлоу выше.

Разбор проблем: что делать, когда что-то ломается

Вот режимы сбоев, которые я вижу чаще всего. Для более широкого справочника руководство по устранению проблем конвертации Markdown детально разбирает 15 типовых проблем конвертации.

В Word-файле отсутствуют картинки. В девяноста процентах случаев это проблема с путём. Проверь исходный .md — пути к вложениям это простые имена файлов (image.png) или сложные пути (../../99 Attachments/My Folder/image.png)? Расплющи их.

Таблицы рендерятся как однострочная каша. Твой источник использует легаси-формат таблиц Obsidian или содержит несогласованные символы pipe. Открой .md в обычном текстовом редакторе и убедись, что в каждой строке одинаковое число pipe. Разделитель заголовка должен совпадать: | --- | --- |.

Блоки кода теряют подсветку языка. Проверь, что твои ограждения включают тег языка (например, python, js, bash) сразу после открывающих тройных бэктиков. Конвертеры используют этот тег для применения подсветки синтаксиса; ограждения без метки скатываются в простой текст.

Wikilinks по-прежнему показываются как [[Note Name]] после экспорта. Предобработка не запускалась, или она не покрыла этот файл. Убедись, что Use [[Wikilinks]] выключен в настройках, затем перезапусти тот плагин конвертации, что ты установил на Шаге 2, по конкретному файлу — большинство из них поддерживает применение к одной заметке, а не ко всему хранилищу.

Математические формулы появляются как сырой LaTeX. Конвертер не поддерживает рендеринг математики. Либо смени конвертер, либо сделай скриншот отрендеренного уравнения в Obsidian и встрой как картинку — некрасиво, но надёжно.

Реалистичный воркфлоу для команд

Если ты единственный пользователь Obsidian в команде, которой нужны файлы Word, построй повторяемый процесс, а не разовый скрипт экспорта. Версия, которую я использую в совместных проектах:

1. Держи в хранилище отдельную папку Exports/ для заметок, которым суждено стать файлами Word
2. В этой папке с самого начала используй стандартные Markdown-ссылки ([text](note.md)) вместо wikilinks — это экономит предобработку
3. Раз в неделю прогоняй пакетную конвертацию для тех заметок, что изменились
4. Складывай готовые DOCX на общий диск, а не в хранилище

Цель — отделить твоё пространство мышления (основное хранилище со всей специфичной мощью Obsidian) от твоего пространства доставки (папка Exports/, говорящая на стандартном Markdown). Рефакторинг к этому разделению занял у меня час в первый раз и с тех пор экономит часы каждый месяц.

Если ты пришёл сюда с противоположной стороны — пишешь в Markdown и хочешь освоить основы — руководство как писать в Markdown покрывает фундамент, с которым любой экспорт идёт глаже. А для более пристального взгляда на сторону конвертации в этом пайплайне полное руководство по Markdown to Word проходит по фичам конвертера, которые важны для сложных документов.

Финальные мысли

Настоящая сила Obsidian — в его нестандартных фичах: wikilinks, выноски, динамические запросы, из-за которых хранилище ощущается живым. Экспорт в Word означает отказ от большей части всего этого. Фокус в том, чтобы перестать с этим бороться: принять, что версия Word будет упрощённым отображением, делать предобработку соответственно и использовать инструменты стилизации Word, чтобы восстановить полировку там, где это важно.

Когда привычка к предобработке устоялась, весь пайплайн занимает около пяти минут на заметку. Это разница между «сделаю позже» и тем, чтобы реально отправить документ сегодня.