но с логической т.з. всё вроде правильно, 2 только болд, 4 подчеркнуто, 3 на пересечении.

на форуме sql.ru то же самое, щас проверил

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

:) Ну главное - идеи - идея неплоха, но нет алгоритма поиска ошибок
И проверил на больших массивах кой код, совместно с куском от devote шустрее, именно он парсит теги без проблем в один -два прохода (без всяки массивов и реверса

:) Ну главное - идеи - идея неплоха, но нет алгоритма поиска ошибок
И проверил на больших массивах свой код, совместно с куском от devote шустрее, именно он парсит теги без проблем в один -два прохода (без всяки массивов и реверса Завтра выложу рандом - ибо лень мегабайты вставлять в песочню

Это как посмотреть на идею. Нашли открывающий тег, помещаем его в стек:

1) если его нет в правилах описанных, значит далее может идти текст или другой открывающий тег
2) если тег есть в правилах, проверяем что следует за ним и что может следовать за ним согласно правил, соответственно следствие

нашли закрывающий тег:

1) если есть правила описанные для тега, проверяем корректно ли закрытие, и если нет, очищаем вершину стека, а текст помещаем как есть
2) если тега нет в правилах, закрытие корректное, обрамляем текст htnl-тегом, иначе ошибка и игнорируем, помещая текст как есть
3) очищаем вершину стека

laimas,
Плюнь пока на правила для тега, это тоже легко поправимо, поставив регу от devote вместо фиксированного списка и объект с функцией перепарса по tag
Воть ошибки, что принимать за корректное - а что нет - тут проблемы - ибо зависит от положения найденного тега, что за один проход вряд ли сделаешь (ну нашли, а внутри несколько вложенных валидных, или не валидных, т.е нун считать кратность вложенных идентичных - как минимум

Вершина стека и определяет валидно или нет, ваша задача следить за вершиной стека.

laimas,
Проще выложи код завтра, а я тест на скорость, ибо один фиг валидация затруднена (мну перерыл кучу, со стеком тож видел)
Самый короткий и простой метод с рекурсией(идём от обрамляющих тегов к вложенным), автоматом поддерживает валидность за счёт сокращения вложенной строки - но рекурсия

Код чего, готового разбора по принципу стека? У меня его нет, но то что можно сделать такое, это 100% гарантии. Вряд ли бы я стал тужится с разбором ВВ только лишь рег. выражениями на JS, хотя бы уже потому, что RegExp в нем хилый по набору, в отличие от возможностей сервера.

Кроме это, "искать возможные ошибки посредством повторных разборов строки", это накладно, гораздо проще смещаться по массиву. И хотите вы того или нет, но html это разнобразие тегов, и без правил не обойтись, вряд ли длинные портяки шаблонов рег. выражений для решения данного условия, это будет легко для RegExp.

Я согласен, что простейший набор, типа как тут B, I, U, ... вполне можно обработать и RegExp, но при ошибках вложений все равно придется карячится.

Стек же есть стек, если был опыт работы с ассемблером, то возможно и сталкивались с очень интересными решениями как раз используя стек, где вроде бы о нем и речи быть не должно. В РНР к примеру, в SPL, есть реализация стека.

Я никого не принуждаю, как считаете нужным, так и делайте. Главная цель скорость, а остальное боком, ну так пожалуйста. Я же, для себя, подобное бы делал (буду, если потребуется) именно на стеке.

Deff,

так что вот с этим? http://javascript.ru/forum/misc/2493...tml#post402862

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