使用非ASCII（自然语言）XML标签是否合适？

使用以非ASCII自然语言编写的XML标记（元素名称）是否合适？ XML规范允许它（请参阅Names和Exceptions），但我无法在W3C和相关页面找到任何关于此的最佳实践。使用非ASCII（自然语言）XML标签是否合适？

我正在寻找的是关于实际的建议哪些工具支持这一点，重要的XML相关技术，如XSLT和XForms是否可能有它的问题，等等。

我觉得安德烈和托默勒格缺少点。 XML不一定被程序员阅读，它被许多不同的专业人士阅读。所以将它与源代码进行比较的论据不一定适用。

让我澄清一下：我的意思是一个保加利亚法律域，其中许多术语都是保加利亚法律程序特有的，甚至可能没有准确英文翻译。翻译它们会很费力，不精确和不切实际。音译为ASCII是不理想的。

回到问题：我会面对哪些工具限制？（Eclipse支持UTF，因此编写xpaths不会成为问题。）

为了让人们从技术角度开始，我希望在几个系统中使用生成技术来确保XML模式之间的完美对应，Java bean和数据库模式。

的Java：this article说，统一是确定
甲骨文：identifiers can contain only alphanumeric characters from your database character set
我不得不检查我们使用（JIBX，推土机，休眠，...的JXPath）模具

来源

2010-05-20 Vladimir Alexiev

如果非开发人员看到您的XML标签，那么您做错了。 – 2010-05-24 03:54:32

这是一个坏主意，因为给本地语言的变量赋予名字。大多数开发人员会自动使您的程序无法读取。

来源

2010-05-20 11:33:14 Andrey

XML <>程序。 XML经常被开发人员以外的开发人员读取 – 2010-05-24 03:18:10

@Vladimir Alexiev用专业人员取代词语开发人员，意思将保持不变。 – Andrey 2010-05-24 10:47:07

我确定保加利亚语法律领域的系统不会被保加利亚语发言人触动（nee开发） – 2010-11-24 10:21:54

简短回答：您可以任何方式为您的XML元素命名。

稍微长一些的答案：如果您想使用最便携/可维护的XML，您应该使用仅限ASCII的元素名称。我可以想象在元素名称中使用其他字符没有什么好的理由，并且它肯定有助于在各种场所处理XML。

想想用一些编程语言来处理XML节点，这些编程语言不一定有其源代码文件UTF-8编码。例如，用这样的语言编写工作XPath表达式就会很困难。或者不说你的元素名所在的语言，但负责源代码的维护者/程序员。例如，当您的元素名称使用西里尔文脚本时，您可以将自己锁定。元素名称应该带有结构和含义，并且没有明显的理由会为此排除ASCII。

来源

2010-05-20 11:39:57 Tomalak

我想知道，如果拉丁字母与西里尔字母一样对你来说是外来的，是。 – 2010-05-20 11:44:58

@Michael：看到我的“简答”。除此之外。如果拉丁字母与西里尔字母对我来说如此陌生（我可以阅读西里尔语，顺便说一下），那么你很可能不是程序员，并且首先不涉及XML文件的问题。这与我个人接触外部脚本或另一个外部脚本无关，在涉及与计算机通信时，ASCII *是最不常见的分母。 – Tomalak 2010-05-20 12:04:58

这取决于你和你的发展规则。但是，XML标签名称应该容易被所有人阅读和理解。即使是那个在某个时候加入你也应该正确地得到它。最好按照适当的命名约定命名它们。

检查下面的例子。

<user name="hero">  
    <address> 
    <street></street>  
    </address>  
</user>

谢谢。

来源

2010-05-20 12:13:48 Parth

“适当的命名约定”并不意味着“排除西里尔文”和“每个人都能理解”并不意味着“英文读者，也许开发人员”。保加利亚法律专业人士如何？ – 2010-05-24 03:16:29

用您喜欢的任何语言编写您的XML。确保编码支持您正在使用的字符集，并确保您在XML处理指令中声明了正确的编码。

这将有助于将支持XML的工具与声称这样做的工具分开，而实际上哪些工具不支持。

