Opis skła­d­ni HTML: ko­men­ta­rze. O co uzu­peł­nić? [ankieta]

Question

Tu­taj jest opis skła­d­ni HTML ogra­ni­czo­ny do po­trzeb wy­cią­ga­nia war­to­ś­ci atry­bu­tów href i src zna­cz­ni­ków link i img. Je­d­nak jest w nim błąd wy­ni­kają­cy z obe­c­nie nie­moż­li­wo­ś­ci za­pi­su skła­d­ni. Ten błąd to de­fi­ni­cja:

znacznik komentarza
    "<!--"
    /[^>]*/
    "-->"

Błąd pole­ga na tym, że za­war­tość zna­cz­ni­ka ko­men­ta­rza może za­wie­rać znak >, a nie może za­wie­rać tek­stu -->. Dla­te­go chciał­bym uzu­peł­nić ję­zyk opi­su skła­d­ni o ele­ment, któ­ry po­zwoli zde­fi­nio­wać, że za­war­tość nie może za­wie­rać po­da­ne­go tek­stu.

Przy­szy­ły mi na my­śl dwa ro­zwią­za­nia:

1. Do­dać ele­ment ty­pu gwia­zdka, któ­ry zbie­rał­by jak naj­mniej tek­stu przed wys­tą­pie­niem w tek­ście kolej­ne­go ele­men­tu:

znacznik komentarza
    "<!--"
    *
    "-->"

2. Do­dać ele­ment ty­pu za­ne­go­wa­ny tek­st bądź za­ne­go­wa­ne wy­raże­nie re­gula­r­ne, któ­ry zbie­rał­by jak naj­mniej tek­stu przed wys­tą­pie­niem po­da­ne­go tek­stu lub wy­raże­nia re­gula­r­ne­go, ale te­go po­da­ne­go tek­stu lub wy­raże­nia re­gula­r­ne­go nie zbie­rał:

znacznik komentarza
    "<!--"
    !"-->"
    "-->"

bądź

znacznik komentarza
    "<!--"
    !/-->/
    "-->"

A może jest je­sz­cze le­p­sze ro­zwią­za­nie?

Możliwe odpowiedzi:

Do­daj gwia­zdkę (0 głosów)

Do­daj za­ne­go­wa­ny tek­st (0 głosów)

Do­daj za­ne­go­wa­ne wy­raże­nie re­gula­r­ne (1 głos, 100%)

Answer 1

Ze składnią HTML-a jest taki problem, że ona niekoniecznie jest regularna i same komentarze można zapisywać na wiele różnych sposobów:

<!-- -->
<!-- --!>
<!- ->
<!- !->

Wszystkie te sposoby są interpretowane przez przeglądarkę jako komentarze, mimo że część z nich jest w teorii niepoprawna składniowo (a to dlatego, że specyfikacja HTML przy opisie parsera ma też cały algorytm do obsługi błędów i tego typu rzeczy są dokładnie rozpisane).

Tak samo zresztą przy zapisie elementów:

<LiNk
hreF

		   =

https://www.comandeer.pl


	rEl=                    "    canonical"
	
	
/>

To wciąż poprawny element link, ale tak na oko Twój syntax go nie sparsuje, bo nie bierzesz pod uwagę choćby odstępów między nazwą a wartością atrybutu.

IMO najsensowniejszy sposób na parsowanie HTML-a to wykorzystanie parsera, względnie napisanie własnego, uproszczonego, na podstawie dokładnego algorytmu w specyfikacji. Niemniej, jeśli nie chcesz rezygnować z istniejącego rozwiązania na wyrażeniach regularnych, to dodałbym do składni zanegowanie wyrażenia regularnego. Albo, IMO jeszcze lepiej, zanegowanie innego fragmentu składni:

znacznik komentarza
    "<!--"
    !zakonczenie komentarza
    zakonczenie komentarza

zakonczenie komentarza
    "-->" | "inne wersje"

Zastanawia mnie też, po co Ci wgl parsowanie tych elementów HTML w serwerze HTTP? Zgaduję, że jest to związane z obsługą HTTP/2 pusha. Jeśli tak, to… IMO nie ma sensu w to za bardzo inwestować, bo HTTP/2 push jest przeznaczony do ubicia. Tym bardziej, że w HTTP/3 działa zupełnie inaczej. Ten z HTTP/2 ma sporo problemów, m.in. nie istnieje sensowny mechanizm kontrolowania, czy dany zasób już pushowaliśmy. A to oznacza, że będziemy marnować transfer albo implementować wymyślne mechanizmy, które będą to dla nas sprawdzać.

Ciekawi mnie też fragment sprawdzający, czy plik zaczyna się od DOCTYPE lub html. Jeśli ma to służyć wykryciu plików HTML, to IMO bym z tym uważał, bo mogą zdarzać się dokumenty HTML niezaczynające się ani od jednego, ani od drugiego. Tak, będą niepoprawne składniowo, ale przeglądarki wciąż je odczytają. Sam znacznik html jest opcjonalny, a brak DOCTYPE powoduje jedynie włączenie trybu quirks. Jedynym sensownym sposobem wykrywania dokumentów HTML jest sprawdzanie ich typu MIME.

Comments

Dzięki za rzeczową odpowiedź.

Wyrażenia regularne to tylko metoda wykrywania treści w tym parserze: po niezajściu wyrażenia regularnego (tak jak też tekstu lub innego rodzaju treści) jest próbowana następna alternatywa z definicji. Tak że wyrażenie regularne nie musi zajść. Może istnieć na przykład coś takiego:

początek komentarza:
    "<!--" | "<!-"

i to jest poprawnie parsowane.

W takim razie jeśli utworzyłbym składnię HTML uwzględniającą błędy, to wtedy byłoby poprawnie, ale to wymaga trochę pracy, bo pewnie opis jest zbudowany jako opis zachowań przy błędach do poprawnej składni.

Tak, dla obsługi pusha zrobiłem parsowanie HTML w serwerze, ale bez względu na to, że może być przestarzały, to jest to dla mnie jakieś zastosowanie parsowania bardziej zaawansowanego niż pliki konfiguracyjne, tzn. mogę przetestować i sprawdzić jak zmienić parser. Ponieważ parser jest ogólny, jako funkcja biblioteczna, nie przynależny do serwera.

Co do wykrywania dokumentów HTML, to nie ufałbym typowi MIME, tylko próbowałbym parsować (przy użyciu pełnego opisu), o ile treść wygląda na HTML. Ale chyba o to samo chodzi.

Zastanawiałem się nad gwiazdką i też podobnym do tego negowaniem fragmentu składni, ale według mnie w tych przypadkach treść za bardzo zależałaby od bieżącej struktury opisu składni. Myślę, że wprowadzę negowanie wyrażenia regularnego i później zobaczę, co zrobić więcej. No i wstępnie sprawdzę, czy da się zdefiniować HTML uwzględniając błędy.