使用非ascii(自然语言)xml标记合适吗?

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

如果您的工具链无法解析该语言中的标记,那么您如何确保它正确处理了内容?

无论是金融、遗传学、工程学还是保加利亚法律体系,程序员都必须学习目标领域的语言。为了程序员的方便而牺牲可用性几乎总是一件坏事。在产品的整个生命周期中,无论预先节省了多少精力,最终都会因为妨碍了最终用户的生产效率和支持努力/成本而丢失。

简而言之:您可以随意命名XML元素。

稍微长一点的答案是:如果您想使用最可移植/维护的xml,那么您可能应该使用仅限于ascii的元素名。我想不出在元素名中使用其他字符的好理由,这当然有助于在各种地方处理xml。

考虑使用一些编程语言来处理xml节点,这些语言不一定对其源代码文件进行utf-8编码。例如,用这种语言编写工作的xpath表达式会很困难。或者不使用元素名所使用的语言,但负责源代码的维护人员/程序员。例如,当您的元素名是西里尔文脚本时,您可以将自己锁定在其中。元素名应该包含结构和含义,没有明显的理由可以排除ascii。

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

这将有助于将支持XML的工具与声称支持XML但实际上不支持XML的工具分离开来。

很抱歉这么说,但是如果您的非技术用户需要读取原始XML,那么您的应用程序将被破坏。而且您存储的数据通常也不会与用户消息有1-1的对应关系:许多东西在xml上以冗余的方式存储,而其他东西则是从数据中隐式存储的。

对我来说,我认为您应该,是的,使用utf-8字符集以保加利亚语存储所有xml数据。但是在属性中,而不是在xml标记结构中。

我在想:你可以设计你的程序,这样任何合法的结构都可以从用户界面上自由修改(也许在一个特殊的“管理”面板上,但仍然远离代码),而且决不能硬编码成文件格式。究其原因,既有法律变迁的原因,也有法理变迁的原因,也有法律条款变迁的原因。(好吧,有些人没有)

这可能使您能够创建一个相当通用的文件格式(也可以考虑一个可以在美国或日本使用的格式—即使您不打算实际使用,这样您在设计灵活的文件格式时所做的更改将更大)

这可能更难。您需要准备好处理不一致、不完整或差的数据。但无论如何,你应该这么做。你可能也会得到回报:文件格式可以更干净,更经得起未来的考验,使你的软件更加灵活。或许不是。注意这里的五月。这实际上取决于你的具体设计权衡。

当然,你需要在这里保持平衡。归根结底,设计一个可靠、灵活的系统是你的负担。你可以用保加利亚语写标签。我来自巴西,我觉得想一想很奇怪,但这是可行的。

关于你对工具限制的实际担忧:我不知道。您应该首先查找您最喜欢的xml库的文档,看看它是否大胆地宣称支持它。即使是最常用的程序也可能不完全支持一个不常用的特性。

这取决于你和你的发展规则。但是XML标记名应该很容易被每个人阅读和理解。即使是在某个时间之后加入你的人也应该得到它。所以最好按照正确的命名约定来命名。

检查下面的示例。

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

谢谢。

我将面临哪些工具限制?

如果我没记错的话,xml名称中允许的字符集在xml 1.0和xml1.1中最初是不同的,后者还允许一些以前被排除在外的东南亚脚本。第五版(即最新版本)的xml 1.0推荐标准发生了变化,现在允许的名称字符是相同的。所以至少 理论上 如果某些声称与xml 1.0兼容的工具检查名称字符的有效性,并且只符合xml1.0的第四版,则这些新的允许字符可能有问题。

但在您的情况下,如果您只使用ascii和保加利亚字符,这个问题只是理论上的。