Священная война разметок: Почему DLE хранит HTML, а Telegram — чистый текст

Или: Как BBCode, Markdown и вечный спор о безопасности привели к тому, что мессенджеры умнее CMS

📜 Пролог: Три эпохи, три подхода

В начале был HTML. Честный, понятный, вездесущий. Вы писали жирный текст, и браузер его делал жирным. Проблема? Любой пользователь мог написать — и это срабатывало. В 2000-е годы это было весело (до первого взлома).

Потом пришли форумы. Чтобы обычный пользователь не поломал сайт, придумали BBCode. Вместо

<b>[.code] писали [b]. Вместо [code]<a href="">

—

[url][/url]

. Безопасно, просто, но уродливо в исходном коде.

Потом случился GitHub и Stack Overflow. Они популяризировали Markdown. Ещё проще, ещё читаемее, ещё безопаснее. **жирный** вместо

[b]

. Идеально для тех, кто не хочет учить теги.

А потом пришёл Telegram. И внёс свою лепту.

Мы, как веб-разработчики, до сих пор спорим: что хранить в базе данных? Готовый HTML? Сырой BBCode? Чистый Markdown? А может, вообще ничего из этого?

Ответ меняет не только то, как вы пишете код, но и то, насколько ваш сайт готов к эпохе AI-агентов, о которой мы говорили в прошлый раз.

🏛️ Акт 1: Как DLE решил проблему (и создал новую)

DataLife Engine (и многие CMS той эпохи) пошли по пути компромисса. Они хранят в базе данных готовый HTML.

Почему они так решили:

1. Скорость. Не нужно каждый раз парсить BBCode или Markdown в HTML при загрузке страницы. Достаточно просто вывести то, что лежит в базе. Это быстро, особенно на слабых хостингах 2000-х.
   
2. Редактирование. Визуальному редактору (WYSIWYG) проще работать с HTML. Он его создаёт, он его и показывает.
   
3. Простота. Не нужно писать парсер для BBCode или Markdown. Берёшь готовый HTML — и в базу.
   

Но эта стратегия породила новые проблемы:

Раздувание базы данных. Один короткий комментарий со смайлом может превратиться в килобайты HTML-мусора. Пользователь написал «Привет» со смайликом — в базе оказывается конструкция на 5 строк с < div>, < span>, < img> и кучей inline-стилей. Умножаем на тысячи комментариев — получаем тонны мусора. Как верно подметил один из пользователей DLE на форуме: «Один коммент с двумя словами и двумя смайлами, а столько «говна» в базу»

Ирония судьбы: DLE боится внедрять Markdown из-за "безопасности" (чтобы не плодить лишние конвертации), но его текущая архитектура с хранением HTML потенциально опаснее, чем любая разметка с сырым текстом.

Альтернативный подход из мира форумов — хранить в базе BBCode, а HTML генерировать при выводе — уже существовал. Более того, в CMS наподобие InstantCMS была продумана эта архитектура: для постов одновременно хранились и сырой BB‑код, и готовый HTML, чтобы не парсить текст при каждом редактировании. Да, база данных «раздувалась» вдвое, но это был осознанный компромисс между скоростью и перспективой .

🔐 Акт 2: Почему безопасность — это не про редактор, а про бэкенд

Разработчики DLE утверждают, что отказались от BBCode и не внедряют Markdown по соображениям безопасности. Якобы лишние конвертации плодят уязвимости.

Это миф. Или, мягко говоря, лукавство.

Вся безопасность любой CMS — на стороне бэкенда. Неважно, что отправляет пользователь: HTML, BBCode, Markdown или сырой текст. Если вы плохо фильтруете входящие данные — вас взломают. Если фильтруете хорошо — не взломают .

Истинная причина отказа от BBCode/Markdown в DLE — это сложность поддержки визуального редактора. WYSIWYG-редакторам (типа TinyMCE или CKEditor) проще работать с HTML. Они его генерируют, они его редактируют. А вот чтобы заставить их работать с BBCode или Markdown, нужно писать прослойку-конвертер. Это дополнительные трудозатраты для разработчиков движка.

Технически, реализация Markdown в DLE невозможна, только если разработчики сами не захотят её реализовать. PHP-пакетов для парсинга Markdown — десятки. cebe/markdown — один из самых авторитетных и стабильных парсеров с поддержкой GitHub Flavored Markdown и Markdown Extra . Есть и более экзотические, но молниеносные варианты, например PECL-расширение md4c, написанное на чистом C, — оно способно переваривать мегабайты текста за миллисекунды . Архитектура DLE это позволяет.

Но DLE упёрлись в позицию: «Только HTML, потому что безопасно». Хотя на самом деле — «потому что так исторически сложилось, и мы не хотим переписывать редактор».



Но есть CMS, которые пошли другим путём. Например, MODX Revo изначально хранил чистый HTML, чем доставлял много головной боли владельцам сайтов при смене дизайна. Их более современная версия MODX Evolution перешла на хранение сырых данных, что стало настоящим спасением для всех, кто ценит будущее своего контента.

