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

Question

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

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

• HTML
• Уценка
• BBCode Код BBCode
• Текстиль
• Разметка MediaWiki
• Другое

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

Answer 1

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

HTML

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

Обычная текстовая Разметка

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

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

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

Answer 2

Джефф обсудили некоторые плюсы и минусы на codinghorror.com пока они были на начальных стадиях составления SO.Я подумал, что это было стоящее чтение.

Answer 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" фреймворк, единственной целью которого является разрешить некоторые HTML-теги и убедиться, что выводимый HTML является допустимым (т.е.не сломает страницу) и свободен от XSS-атак.

Answer 4

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

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