来源

2010-05-24 03:20:44

+1，但我认为弗拉基米尔的问题更符合'哪些常见的XML工具对非拉丁标签有技术问题（尽管规范允许它们）？'。 – whybird 2010-05-24 04:27:00

我不知道有任何这样的问题。任何有问题的人都应该公开并公开嘲笑。 – 2010-05-24 05:03:41

完全同意.. – whybird 2010-05-25 00:19:20

如果文档的内容将在保加利亚语中，那么标记应该是可以的。

如果您的工具链无法解析该语言中的标签，那么您如何确定它正确地处理内容？

程序员将永远需要学习目标领域的语言，无论是金融，遗传学，工程学还是保加利亚法律体系。为了程序员的方便而妥协的可用性几乎总是一件'坏事'。无论什么样的努力最终都会因最终用户的生产力和产品的整个生命周期中的支持努力/成本而受到损失。

来源

2010-05-24 03:49:59

+1，这也是XML的设计目的！ :) – porges 2010-05-24 04:03:22

+1为正确的态度:-)但关于“你怎么能确定”：例如我确信Informix处理nvarchar字符串，但远不能确定它可以处理保加利亚表和列名 – 2010-11-24 10:20:40

我很抱歉地说，但如果您的非技术用户需要读取原始XML，那么您的应用程序已损坏。您存储的数据通常不会与用户消息产生1-1对应关系：许多事物以冗余方式存储在XML中，而其他数据则隐含在数据中。

对于我来说，我认为你应该使用UTF-8字符集将所有XML数据存储在保加利亚语中。但是在属性中，而不是在XML标签结构中。

我在想这个问题：你可以设计你的程序，这样任何合法的结构都可以从用户界面自由修改（也许在特殊的“管理”面板上，但离代码还很远），并且没有办法硬编码到文件格式。其原因是法律的变化，法理学的变化以及法律条款的变化。（嗯，有些没有）

这可能使您能够创建一个相当普遍的文件格式（想想一个可以在美国或日本使用，太 - 即使你真正做到这一点不打算，这样你的设计灵活的文件格式的变化会更大）

这可能会更难。您需要做好准备，处理不一致，不完整或其他数据不佳的情况。但无论如何，你应该这样做。而且你也可能会得到回报：文件格式可能更清晰并且面向未来，从而使您的软件更加灵活。或者可能不是。注意这里的mays，coulds。它实际上取决于您的具体设计折衷。

而且，当然，你需要在这里有一些平衡。在这一天结束时，设计一个可靠的，灵活的系统的负担就在你身上。您可以采用保加利亚语写入标签的方法。我来自巴西，我觉得奇怪的是想想像，但它可以工作。

有关工具限制您的实际忧虑：我不知道。您应该首先查找您最喜爱的XML库的文档，并查看它是否大胆声称支持它。即使是最常用的程序也可能不完全支持不太常用的功能。

来源

2010-05-24 04:09:13 user348635

为什么你在想“一个应用程序“？上下文是电子政务XML交换模式和规则的设计。当然我们会看看GJXDM和NIEM（美国已经做得很好，在IT中表达警察状态;-)。请注意，GJXDM/NIEM有许多美国的理念，例如“国际交换学生的明显学术术语”，所以它不是一个全球通用的合法XML模式。同样，保加利亚语中也有很多BG特定的法律概念。 – 2010-05-25 05:45:59

我将面临什么样的工具限制？

如果我没有记错，这组在XML名称中允许的字符原是XML 1.0和XML 1.1后者也允许一些先前排除的东南亚脚本不同。 XML 1的第五版（最新版）发生了变化。0建议，现在允许的名称字符是相同的。所以至少理论上可能有些工具被称为XML 1.0兼容，如果它们检查名称字符的有效性并且只符合XML 1.0的第四版，就会对这些新的允许字符产生问题。

但在你的情况下，这个问题仅仅是理论性的，如果你只使用ASCII和保加利亚字符。

来源

2010-10-08 16:46:13 jasso

使用非ASCII（自然语言）XML标签是否合适？

回答

相关问题