Ich lese jetzt über Compiler und Parser-Architektur und ich frage mich über eine Sache ... Wenn Sie XML, XHTML, HTML oder eine beliebige SGML-basierte Sprache haben, Was wäre die Rolle eines Lexikers und was wären die Tokens?
Ich habe gelesen, dass Token wie Wörter sind, die vom Lexer für die Analyse vorbereitet werden. Obwohl ich keine Probleme habe, Token für die Sprachen C, C ++, Pascal usw. zu finden, wo es Schlüsselwörter, Namen, Literale und andere wortähnliche Strings gibt, die durch Leerzeichen getrennt sind, habe ich mit XML ein Problem, weil es keine t irgendwelche Worte! Es ist nur einfacher Text, der mit dem Markup (Tags) verschachtelt ist.
Ich dachte mir, dass es sein könnte, dass diese Tags und Klartextfragmente die Token sind, etwa so: [TXT][TAG][TAG][TXT][TAG][TXT][TAG][TAG][TXT]... . Es wäre ziemlich vernünftig, da es SGML egal ist, was sich in den Markup-Trennzeichen < und > befindet (gut, es erkennt spezielle Verarbeitungsanweisungen und Definitionen, wenn es ? oder ! als nächstes Zeichen findet; Kommentare gehören auch zu dieser Gruppe), und der SGML-Tokenizer könnte eine Basis für den XML / HTML / XHTML-Parser sein.
Aber dann erkannte ich, dass < -Zeichen innerhalb des Markups als Teil anderer Syntax gefüllt sein können: Attributwerte: - / Auch wenn es nicht ganz gut ist, < -Zeichen innerhalb von Attributwerten zu setzen (es ist besser um < dafür zu verwenden, gehen viele Browser und Editoren damit um und behandeln diese < als Teil des Attributwertes, nicht als Tagbegrenzer.
Es verkompliziert die Dinge ein wenig, weil ich keine Möglichkeit sehe, Markups wie diese durch einen einfachen Deterministischen Finiten Automaten (DFA) im Lexer zu erkennen. Es sieht so aus, als benötige es einen separaten Kontext für den Automaten, wenn er sich innerhalb des Tags befindet, und einen anderen Kontext, wenn er auf einen Attributwert stößt. Dies würde einen Stapel von Zuständen / Kontexten erfordern, denke ich, so dass DFA das möglicherweise nicht verarbeiten kann. Habe ich Recht?
Was ist Ihre Meinung? Ist es gut, Token aus Tags (Markup) und reinem Text zu machen?
Hier: Ссылка
ist eine Art unterschiedliche Technik: Sie behandeln < und > (und auch </ und /> ) als separate Tokens, und innerhalb der Tags verwenden sie GENERIC_ID als ein Token etc. Sie bewegen die meisten von die Arbeit an den Parser. Aber sie müssen auch die Kontexte für den Tokenizer ändern: Sie verwenden einen anderen Kontext im Klartext und einen anderen im Markup (aber sie haben den Attributwertkontext vergessen, weil das erste Vorkommen von > das Tag in ihrem Lexer beendet) .
Was ist der beste Ansatz für die Analyse von SGML-ähnlichen Sprachen? Wird der Lexer dort wirklich benutzt? Wenn ja, welche Strings bilden die Token?
Nachdem ich XML- und HTML-Parser erstellt habe, habe ich Meinungen.
Lexeme im Allgemeinen sollten erkennbare Sprachelemente sein.
Für XML und HTML entsprechen diese grundsätzlich
Wir können darüber streiten, ob Sie ein Token für HTML / XML-Kommentare erzeugen wollen oder nicht. Wenn Sie das tun, tun Sie das.
Wenn wir die Komplikationen von DTDs und Schemas für XML ignorieren, ist das alles, was Sie wirklich brauchen.
Wie der Lexer erzeugt ist das komplizierter; Bei XML und HTML gibt es eine Menge Probleme mit Escapes im Eingabestream, & lt; [CDATA ...] & gt; (wenn ich das richtig habe) das ist nur eine lustige Art von Zitat und verschwindet, wenn das CONTENT-Lexem produziert wird. Um all dies zu bewältigen, benötigen Sie eine ziemlich anspruchsvolle Lexer-Engine. Und ja, in der Praxis benötigen Sie verschiedene lexikalische Zustände ("Modi"), um verschiedene Teile des Textes zu bearbeiten. Ich habe so ziemlich einen Hauptmodus, um Dinge innerhalb von & lt; ... & gt; zu verarbeiten, und einen Hauptmodus, um CONTENT zu verarbeiten.