Исследование. Особенности парсинга сообщений в html-кодах и в bb-кодах

[doran7]

Исследование. Особенности парсинга сообщений в html-кодах и в bb-кодах

Цель. Сбор информации, обсуждение и подготовка обзорной статьи о парсинге сообщений в html-кодах и в bb-кодах.

Название статьи: "Принципы парсинга сообщений. Применение html-кодов и bb-кодов".

Аннотация. Принципы парсинга сообщений в блогах, комментариях и на форумах. Парсинг с применением html-кодов, достоинства и недостатки. Парсинг с применением bb-кодов, достоинства и недостатки. Преимущества парсинга при создании сообщений над парсингом при отображении сообщений (при генерации страницы с сообщением). Преимущества и недостатки хранения в БД текста сообщений, форматированного в bb-кодах и текста сообщений, форматированного в html-кодах. Возможность оптимизации форматирования текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.

Рассматриваемые вопросы
* Парсинг сообщений в bb-кодах.
* Хранение сообщений в БД с форматированием текста в bb-кодах.
* Парсинг сообщений в html-кодах
* Хранение сообщений в БД с форматированием текста в html-кодах.
* Возможности и ограничения оптимизации форматирования и парсинга текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.

Текущая ситуация. Проблемы и решения

На текущий момент форматирование и парсинг текста сообщений в блогах, комментариях, на форумах и т.д. в bb-кодах весьма популярно,. В частности, парсинг bb-кодов довольно хорошо отработан на форумном движке FluxBB последних версий. При этом в БД хранится текст сообщений, отформатированных в bb-кодах. Такой подход имеет ряд ограничений и недостатков. Например, необходимость парсить сообщения (преобразовывать из представления в bb-кодах в представление в html) при каждом просмотре сообщения. Это может довольно серьезно нагружать сервер хостера . В то же время, хранение в БД соощений, отформатированных в html-кодах, избавляет от необходимости парсить такие сообщения при их просмотре (отображении). Однако, парсинг таких сообщений при их создании и редактировании существенно сложеннее парсинга в bb-кодах. Кроме того, хранение в БД сообщений, отформатированных в html-кодах обладает ощутимой избыточностью, по сравнению с хранением в БД сообщений, отформатированных в bb-кодах.

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

 

[ksnk]

Возможность оптимизации форматирования текста в html-кодах за счет записи значений атрибутов html-тегов без кавычек.

Это как? Давайте экономить на кавычках и хранить невалидный html?

Вероятно статью следовало назвать "Особенности... в форуме FluxBB". Так как никто не мешает хранить и BB и отпарщенное сообщение в той же базе и использовать нужный вид по надобности.

 

[doran7]

Это как? Давайте экономить на кавычках и хранить невалидный html?

Первое, не для всех html-тегов я убираю кавыяки, а только для ограниченного набора упращенных тегов, предназначенных только для форматирования текста сообщений. Второе - с точки зрения стандарта и допусков HTML5 такие теги (при грамотном составе их атрибутов) вполне валидные.

Так как никто не мешает хранить и BB и отпарщенное сообщение в той же базе и использовать нужный вид по надобности.

Можно и так, но как-то это неэлегантно. Если постить в bb-кодах, потом парсить и сохранять в БД текст с форматированием в упрощенных (без кавычек) html-кодах, то при показе/просмотре таких сообщений их уже не надо парсить в html снова. При редактировании - да, снова придется парсить в bb-коды, ну и пусть. Случаев редактирования многократно меньше по сравнению со случаями просмотра сообщений, так что это можно пережить.Это вариант для юзеров: постят в bb, дальше валидация, парсинг в упрощенный html, хранение в БД в упрощенном html, просмотр - без парсинга, редактирование - обратный парсинг в bb. Вполне рабочая схема, с самым быстрым просмотром.

Для админа схема упрощается - создание сообщений в прощенном (без кавычек) html (из админки, никаких xss и хакеров), сответственно, хранение в БД в html, редактирование в html, показ/просмотр в html. А статей и сообщений, создаваемых админами - огромное количество.

