Parser vs.Lexer und XML

Question

Ich lese gerade über die Architektur von Compilern und Parsern und frage mich über eine Sache ...Wenn Sie über XML, XHTML, HTML oder eine andere SGML-basierte Sprache verfügen, Was wäre die Rolle eines Lexer hier und was wären die Token?

Ich habe gelesen, dass Token so sind Wörter zum Parsen vorbereitet Lexer.Obwohl ich kein Problem damit habe, Token für die Sprachen C, C++, Pascal usw. zu finden, in denen Schlüsselwörter, Namen, Literale und andere wortähnliche Zeichenfolgen durch Leerzeichen getrennt sind, habe ich mit XML ein Problem, weil es solche gibt. Keine Worte!Es handelt sich lediglich um einfachen 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]....Das wäre durchaus sinnvoll, da es SGML egal ist, was in den Markup-Trennzeichen steht < Und > (Nun, es erkennt spezielle Verarbeitungsanweisungen und Definitionen, wenn es gefunden wird ? oder ! als nächstes Zeichen;Kommentare gehören ebenfalls zu dieser Gruppe), und der SGML-Tokenizer könnte eine Basis für den XML/HTML/XHTML-Parser sein.

Aber dann wurde mir klar, dass es das geben kann < Zeichen, die als Teil einer anderen Syntax in das Markup eingefügt werden:Attributwerte :-/ Auch wenn das keine ganz gute Idee ist < Zeichen innerhalb von Attributwerten (es ist besser zu verwenden < dafür), beschäftigen sich viele Browser und Editoren damit und behandeln diese < als Teil des Attributwerts, nicht als Tag-Trennzeichen.

Das macht die Sache etwas komplizierter, weil ich keine Möglichkeit sehe, solche Markups durch einen einfachen Deterministic Finite Automaton (DFA) im Lexer zu erkennen.Es sieht so aus, als ob ein separater Kontext für den Automaten erforderlich ist, wenn er sich innerhalb des Tags befindet, und ein anderer Kontext, wenn er auf einen Attributwert trifft.Ich denke, dafür wäre ein Stapel von Zuständen/Kontexten erforderlich, sodass DFA das möglicherweise nicht bewältigen kann.Habe ich recht?

Was ist Ihre Meinung?Ist es sinnvoll, Token aus Tags (Markup) und einfachem Text zu erstellen?

Hier: http://www.antlr.org/wiki/display/ANTLR3/Parsing+XML
wird eine andere Technik verwendet:sie behandeln < Und > (und auch </ Und />) als separate Token und innerhalb der von ihnen verwendeten Tags GENERIC_ID als Token usw. Sie verlagern im Allgemeinen den größten Teil der Arbeit auf den Parser.Sie müssen aber auch den Kontext für den Tokenizer ändern:Sie verwenden einen anderen Kontext im Klartext und einen anderen im Markup (aber ich glaube, sie haben den Kontext der Attributwerte vergessen, weil er zum ersten Mal vorkommt > beendet das Tag in ihrem Lexer).

Was ist also der beste Ansatz zum Parsen von SGML-ähnlichen Sprachen?Wird der Lexer dort wirklich verwendet?Wenn ja, aus welchen Zeichenfolgen bestehen die Token?

Answer 1

Nachdem ich XML- und HTML-Parser erstellt habe, habe ich Meinungen.

Lexeme sollten im Allgemeinen erkennbare Sprachelemente sein.

Für XML und HTML entsprechen diese grundsätzlich

• TAGBEGIN, Dinge der Form von <NAME
• TAGEND, in der Form von >
• TAGCLOSE, in der Form von </NAME>
• TAGENDANDCLOSE des Formulars /> (Nur XML)
• ATTRIBUTENAME, in der Form von NAME
• EQUALSIGN, präzise sein =
• ATTRIBUTEVALUE ist der Wert der genauen Zeichenfolge, die durch ein Attribut dargestellt wird, unabhängig von Anführungszeichen (oder sogar der Abwesenheit von Anführungszeichen bei älterem HTML).Wenn das Attribut maskierte Zeichencodes enthält, sollten diese Codes in den tatsächlichen Zeichencode konvertiert werden.
• CONTENT, das ist der Text zwischen TAGENDs und TAGBEGINs.Wie bei ATTRIBUTEVALUES sollten alle Escape-Zeichen konvertiert werden, also der INHALT dazwischen <B>foo<bar</B> wird in den Text umgewandelt foo<barWenn Sie die Entitätsaufrufe als separate Token behalten möchten, können Sie dies tun und Streams von CONTENT- und ENTITYINVOCATION-Tokens zwischen TAGENDs und TAGSTARTs erzeugen.hängt davon ab, was Ihr Ziel ist.

Wir können darüber streiten, ob Sie ein Token für HTML/XML-Kommentare erstellen möchten oder nicht.Wenn ja, dann tun Sie es.

Wenn wir die Komplikationen von DTDs und Schemas für XML außer Acht lassen, ist das alles, was Sie wirklich brauchen.

Wie der Lexer produziert das ist komplizierter;Bei XML und HTML gibt es viel Chaos im Zusammenhang mit Escapezeichen im Eingabestream, <[CDATA ...]> (wenn ich das recht habe), was nur ein lustiges Zitat ist und verschwindet, wenn das CONTENT-Lexem erzeugt wird.Um all dies zu bewältigen, benötigen Sie eine ziemlich ausgefeilte Lexer-Engine.Und ja, aus praktischen Gründen benötigen Sie unterschiedliche lexikalische Zustände („Modi“), um verschiedene Teile des Textes zu verarbeiten.Ich habe so ziemlich einen Hauptmodus, um Dinge in mir zu verarbeiten <...>, und einen Hauptmodus zum Verarbeiten von INHALTEN.