LINUX.ORG.RU

Делаем для прикола свой HTML-парсер, не догоняем особенности <SCRIPT></SCRIPT>


0

1

Некрасивым, но быстрым решением при работе с тегом <SCRIPT> оказалось такое: после приёма валидного тега <script attr=«value»> с любыми атрибутами, отрубаем HTML-парсер и тупо ждём подстроку «</», после чего ждём «>» и врубаем HTML-парсер обратно.

Сначала думали, что в JavaScript допустимо написать var x = «</script>» и тогда ловить закрывающий </script> было бы ещё труднее. Мало того, в теле скрипта запрещена подстрока «</».

Это мы узнали не из чтения стандарта (не нашли такого места), а из экспериментов с браузером chrome.

Начали экспериментировать с браузером chrome. Скармливаем ему лабуду между тегами <script></script> и смотрим на реакцию. Удивительной штукой оказалось то, что достаточно появления в теле «скрипта» подстроки «</» и тег <script> считается закрытым.

Выявленный алгоритм реакции на <script> в chrome такой:

Изначально работает полноценный HTML-парсер. Если встретился тег <script> (в любых реализациях (< ScRiPt ParaM1=1 paRRam2=2>), HTML-парсер отрубается, начинает работать процедура, ищущая подстроку «</». Как только данная подстрока найдена, ищется «>», после чего полноценный HTML-парсер врубается обратно. Всё, что после нормального тега <script> и до строки «</»- отдаётся javascript-движку.

Есть ли тут гуру, которые могут высказаться по теме? Где мы не правы в наших наблюдениях?

Только не надо спрашивать, зачем нам писать свой HTML-парсер, в гуманитарных науках мы не сильны.

Скорее всего ваши наблюдения неверны. Сейчас почти на каждом говносайте в скриптах есть динамически генерируемый html код и комбинации типа «</» встречается достаточно часто. Встречаются даже такие приёмы '</scr' + 'ipt>' чтобы парсер правильно нашёл конец блока.

mashina ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.