Кстаити, для варианта bb- - нашел некий JS-парсер bb-кодов, статья здесь: http://sadex.p.ht/viewtopic.php?id=140 , демо-режим здесь: http://sadex.p.ht/aa/sample.html

Интересный парсер на JS, с его помощью можно делать предпросмотр сообщений, создаваемых в bb-кодах, прямо на клиенте, в браузере юзера, не напрягая для этого сервер.

 

[Vladson]

Такой подход имеет ряд ограничений и недостатков. Например, необходимость

(ИМХО)

Это на мой взгляд единственно верный подход, и эти "недостатки" существенны только для Highload (однако для него 99% правил неприменимы, но это штучный товар, к базовому вопросу "что такое хорошо, и что такое плохо" это неприменимо)

Любой сайт/блог/форум это простая схема ввод->хранилище->вывод в этой схеме нет понятия "данные" они просто то чем оперируют эти блоки, при этом вводов/выводов может быть много (браузер->БД, БД->браузер, БД->RSS, БД->почта) и у каждого своя форма форматирования, а потому оно всё должно идти на выводе.

 

[doran7]

Это на мой взгляд единственно верный подход, и эти "недостатки" существенны только для Highload (однако для него 99% правил неприменимы, но это штучный товар, к базовому вопросу "что такое хорошо, и что такое плохо" это неприменимо)

Ко всему "единственно верному" почему-то отношусь с недоверием... . Главный недостаток такого подхода (когда в БД форматирование в bb-кодах) - это необходимость парсить такие сообщения при любом их просмотре. А просмотров - многократно больше, чем созданий сообщений и их редактирований. Поэтому парсить bb-коды при создании и редактировании сообщений и хранить в БД уже отформатированные сообщения - просто рациональнее с точки зрения нагрузки на сервер. Лишняя процедура парсинга при просмотре, если ее можно избежать не очень оптимально выглядит. ИМХО.
Другой вопрос - как это грамотно организовать. Борьбу за скорость генерации страниц в конкурентном противостоянии сайтов никто не отменял.

 

[Vladson]

Хорошо. Конвертанул ты в HTML, а потом решил отправлять посты на мыло в plain/text, и что ? При каждом письме обратно конвертить ?

А нагрузка на сервер, ну не смешите меня... Это даже как шутка не смешно... 99% сайтов нормально висят на слабых серверах пачками по 100 штук, и не парятся. Если ваш сайт входит в 1% хоть сколько-то нагруженных, то это совсем уже другая история, и вас не касается не только ни одно "единственно верное" но и вообще 99% прописных истин которым учат любого нормального программиста вообще.

Да можно умножать с помощью сдвига, менять переменные ксором, пару тактов проца выиграете, и пару байт оперативки, а сколько потеряете в понятности кода другими (далеко не всегда хорошо квалифицированными) программерами ?

Изначально надо писать код понятный человеку (в том числе и самому себе, ибо от ошибок никто не застрахован, и в простом коде их допустить сложнее) а оптимизацией стоит заняться ТОЛЬКО тогда когда она нужна...

 

[doran7]

Хорошо. Конвертанул ты в HTML, а потом решил отправлять посты на мыло в plain/text, и что ? При каждом письме обратно конвертить ?

Интересная мысль, однако. Аналогичный вопрос к тебе. Конвертанул ты в BBCode, а потом решил отправлять посты на мыло в plain/text, и что ?

Вообще говоря, конвертнуть из HTML в plain/text гораздо проще, чем из BBCode в HTML, а потом, это делается один раз (одно сообщение конвертится) и рассылается на 1000 писем.

Насчет понятного кода - мы не об этом сейчас говорим, а о скорости генерации страниц - с процедурой парсинга из bbCode в HTML и без нее, когда из БД уже берется HTML в готовом виде.

 

[ksnk]

Можно и так, но как-то это неэлегантно

В чем неэлегантность? Ну, можно назвать этот этап "кэширование". Стало элегантнее?

При редактировании - да, снова придется парсить в bb-коды, ну и пусть

