Один и тот же текст живёт в четырёх телах: Markdown — для редактирования и черновиков, HTML — для публикации и вставки в CMS, чистый текст — для рассылок, логов и терминала, а «просто красивый текст» — это ещё и типографика: кавычки-ёлочки вместо лапок, тире вместо дефисов, неразрывные пробелы. Конвертировать между этими состояниями вручную — значит терять структуру на каждом переходе: HTML склеивается в «простыню», Markdown-таблица разваливается, в Word-скомпилированном тексте остаётся мусор от форматирования. Разберём, чем форматы отличаются по-настоящему, где конвертация неизбежно теряет, и как довести текст до вида, не переписывая его руками.
Часть I. Три формата — три потребителя
Текст существует не «вообще», а всегда для кого-то конкретного. Формат — это контракт с потребителем, и выбор формата = выбор того, кто будет текст интерпретировать.
| Формат | Потребитель | Назначение | Где живёт |
|---|---|---|---|
| Markdown | человек + редактор/git | писать и ревьюить диффы, вести документацию | .md, README, вики |
| HTML | браузер, CMS, email-клиент | публиковать, стилизовать, отдавать в вебе | страницы WP, письма |
| чистый текст | терминал, лог, рассылка без разметки | читать везде, где разметки нет | txt, конфиг, --format=plain |
Практический смысл таблицы: начинайте с формата потребителя, а не с convenience автора. Пишете статью, которая уйдёт в WordPress? Рабочий носитель для неё всё равно HTML — но писать по-человечески удобнее в Markdown, значит в цепочке обязана быть конвертация. Собираете документацию к плагину в репозитории? Нужен Markdown, и не нужен HTML никогда. Делаете email-дайджест в рассылку без HTML-версии? Чистый текст, и любая разметка в нём — баг.
Эти цепочки и разбираются ниже: Markdown→HTML (II), разметка→чистый текст (III), и поверх всего этого — типографика как отдельный проход (IV).
Часть II. Markdown против HTML: конвертация несимметрична
Главное заблуждение: «форматы взаимно конвертируемы». На практике направление решает.
Markdown → HTML: почти без потерь. Markdown — подмножество смыслов HTML: # это <h1>…</h1>, **жирный** это <strong>, - это <li>. Каждой конструкции Markdown соответствует готовый HTML-элемент, поэтому конвертер переводит их механически.
## Заголовок раздела
Обычный абзац с **жирным** и [ссылкой](https://example.test/page).
- пункт списка
- второй пункттот же текст после конвертации в HTML:
<h2>Заголовок раздела</h2>
<p>Обычный абзац с <strong>жирным</strong> и <a href="https://example.test/page">ссылкой</a>.</p>
<ul>
<li>пункт списка</li>
<li>второй пункт</li>
</ul>HTML → Markdown: теряет всё, чего в Markdown нет. В Markdown физически отсутствуют: классы и стили, вложенные блоки, <div>, таблицы со слиянием ячеек, якоря <a name>, формы, картинки с title. Конвертер, встречая такое, делает одно из трёх (и каждое — потеря): выбрасывает узел, «размывает» до текста или выдаёт сырой HTML внутри Markdown (легитимный, но ломает переносимость). Поэтому обратный путь «вытащить HTML-страницу в Markdown» для сложной вёрстки — всегда потеря структуры, и честный инструмент об этом предупреждает, а не делает вид.
Таблицы — отдельный случай. Markdown-таблица не поддерживает объединение ячеек и множественные заголовки; HTML-таблица поддерживает. Значит: MD→HTML ok, сложная HTML→MD упрощает или ломается. Простые регулярные таблицы переживают круг без потерь.
Часть III. В чистый текст: не удалить теги, а переложить структуру
Ключевое различие: чистый текст — не «HTML минус теги», а «смысл минус разметка». Смыслы (заголовки, списки, абзацы) никуда не делись — у них просто больше нет стандартных носителей, и их надо переложить в конвенции текста:
| В разметке | В чистом тексте |
|---|---|
<h2> / ## | отдельная строка-заголовок (часто заглавными или с отступом) |
<ul><li> | маркеры - в начале строки |
<ol> | нумерация 1. 2. |
абзацы <p> | пустая строка между блоками |
**сильный** | пропадает (в чистом тексте нет «жирного») |
Наивная конвертация «вырезать теги регуляркой» даёт знаменитую «простыню»: все абзацы склеиваются в одну строку, списки теряют маркеры, текст формально «без HTML», фактически — нечитаем. Рабочая конвертация сохраняет пустые строки между блоками и оформляет списки маркерами — то есть переводит не теги, а структуру.
Отдельная ловушка — сущности ( , —, «): в HTML они живут как коды символов. В чистый текст их надо раскрыть в настоящие символы (неразрывный пробел, тире, кавычки), а не тащить амперсанды за собой — ««слово»» в txt читается именно так, с буквальными &.
Когда это нужно по-настоящему: письма в рассылке без HTML-версии (клиенты, у которых выключена разметка), вывод в терминал/лог, extraction текста страницы для анализа, plain-версия статьи «для печати».
Часть IV. Типографика: формат не при чём, а вид текста решают именно эти правки
Типографика — отдельный слой поверх формата: те же байты текста можно оформить «как в Word из 90-х» или «как в книге». Это не разметка — это символы и пробелы, и чинится оно финальным «проходом очистки», после того как формат уже выбран.
Базовый набор правок для русского текста:
- кавычки-ёлочки
«…»вместо прямых"…"(и вложенные „лапки“); - тире
—между словами и перед «это/вот» — вместо дефиса с пробелами «-»; - неразрывный пробел перед короткими словами-предлогами и союзами («на ‹nbsp›сервере»), чтобы перенос строки не оставлял висячий предлог;
- пробелы около знаков: один пробел после точки/запятой, никаких пробелов перед ними; двойные пробелы внутри строки — схлопнуть;
- пустые строки и хвостовой мусор: лишние пустые абзацы и повторяющиеся куски — убрать.
было (Word-экспорт, кривая типографика):
Настройка - это важный этап. Нельзя ставить "запятую" ,в начале строки.
В этой статье мы рассмотрим все параметры.
стало (после прохода типографики):
Настройка — это важный этап. Нельзя ставить «запятую» в начале строки.
В этой статье мы рассмотрим все параметры.Почему это стоит делать отдельным проходом: правки форматов (части II–III) и правки символов независимы. Сначала выбираете тело текста (HTML/MD/plain), потом причесываете содержимое. В обратном порядке конвертер может «съесть» ваши неразрывные пробелы при переносе тегов.
Часть V. Практика под WordPress: Gutenberg, вставка из Word и чистый HTML
У WordPress есть своя специфика, из-за которой цепочки из частей II–IV ломаются по-своему.
Gutenberg говорит на HTML, а не на Markdown
Редактор блоков (Gutenberg) хранит содержимое поста как HTML плюс block-комментарии (<!-- wp:paragraph --> … <!-- /wp:paragraph -->) — это его родной формат. Markdown для него не нативен: вставить Markdown «как есть» — значит увидеть в статье литеральные ## и **. Поэтому рабочий путь для Markdown-черновика: сначала конвертировать в HTML, потом вставлять в редактор (в «HTML-блок» или как обычные блоки). Тот же путь — для любого внешнего текста, которому нужна публикация.
При вставке в чистый HTML-шаблон или письмо важна ещё деталь: не нужен полный документ. Достаточно внутреннего контента — без <!DOCTYPE>, <html>, <head>, <body>; вставка такого «каркаса» внутрь поста или блочного контейнера ломает вёрстку. Хороший конвертер по умолчанию отдаёт именно внутренности: семантичные <h2>, <p>, <ul>, <strong>, <a>, <table> — и ничего вокруг.
Вставка из Word/RTF — мусор стилей
Copy-paste из Word в Gutenberg тащит за собой «грязный» HTML: <span style="..."> на каждой букве, классы MsoNormal, обрезанные шрифты, кавычки-лапки вместо ёлочек, двойные пробелы. Результат — текст выглядит как в Word, но весит в 3 раза больше и не слушается темы.
Правильная цепочка для Word-исходника:
- вытащить содержание в чистый текст или Markdown (проход «очистка и типографика» убирает стили-обломки);
- поправить символы (ёлочки/тире/пробелы — часть IV);
- конвертировать в чистый семантичный HTML (часть II);
- вставить в Gutenberg.
Так же решается и обратная задача — «сделать из HTML-страницы аккуратный текст для дайджеста/рассылки» (часть III, с раскрытием сущностей).
Часть VI. Режим вывода и границы инструмента
Два практических параметра, которые часто забывают, — они дешевле, чем кажется, но портят результат по умолчанию.
Плотность вывода: стандартный / компактный / развёрнутый. Это не косметика, а разные тексты под разные места:
- компактный — без лишних пустых строк: для вставки в готовый HTML-блок, в письмо с tight-вёрсткой, туда, где пустые строки превратятся в giant-gap;
- развёрнутый — с пустыми строками между абзацами: для чтения как документа, для Markdown-файла, для diff;
- стандартный — сбалансированный вариант по умолчанию.
Один и тот же HTML в «компактном» и «развёрнутом» режимах — одинаковый смысл, удобная вставка против удобочитаемого исходника. Выбирайте режим по месту назначения, не по вкусу.
Границы входа. У автоматической конвертации есть потолок объёма (у готового инструмента ниже — 15 000 символов за запрос): длинные лонгриды не проходят одним куском. Рабочий приём — конвертировать по разделам (каждый H2 отдельно) и склеить результат: структура от этого не меняется, а лимит не наступает. Это же защищает от «тихого» усечения хвоста на огромном тексте.
Ответственный за смысл остаётся человек. Конвертер выбирает теги и убирает мусор; он не решает, был ли заголовок списком или пунктом, и не знает, что «та таблица» — ключевая в статье. Финальная сверка результата с исходником (особенно после обратных направлений — часть II про потери) остаётся за вами.
Инструменты под задачу
Держать в голове правила всех четырёх направлений и трёх режимов, помнить про раскрытие сущностей при «чистом тексте» и про мусор Word при вставке в Gutenberg — это ровно тот класс механических правок, которые легко автоматизировать и почти невозможно вычитать без пропуска. Чтобы снять рутину, в codestack.space есть ИИ конвертер текста. Он покрывает все разобранное выше одним экраном:
- четыре направления: текст → Markdown (заголовки
#, списки, ссылки, таблицы), текст → HTML (семантичные теги, без обвязки документа), Markdown/HTML → чистый текст (с сохранением абзацев и маркеров), очистка и типографика (ёлочки, тире, лишние пробелы, дубли абзацев); - три режима вывода: стандартный / компактный / развёрнутый — под письмо, вставку или чтение;
- живой предпросмотр результата рядом с кодом — видно не «что вернул сервис», а как это будет выглядеть;
- лимит 15 000 символов за проход — на лонгрид конвертируйте по разделам (Часть VI).
Попробуйте прямо здесь, на своём тексте:
Он не решает, какой формат нужен вашему потребителю (Часть I) и что потеряется при обратном ходе (Часть II) — он снимает ручную часть: переложить структуру, причесать символы, не забыть неразрывный пробел.
Чек-лист граблей
- Начинаете «с удобного автору» формата вместо формата потребителя → ломается вся цепочка; спросите «кто это читает» (часть I).
- Ждёте потерю структуры при HTML→Markdown → вложенные блоки, стили, сложные таблицы — их просто нет в Markdown; это не баг конвертера.
- Снимаете «чистый текст» вырезанием тегов регуляркой → простыня без абзацев и маркеров; структуру надо перекладывать, а не удалять.
- Тащите HTML-сущности (`«`, ` `) в txt → читается буквально; раскрывайте в символы.
- Вставляете Markdown-черновик прямо в Gutenberg → видите литеральные `##` и `**`; сначала в HTML, потом в редактор.
- Вставляете из Word по copy-paste → мусор `MsoNormal`/`span style` поверх текста; сначала очистка, потом конвертация.
- Вставляете HTML с `<!DOCTYPE>`/`<body>` в пост → ломает вёрстку страницы; просите внутренний контент.
- Не выбираете режим компактный/развёрнутый под место назначения → пустые строки распухают в письме или слепливаются в документе.
- Конвертируете лонгрид целиком через инструмент с лимитом → тихое усечение хвоста; режьте по разделам (H2) и склеивайте.
- Доверяете обратным направлениям «на глаз» без сверки → потерянные смыслы молча уходят; сверяйте с исходником.
- Правите типографику до смены формата → конвертер съедает неразрывные пробелы при переносе; символы — финальным проходом.
👤 Зарегистрируйтесь, чтобы добавить материал в закладки.