解析器与词法分析器和XML

发布时间：2020-12-16 07:49:59 所属栏目：百科来源：网络整理

导读：我现在正在阅读有关编译器和解析器架构的内容,我想知道一件事…… 当您拥有 XML,XHTML,HTML或任何基于SGML的语言时,词法分析器的作用是什么以及令牌是什么？我已经读过,令牌就像为词法分析器准备的单词一样.虽然我没有找到用于语言行C,C,Pascal等的令牌的问

我现在正在阅读有关编译器和解析器架构的内容,我想知道一件事……
当您拥有 XML,XHTML,HTML或任何基于SGML的语言时,词法分析器的作用是什么以及令牌是什么？

我已经读过,令牌就像为词法分析器准备的单词一样.虽然我没有找到用于语言行C,C,Pascal等的令牌的问题,其中有关键字,名称,文字和其他由空格分隔的类似字符串的字符串,但是我有一个问题,因为没有任何话！它只是与标记(标签)交错的纯文本.

我心里想,可能是这些标签和纯文本片段都是令牌,类似的东西：[TXT] [TAG] [TAG] [TXT] [TAG] [TXT] [TAG] [TAG] [TXT] ….这是非常合理的,因为SGML并不关心标记分隔符中的内容<和> (当它发现？或！作为下一个字符时,它识别特殊处理指令和定义;注释也属于该组),并且SGML标记化器可以是XML / HTML / XHTML解析器的基础.

但后来我意识到可以有<作为其他语法的一部分填充在标记内的字符：属性值： - /即使放入<属性值中的字符(最好使用& lt;为此),许多浏览器和编辑处理这些并处理这些<作为属性值的一部分,而不是标记分隔符. 它使事情变得复杂,因为我没有看到通过词法分析器中的简单确定性有限自动机(DFA)识别标记的方法.看起来它需要一个单独的自动机上下文,当它在标签内时,另一个上下文遇到一个属性值时.这需要一堆我认为的状态/上下文,所以DFA可能无法处理.我对吗？你有什么看法？从标签(标记)和纯文本制作令牌是否合适？这里：http://www.antlr.org/wiki/display/ANTLR3/Parsing+XML
使用某种不同的技术：他们治疗<和> (以及< /和/>)作为单独的标记,并且在标记内部,它们使用GENERIC_ID作为标记等.它们通常将大部分工作移动到解析器.但是他们还必须改变标记化器的上下文：它们在纯文本中使用不同的上下文,在标记中使用不同(但是他们忘记了属性值上下文我认为,因为>的第一次出现将在它们的词法分析器中结束标记).

那么解析类SGML语言的最佳方法是什么？那个词法分析器真的用在那里吗？如果是,那么代币是什么字符串？

构建XML和HTML解析器后,我有意见.

Lexemes一般应该是可识别的语言元素.

对于XML和HTML,这些基本上对应于

> TAGBEGIN,< NAME形式的东西
> TAGEND,形式为>
> TAGCLOSE,形式为< / NAME>
> TAGENDANDCLOSE形式/> (仅限XML)
> ATTRIBUTENAME,形式为NAME
> EQUALSIGN,正是=
> ATTRIBUTEVALUE,是属性所代表的确切字符串的值,不管引号(或甚至没有引号,对于旧HTML).如果属性中有转义的字符代码,则应将这些代码转换为实际的字符代码.
>内容,这是TAGEND和TAGBEGIN之间的文字.与ATTRIBUTEVALUES一样,任何转义字符都应该被转换,因此< B> foo& lt; bar< / B>之间的内容转换为文本foo< bar
如果您希望将实体调用保持为单独的令牌,则可以这样做,在TAGEND和TAGSTART之间生成CONTENT和ENTITYINVOCATION令牌流;取决于你的目标是什么.

我们可以争论是否要为HTML / XML注释生成令牌.如果你这样做,那你就做了.

如果我们忽略了DTD和XML的Schema的复杂性,那就是你真正需要的.

词法分子如何产生这些更复杂;使用XML和HTML,与输入流中的转义有很多混乱,< [CDATA ...]> (如果我有这个权利)这只是一种有趣的引用,并在内容词汇产生时消失.要处理这一切,你需要一个非常复杂的词法引擎.是的,作为实际问题,你需要不同的词汇状态(“模式”)来处理文本的不同部分.我几乎有一个主要模式来处理< ...>内部的事情,以及一个处理CONTENT的主要模式.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!