Предлагается ОДНОВРЕМЕННО иметь и BB и результат трансляции. Зачем парсить в bb коды? Вообще говоря, несложно придумать BB правила, когда однозначный обратный парсинг невозможен.

 

[fixxxer]

На текущий момент форматирование и парсинг текста сообщений в блогах, комментариях, на форумах и т.д. в bb-кодах весьма популярно

Популярно это недоразумение только в олдскульных форумах и их преемниках. Зародилось это еще в 90-х годах, когда браузеры не умели contentEditable/designMode: нормальный визивиг не сделаешь, полноценный парсер/валидатор html писать лень, а тут какбэ регулярок набросал и готово.

Для нетехнического человека, который не застал всякие вбуллетины, это выглядит ничем не лучше html-я - непонятный набор символов: современный "обычный юзер" с интернетами знаком не по форумам, где это дело привычное, а по фейсбукам-одноклассникам.

Рассуждения о емейлах в данном случае неприменимы: ббкод - это хак, заменяющий подмножество html, его единственный целевой формат - html - и, по большому счету, без разницы, из html-я или bbcode-а конвертировать в другие форматы. Действительно весомая причина хранить оригинальный ббкод - повторное редактирование. Но проще избавиться от этого недоразумения, дать пользователям нормальные человеческие яйц^W средства визуального редактирования - и вопрос отпадет сам собой.

 

[MiksIr]

fixxxer к сожалению нормальный визивиг на форуме - это ужасная головная боль. Если делать действительно хороший редактор, с цитатами, картинками и прочим. Мы как-то однажды сделали такой - трудозатраты огромные. BBкоды хороши еще одним - в случае ошибки парсинга, приводящей, например, к XSS нам нужно только поменять алгоритм парсера. Да и вообще замена BB на HTML более управляема с этой точки зрения, чем валидация html.

 

[doran7]

Действительно весомая причина хранить оригинальный ббкод - повторное редактирование.

Если это так, то для повторного редактирования я сделаю обратный парсинг из html в bb-, благо он гораздо проще должен быть, чем прямой. А в БД могу хранить форматирование в упрощенных (урезанных) html-кодах без кавычек, и в добавок - ограниченного набора.

Но проще избавиться от этого недоразумения, дать пользователям нормальные человеческие яйц^W средства визуального редактирования - и вопрос отпадет сам собой.

Это конечно проще, прикрутил CKEditor или TinyMCE - и все дела. Но есть причина, по которой не все так делают, и на этом форуме тоже.

На Stack Overflow этот вопрос тоже обсуждался. Why should I use BBCode but not HTML-code in comment forms?
http://stackoverflow.com/questions/7268023/why-should-i-use-bbcode-but-not-html-in-comment-forms

К однозначному выводу не пришли. Говорят, что использование bbCode позволяет иметь минимальные издержки при защите сайтов от XSS и прочих атак.

BBCode became popular as allowing the user a limited access to html while trying to prevent XSS. BBCode became popular before there where solutions like HTML Purifier. In all reality BBCode and Html Purifier have their own security problems. Its just that BBCode was a more simple solution to this problem.

 

[doran7]

Да и вообще замена BB на HTML более управляема с этой точки зрения, чем валидация html.

Похоже что так. Сообщение от юзера с форматированием в bbCode на сервере можно прогнать через strip_tags, а с форматированием в html-кодах такого не сделаешь.

Может даже проще и менее затратно по ресурсам делать форматирование в bbCode, парсинг в урезанный html (без кавычек) и сохранение этого html в БД, чем постить и форматировать в html, делать валидацию и фильтрацию этого html (с помощью htmLawed, например) и хранить этот html в БД.

 

[fixxxer]

BBкоды хороши еще одним - в случае ошибки парсинга, приводящей, например, к XSS нам нужно только поменять алгоритм парсера

Ну так храни оригинальный инпут и прогоняй purifier при выводе (разумеется это можно кэшировать) - получишь 1 в 1 то же, что с bb

