Какой язык разметки для сильно форматированного контента?

Когда вы разрабатываете веб-приложение и хотите разрешить пользователю форматированный текст, вам нужно сделать выбор, как разрешить этот ввод. Было создано много разных языков разметки, потому что, возможно, сложнее дезинфицировать HTML.

В чем преимущества и недостатки различных разных языков разметки, таких как:

Или, говоря иначе, какие факторы вы учитываете при выборе конкретного языка разметки.

Ответы

Ответ 1

Разметка Markdown, BBCode, Textile, MediaWiki - это в основном одна и та же общая концепция, поэтому я бы просто разделил ее на две категории: HTML и разметку текста.

HTML

Сделка с HTML - это содержимое уже в "презентабельной" форме для веб-контента. Это замечательно, экономит время обработки, и это легко анализируемый язык. Есть десятки библиотек на любом языке для обработки содержимого HTML, конвертирования в/из HTML в другие форматы и т.д. Основной недостаток заключается в том, что из-за слабых стандартов ранних веб-дней HTML может быть невероятно переменным, и вы можете t всегда зависит от нормального ввода при принятии HTML-кода от пользователей. Как уже отмечалось, уборка или santizing HTML часто бывает очень сложной, особенно потому, что она не выполняет обычные правила разметки, как это делает XML (т.е. Неправильно закрытые теги).

Обычная разметка текста

Эта категория часто используется по следующим причинам:

  • Легко разобрать на несколько форм из одного источника - PDF, HTML, RTF
  • Содержимое хранится в читаемом обычном тексте (обычно гораздо более легком для чтения, чем необработанном HTML), если необходимо в какой-то более поздний срок, вместо того, чтобы извлекать из HTML
  • Выполняет определенные определенные правила, в которых HTML может быть раздражающей переменной и неструктурированной.
  • Позволяет принудительно форматировать подмножество форматирования содержимого, что более во многих случаях, чем просто разрешение полного HTML
  • В дополнение к форсированию подмножества HTML упрощается дезинфекция ввода и предотвращение проблем с сценарием на разных сайтах и ​​т.д.
  • Сохранение "сырых" данных в абстрактном формате означает, что в более поздний срок, если вы, например, хотели конвертировать ваш сайт из HTML 4 в XHTML, вам нужно только изменить код разбора. Благодаря вводу данных в формате HTML вы застряли, и теперь вам нужно преобразовать весь HTML в XHTML отдельно, что, как показывает HTML Tidy, не всегда является простой задачей. Аналогично, если в какой-то момент появляется новый язык разметки или вам нужно перейти в альтернативный формат (RTF, PDF, TeX), абстрагированное ограниченное подмножество вариантов форматирования текста делает эту задачу более простой.

Нижняя строка - это то, для чего используется пользовательский ввод. Если вы планируете хранить данные и, возможно, придется перетасовывать форматы и т.д., Тогда имеет смысл использовать тщательный абстрактный формат для хранения информации. Если вам нужно работать с необработанными данными вручную по любой причине, то бонусные баллы, если этот формат легко читается человеком. Если вы показываете только контент на веб-странице (или документ HTML для отчета и т.д.), И у вас нет проблем с его преобразованием или будущей проверкой, тогда разумная практика заключается в том, чтобы хранить его в HTML.

Ответ 3

@netrox база данных не является проблемой, выход браузера.

Единственная проблема - окончательный рендеринг, который может быть нарушен HTML-кодом, вставленным пользователем. Например, пользователь может открыть тег <li>, но никогда не закрывать его, что в зависимости от структуры страницы может потенциально повредить весь макет, который следует за ним. Или в другом примере откройте тег <strong>, не закрывая его, делая все оставшееся содержимое жирным.

Значит, не только допустимые теги должны быть проверены, но и как именно вы разрешаете некоторые теги, а не другие? Поскольку очень легко предотвратить синтаксический анализ всех HTML-тегов с помощью htmlspecialchars() Метод PHP, например, но когда дело доходит до разрешения некоторых из теги вам придется искать другие способы. Существует функция strip_tags() PHP, которая удаляет (полностью удаляет) недопустимые теги, но тогда это означает неправильное изменение содержимого пользователя, не позволяя пользователю публиковать простой код, например (код для совместного использования/показа, а не код для обработки).

Помимо разрыва макета, вы должны учитывать атаки XSS, такие как вставка javascript в атрибут href ссылки, которая, например, может перенаправлять пользователей на другой сайт. См. Этот длинный список возможных атак XSS: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Как вы можете видеть, что предотвращение интерпретации HTML-тегов очень просто, но предотвращение только некоторых из тегов намного сложнее. Чтобы понять это, вы можете взглянуть на огромную структуру HTML Purifier, которая предназначена только для того, чтобы разрешить некоторые HTML-теги и убедиться, что выводимый HTML действителен (т.е. не будет разбивать страницу) и без атак XSS.

Ответ 4

"Было создано много разных языков разметки, потому что, возможно, сложнее дезинфицировать HTML".

Действительно? Как это сложно? Существуют функции для удаления потенциально опасных атрибутов или тегов и проверки HTML, прежде чем вводить их в базу данных или файл. Можете ли вы привести примеры того, как сложно дезинфицировать HTML?