XSL：for-each 选择带有变音符号的字符串
我有以下 XML：
<FeatureGroup FeatureGroup="Bundesländer">
<Feature>
<FeatureValue>
<Value LanguageCode="fr">Brandenburg</Value>
<Value LanguageCode="de">Brandenburg</Value>
<Value LanguageCode="en">Brandenburg</Value>
</FeatureValue>
</Feature>
</FeatureGroup>
我希望它由 xsl 转换，但我无法选择功能组值“Bundesländer”。这是 xsl：
<field name="federalState">
<xsl:for-each select="FeatureGroups/FeatureGroup[FeatureGroup = 'Bundesländer']">
<xsl:for-each select="Feature/FeatureValue/Value[@LanguageCode= 'de']">
<xsl:value-of select="." />
</xsl:for-each>
</xsl:for-each>
</field>
如何选择其中包含变音符号的属性值？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
XML 和 XPath 完全支持 Unicode，因此选择任何 Unicode 字符都不是问题，您只需确保您的路径选择带有
@的属性节点，即替换Well XML and XPath have full support for Unicode so selecting any Unicode character is not a problem, you simply need to make sure your path selects the attribute node with
@i.e. replace<xsl:for-each select="FeatureGroups/FeatureGroup[FeatureGroup = 'Bundesländer']">by<xsl:for-each select="FeatureGroups/FeatureGroup[@FeatureGroup = 'Bundesländer']">.如果您在以正确的编码保存文件时遇到问题（如 Sjoerd 的评论中所建议的），您可以随时使用
“变音实体”（与 HTML 中相同）：
在这里您可以找到完整的列表。
If you have problems to save your file in a proper encoding (as suggested in the comment by Sjoerd), you can always use
"Umlaut entities" (same as in HTML):
Here you find a complete list.
事实证明这不是你的问题，但一种理论上的可能性是重音字母有两种 Unicode 表示形式：一种是单个 Unicode 代码点（组合形式），另一种是两个 Unicode 代码点（分解形式）。在 XPath 1.0 中，它们不会比较相等。在 XPath 2.0 中，它们可能比较相等，也可能不相等，具体取决于默认排序规则（与处理器相关）。
我将这个问题描述为理论问题，因为我从未在实践中真正看到过它的出现。我认为这是因为大多数工具都会生成字符的组合形式，除非您不遗余力地获得分解形式。
It turns out this wasn't your problem, but one theoretical possibility is that there are two Unicode representations of an accented letter: one as a single Unicode codepoint (composed form) and one as two Unicode codepoints (decomposed form). In XPath 1.0 they won't compare equal. In XPath 2.0, they may or may not compare equal, depending on the default collation, which is processor-dependent.
I describe this problem as theoretical because I've never actually seen it arise in practice. I think that's because most tools generate the composed form of characters unless you go out of your way to get the decomposed form.