Трудозатраты на нормальный UI, разумеется, выше, чем в случае перекладывания проблемы на пользователей =)

 

[doran7]

Ну так храни оригинальный инпут и прогоняй purifier при выводе...

А если прогонять purifier-ом перед сохранением в БД html-кода?

 

[fixxxer]

А если прогонять purifier-ом перед сохранением в БД html-кода?

- Скажытэ, мая жэна родыла?
- Да.
- Малъчык?
- Нет.
- А кто?

 

[doran7]

- Малъчык?
- Нет.
- А кто?

... Реально не уловил, где было сказано, что не мальчик... Я наполовину не врубаюсь в такую профессиональную терминологию... "Оригинальный инпут" - это html имелся в виду?

 

[Vladson]

Конвертанул ты в BBCode

А я и не сказал что надо конвертить во что либо, совсем наоборот... В базе должно быть то что написал юзер (bbcode или нет, это уже вопрос конкретного продукта)

 

[Vladson]

мы не об этом сейчас говорим, а о скорости генерации страниц

Это взаимосвязано. Можно делать быстрый но сложный код, а можно сделать "достаточно быстрый" (читай медленный) который при необходимости без труда можно усложнить/ускорить (что нужно очень редко) вместо того чтоб (что нужно очень часто) упрощать сложный (который сначала ещё писать надо)

 

[MiksIr]

Ну так храни оригинальный инпут и прогоняй purifier при выводе (разумеется это можно кэшировать) - получишь 1 в 1 то же, что с bb

purifier тяжелее будет. Ибо HTML сложнее BB-кодов. А если упрощать HTML только под наши нужды.. ну получим аналог бб-кодов. Так что по сути это такая вкусовщина получается. Но с бб-кодами спистся спокойнее.
И, кстати, бб коды никак визивигу не мешают, мы именно так и делали - визивиг редактор, плагин для упрошения результата и перевода в бб-коды - парсинг на выводе.

Трудозатраты на нормальный UI, разумеется, выше, чем в случае перекладывания проблемы на пользователей =)

Много выше. Я бы сказал - много-много выше, и требуют постоянной поддержки, ибо браузеры не стоят на месте.

 

[doran7]

В базе должно быть то что написал юзер (bbcode или нет, это уже вопрос конкретного продукта)

1. Допустим, выбор за разработчиком, что хранить в БД - сообщение юзера, отформатированное в bb-кодах или в html-кодах.
2. Разработчик принял, что юзер постит в bb-кодах (многие говорят что это оптимально, с точки зрения издержек на обеспечение безопасности, я также думаю).

Дальше у разработчика два варианта. Первый - хранить сообщение юзера в БД в bb-кодах, но при этот придется парсить в html вывод/просмотр этого сообщения. Второй - пропарсить bb-коды в html на этапе ввода (редактирования) сообщения, и хранить в БД уже готовый к выводу html.

При первом варианте легче редактировать сообщение, т.к. не надо преобразовывать bb-коды из БД при выдаче сообщения юзеру для редактирования. Но при этом придется парсить сообщение в html при выдаче его для просмотра.

При втором варианте легче выдавать готовый html из БД для просмотра, но надо парсить обратно html из БД в bb-коды при редактировании.

При первом и втором варианте степень безопасности одинаковая, валидация и фильтрация одинаковая по издержкам. Различие только в том, что хранится в БД (bb- или html-коды форматирования) и в том, на каком этапе (до помещения в БД или после) производится парсинг из bb- в html-коды.

И первый и второй вариант имеют право на существование (зависит от особенностей сайта и выбора разработчика). НО. При втором варианте, такая массовая процедура как выдача сообщения из БД для просмотра, может осуществляться без парсинга bb в HTML. А эта массовая процедура - самое узкое место (для времени генерации страницы) во всем процессе, по издержкам (нагрузкам) сервера. И второй вариант позволяет расшить это узкое место, облегчить эту самую напряженную для сервера процедуру. ИМХО. При условии, что редактирование происходит в десятки/сотни/тысячи и т.д. раз реже, чем просмотр сообщения.