Какой язык разметки для богато отформатированного контента? - PullRequest
12 голосов
/ 05 декабря 2008

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

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

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

Ответы [ 4 ]

10 голосов
/ 05 декабря 2008

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-документ для отчета и т. Д.) И не беспокоитесь о его преобразовании или проверке на будущее, то разумно хранить его в HTML.

5 голосов
/ 05 декабря 2008

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

0 голосов
/ 14 июля 2013

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

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

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

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

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

0 голосов
/ 21 октября 2010

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

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

...