私は現在、コンパイラとパーサーのアーキテクチャについて読んでいますが、1 つのことについて疑問に思っています... XML、XHTML、HTML、または SGML ベースの言語を使用している場合、ここでのレクサーの役割とトークンは何でしょうか?
トークンは、 lexerによる解析用に準備された単語のようなものだと読んだことがあります。キーワード、名前、リテラル、その他の単語のような文字列が空白で区切られている C、C++、Pascal などの言語のトークンを見つけることに問題はありませんが、XML では問題があります。どんな言葉でも!これは、マークアップ (タグ) がインターリーブされたプレーン テキストのみです。
これらのタグとプレーンテキストの断片がトークンである可能性があると思いました[TXT][TAG][TAG][TXT][TAG][TXT][TAG][TAG][TXT]...
。SGML はマークアップ区切り文字の内部にあるものを気にせず<
(>
まあ、それが見つかったとき、?
または!
次の文字として特別な処理命令と定義を認識します。コメントもそのグループに属します)、SGML トークナイザーはXML/HTML/XHTML パーサーのベースになります。
しかし、その後、他の構文の一部としてマークアップ内に文字が詰め込まれる可能性があることに気付きました<
:エディターはそれを処理し、これらをタグ区切り文字ではなく、属性値の一部として扱います。<
<
<
レクサーの単純な決定論的有限オートマトン (DFA) によってそのようなマークアップを認識する方法が見当たらないため、少し複雑になります。オートマトンがタグ内にある場合は別のコンテキストが必要であり、属性値に遭遇した場合は別のコンテキストが必要なようです。これには状態/コンテキストのスタックが必要になると思うので、DFA はそれを処理しない可能性があります。私は正しいですか?
あなたの見解は?タグ(マークアップ)とプレーンテキストからトークンを作るのは良いですか?
ここ: http://www.antlr.org/wiki/display/ANTLR3/Parsing+XML
は、ある種の異なる手法を使用しています: それらは<
and >
(および and も</
)/>
を個別のトークンとして扱い、タグ内ではGENERIC_ID
トークンとして使用します。 .通常、ほとんどの作業をパーサーに移します。しかし、トークナイザーのコンテキストも変更する必要があります。プレーンテキストでは異なるコンテキストを使用し、マークアップでは異なるコンテキストを使用します (しかし、属性値のコンテキストを忘れていたと思います>
。
では、SGML に似た言語を解析するための最良のアプローチは何でしょうか? レクサーは本当にそこで使われていますか?はいの場合、どの文字列がトークンを構成していますか?