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

使用非ASCII自然语言编写的XML标记（元素名称）合适吗？XML规范允许这样做（请参阅和），但我在和相关页面上找不到任何关于这方面的最佳实践

我想要的是关于哪些工具支持这一点的实用建议，以及诸如XSLT和XForms等重要的XML相关技术是否存在问题，等等

我认为安德烈和托马拉克没有抓住重点。XML不一定由程序员阅读，而是由许多不同的专业人士阅读。因此，将其与源代码进行比较的论点不一定适用

让我澄清一下：我指的是保加利亚法律领域，其中许多术语是特定于保加利亚法律程序的，甚至可能没有准确的英文翻译。翻译它们将是费力、不精确和不切实际的。音译为ASCII是次优的

那么回到问题上来：我将面临哪些工具限制？（Eclipse支持UTF，因此编写XPath不会有问题。）

让人们从我想要的技术方向开始：在一些系统中，我们使用了生成技术来确保XML模式、JavaBean和数据库模式之间的完美对应

• Java：说Unicode是可以的
• 甲骨文：
• 我必须检查我们使用的工具（JibX、Dozer、Hibernate、JXPath…）

---

简短回答：您可以随意命名XML元素
稍长一点的回答：如果您想使用最可移植/可维护的XML，可能应该使用仅限ASCII的元素名称。我想不出有什么好的理由在元素名中使用其他字符，这当然有助于在各种场合处理XML

---

考虑使用一些不一定对其源代码文件进行UTF-8编码的编程语言来处理XML节点。例如，用这种语言编写工作XPath表达式会很困难。或者不使用元素名称所使用的语言，但负责源代码的维护人员/程序员。例如，当您的元素名是西里尔字母脚本时，您就有点把自己锁定了。元素名称应该具有结构和含义，没有明显的理由排除ASCII用于此目的。
这取决于您和您的开发规则。但是XML标记名应该易于阅读和理解。即使是在某个时候加入你的人也应该得到它。因此，最好按照适当的命名约定命名它们
检查下面的示例

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

---

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

---

这将有助于区分支持XML的工具和声称支持XML的工具，而实际上不支持XML的工具。
如果文档的内容是保加利亚文的，那么标记应该可以使用
如果您的工具链无法解析该语言中的标记，那么您如何确保它正确处理了内容

---

程序员必须始终学习目标领域的语言，无论是金融、遗传学、工程学还是保加利亚法律体系。为了方便程序员而牺牲可用性几乎总是一件“坏事”。无论在前端节省了多少精力，最终都会因为最终用户的生产效率和产品生命周期内的支持工作量/成本而丢失。
我很抱歉这么说，但是如果您的非技术用户需要读取原始XML，则您的应用程序将被破坏。而且您存储的数据通常也不会与用户消息有1-1的对应关系：许多内容以冗余方式存储在XML上，而其他内容则是从数据中隐式存储的
对我来说，我认为应该，是的，使用UTF-8字符集以保加利亚语存储所有XML数据。但是在属性中，而不是在XML标记结构中
我在想：你可以设计你的程序，这样任何法律结构都可以从用户界面上自由修改（可能在一个特殊的“管理”面板上，但仍然远离代码），而不是硬编码到文件格式。这是因为法律改变了，判例也改变了，法律术语也可能改变。（好吧，有些人没有）
这可能使您能够创建一个相当通用的文件格式（考虑一下美国或日本也可以使用的格式-即使您不打算实际这样做，这样您在设计灵活的文件格式时所做的更改将更大）
这可能更难。您需要准备好处理不一致、不完整或糟糕的数据。但无论如何，你应该这样做。你可能也会得到回报：文件格式可能更干净、更经得起未来考验，使你的软件更加灵活。也许不是。注意这里的五月和五月。这实际上取决于您具体的设计权衡
当然，你需要在这里保持平衡。归根结底，设计一个可靠、灵活的系统的负担就在你身上。你可以用保加利亚语写标签。我来自巴西，我觉得像这样的想法很奇怪，但它可以奏效
关于您对工具限制的实际担忧：我不知道。您应该首先查找您最喜欢的XML库的文档，看看它是否大胆地宣称支持它。即使是最常用的程序也可能不完全支持使用不多的功能
我将面临哪些工具限制
如果我没记错的话，XML名称中允许的字符集最初在XML 1.0和XML 1.1中是不同的，后者也允许一些以前被排除在外的东南亚脚本。XML 1.0建议的第五版（=最新版本）发生了变化，现在允许的na也发生了变化