💬 Акт 3: Что же делает Telegram (и почему это гениально)

А теперь посмотрим на Telegram. В мессенджере мы пишем текст, и, чтобы его украсить, используем Markdown (или ограниченный набор HTML-тегов). Текст хранится в базе данных как есть, в чистом виде, вместе со служебными символами разметки.

Почему это гениально:

1. Универсальность. Один и тот же текст можно отобразить где угодно: в вебе, в мобильном приложении, в десктопном клиенте. Для каждого устройства — своя версия HTML. Не нужно хранить отдельные копии.
   
2. Безопасность. Парсить Markdown в HTML гораздо безопаснее, чем пытаться «обезвредить» пользовательский HTML. Markdown не позволяет вставлять скрипты и опасные теги по определению.
   
3. Экономия места. Вы храните ровно тот текст, который написал пользователь. Никакого лишнего HTML-мусора, который раздувает базу данных.
   
4. Будущее. Если завтра появится новый формат разметки, вам не нужно конвертировать старые данные. Вы просто напишете новый парсер.
   

Ирония: Мессенджер, который не позиционирует себя как CMS, технически реализовал работу с контентом более грамотно, чем многие профессиональные системы управления сайтами.

🔄 Акт 4: А как же ваш новый скрипт? (Идеальное решение)

Вы разрабатываете скрипт, который принимает письма по email и публикует их как посты в блоге. Email приходит в чистом тексте (plain/text). Вы сохраняете его в базу данных как есть, безо всякой разметки.





Это идеальный подход!

Это безопасно. Пользователь не может вставить в email HTML-теги, которые сломают ваш сайт.
Это экономит место. Вы храните ровно тот текст, который написал пользователь.
Это универсально. Вы всегда сможете добавить парсер для Markdown, BBCode или любого другого формата постфактум.




А чтобы отобразить этот текст красиво в HTML, ваш скрипт должен на лету:

1. Определить (или дать возможность пользователю выбрать), в какой разметке написан текст (если вообще в какой-то).
   
2. Распарсить эту разметку в HTML с помощью подходящей библиотеки (Markdown, BBCode).
   
3. Выдать готовый HTML на сайте.
   

Это идеальная архитектура для долгоживущего проекта.

🚀 Акт 5: Что это значит для веб-разработчика (и для будущего)

Философия Telegram и вашего скрипта — это контент в чистом виде, а визуал — как услуга. Это именно то, к чему мы должны стремиться в веб-разработке, особенно в эпоху AI-агентов.

Вернёмся к прошлой статье про AI-агентов. Помните, мы говорили, что агентам нужен чистый структурированный контент в JSON, XML, RSS? Им плевать на ваш красивый дизайн.

Если вы храните контент в HTML — вам придётся его парсить, чтобы отдать агенту. Это лишняя работа и потенциальные ошибки.
Если вы храните контент в чистом виде (с разметкой Markdown или даже без неё) — вы легко отдадите его агенту в нужном формате.

Вывод: хранение чистого текста в базе данных — это не просто «правильное» решение с точки зрения производительности и безопасности. Это стратегическое решение, которое готовит ваш сайт к грядущей эпохе AI-агентов.

🧾 Эпилог: Чистый текст — основа цифрового суверенитета

Разработчики DLE лукавят, когда говорят, что Markdown опасен. На самом деле опасен плохо написанный код фильтрации HTML. А хранить чистый текст с разметкой — это универсально, безопасно и дальновидно.

Ваш скрипт по публикации email-писем — это пример идеальной архитектуры. Вы храните то, что получаете — чистый текст. А HTML генерируете на лету.

Почему это важно для будущего?

1. Универсальность. Ваш контент можно отобразить где угодно: на сайте, в мобильном приложении, в Telegram-боте, в голосовом ассистенте.
   
2. Безопасность. Вы не зависите от дыр в фильтрации HTML. Парсеры Markdown безопасны по определению.
   
3. AI-агенты. Им не нужно парсить ваш HTML. Вы отдадите им чистый JSON или XML.
   
4. Архивация. Вы храните ровно то, что написал автор. Никакого лишнего мусора.
   

Помните: веб-страница — это лишь одна из «витрин» вашего контента. Храните его так, чтобы он мог жить на любой витрине, не требуя переделки. Идея «хранить в базе данных не готовый результат, а исходные данные с документацией по их преобразованию» — это основа качественного API, к которому мы все должны стремиться.



P.S. Мы в TCSE не храним HTML в базе данных. Мы храним чистые данные, а HTML генерируем на стороне шаблонизатора. Это дольше на микросекунду, но безопаснее и гибче. Именно так мы готовим сайты к эпохе агентов.

P.P.S. А если вы всё ещё храните HTML в базе, потому что «так быстрее», — попробуйте спросить себя: вам нужна производительность здесь и сейчас или возможность развиваться годами? Выбор за вами. Но Telegram свой выбор уже сделал. И он, кажется, оказался прав. 😏