JFlex: Негативный прогноз в регулярном выражении
Отказ от ответственности: используйте парсер, если у вас есть опция. Тем не менее ...
Это регулярное выражение, которое я использую (!) Для соответствия тэгам HTML:
<(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+>
Это может быть не идеально, но я запустил этот код через lot HTML. Обратите внимание, что он даже ловит странные вещи, такие как , которые появляются в Интернете.
Думаю, чтобы он не соответствовал самодостаточным тегам, вы либо захотите использовать Kobi :
<(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+(?
или просто объединить, если и если нет.
To downvoters: Это рабочий код из реального продукта. Я сомневаюсь, что кто-либо читает эту страницу, создается впечатление, что социально приемлемо использовать регулярные выражения для HTML.
Предостережение. Я должен заметить, что это регулярное выражение все еще ломается при наличии блоков CD87, комментариев и элементов сценария и стиля. Хорошая новость заключается в том, что вы можете избавиться от тех, кто использует регулярное выражение ...
1 ответ
Неясно, возможно ли это в вашем случае, но моей первой реакцией на проблему такого рода обычно будет попытка переместить ее на один уровень выше лексера. То есть вместо лексера-токена NUMBER я бы вернул составляющие числа, например, {Digits}, ".", "^^" и т. Д., А затем объединить их либо в грамматику синтаксического анализатора (если он есть), либо в механизме синтаксического анализа, который вызывает лексер.
Обычный движок LR или LL на вершине может гораздо лучше справляться с прогнозом и контекстом, т. Е. В вашем примере все, что ниже Base, может уже перейти в анализатор вместо лексера.
По крайней мере, если вы хотите продолжить вычисление со значением числа, вам все равно придется более детально проанализировать сопоставленный текст для числа, потому что оно настолько сложное, что с этой точки зрения вы не потеряете что-нибудь.