3.4 与应用程序有关的问题

3.4.1 显示和网络顺序

通常情况下，域名会按照网络顺序（在协议中发送字符的顺序）传输，但可能有不同的显示顺序（在屏幕或者纸张上显示字符的顺序称为显示顺序）。当域名包含从右到左的字符时，尽管网络顺序不会受到影响，但显示顺序会受到影响。如果域名中从左到右的字符和从右到左的字符相邻，那么情况就会变得比较复杂。显示顺序由用户客户端控制，如浏览器、电子邮件客户端、主机网络应用程序等因素都会影响显示顺序。

当在国际化资源标识符（Internationalized Resource Identifiers，IRI）中出现IDN时，显示顺序会再次发生变化（见RFC 3987）。国际化资源标识符或者国际化电子邮件地址包含了各种字符，如国际化资源标识符包含协议标识符（“http：//”）和字段定界符（“mailto：”），当电子邮件地址包含“＠”时，会将本地部分从域名中分离出来。应用程序开发者必须选择国际化资源标识符或者国际化电子邮件地址中的字符是从左到右的还是从右到左的。例如，域名“abc.def”，如果是从右到左的字符，则域名的输入顺序是fed.cba。如果字符是从右到左（RTL）的，那么在输入域名时是否每次都应当颠倒整个域名呢？在输入域名之前，如果输入“http：//”，那么情况是否会发生改变？这是否意味着用户要以网络顺序的国际化资源标识符作为开头呢？根据20世纪80年代和90年代关于组合系统的经验，在网络顺序（从左到右）中的域名中使用显示顺序（从右到左）的字符时会发生混淆。如果每个应用程序都在这些问题上做出自我决策，那么当信息在应用程序间进行交换时，有时就会失败。

3.4.2 应用程序的登录和显示

应用程序可以使用任何字符集或者字符编码系统来接收和显示域名，IDNA的协议并不会影响用户和应用程序之间的界面。支持IDN的应用程序能够以两种方式接收和显示IDN：应用程序支持国际化字符集以显示U-label格式的字符，以及应用程序允许显示A-label格式的字符（但不鼓励这么做）。通常，应用程序开发者应允许但不鼓励用户输入A-label格式的字符，因为A-label格式的字符是不透明的，并且其变化不易被察觉。IDN使用的字符可以采用A-label格式或U-label格式，应用程序可以合理地让用户选择自己偏好的显示顺序。

域名是互联网的基本元素，会在许多应用程序中存储和传输。域名是文件的构成部分或者电子邮件信息和网页的核心元素等，如简单邮件传输协议（SMTP）的控制命令、相关电子邮件主要部分标题以及WWW服务程序所用的协议等。在定义如何处理规范标准或者字符集的互联网协议中，会对允许的字符集进行设置。如果互联网协议中只允许一个字符集，那么域名字段必须采用这个字符集。并不是所有的字符集都适合用于域名字段，IETF推荐的字符集是Unicode字符集，也是目前主流的世界通用字符集。如果U-label格式的字符不能显示全部域名字段，就只能选择A-label格式的字符。

IDNA2008没有固定一个字符和其他因素之间的映射关系。IDNA2008禁止输入基于拉丁语的数学符号，以及大写字母、宽字符等。当用户需要使用这些字符时，可以通过特定的客户端进行处理。

RFC 5892不能使用NFKC（规格化形式KC）转换字符串，如果应用程序在域名查询之前执行了NFKC转换，那么就可以使应用程序查询任何有效的字串，该操作是安全的。不过，正如上文所探讨的，由于应用程序不能保证其他应用程序都执行NFKC转换，因此在执行NFKC转换时会发出警告。在许多情况下，系统会支持用户界面执行一些适合本地环境的字符映射，这种映射可以作为上述讨论的Unicode惯例和协议文件（见RFC5891）的一部分，但这些变化只能是本地的变化。

对系统互换应用来说，映射显得更为重要，在没有信息损失的前提下，U-label格式的字符和A-label格式的字符可以相互映射。在仅使用ASCII字符的DNS中，可以通过大小写不敏感的方式来查询和匹配域名，但没有发生实际的大小写转换。

3.4.3 语言期待：合体字、连体字和交替字符形式

在很多情况下，用户会期待字符匹配或者实现语言的正确拼写，例如：

（1）挪威的用户可能会将连体字“ae-”和“a-”当成相同的字符，但英国的用户会感到很惊讶。

（2）德国的用户可能会将“o-”及其元音变音“oe”当成相同的字符，但在挪威语中会造成明显的错误。

（3）中国的用户可能会期望自动匹配简体中文字符和繁体中文字符，但在韩文或日文中会造成很大的混淆。

（4）英语的用户可能会期望匹配“theater”和“theatre”。

很多语言使用连体字，即使用两个字符来表示一个单音位。例如，在“pharmacy”和“telephone”中的“ph”（这些字符也可以连续出现，如“tophat”）。有些连体字可以通过两个靠近的字符来实现，用合体字作为连体字。例如，在“encyclopaedia”中，有时使用U+00E6（拉丁小写连字AE）来表示“ae”。

例如，合体字“ae”是拉丁文字母表中第27个字母和第29个字母，它等同于瑞典字母表中的第28个字母（也包含第29个字母），即U+00E4（“?”，带有分音符号的拉丁文小写字母a）。根据现有的正确拼写标准，“ae”不能被取代。字符U+00E4也是德语字母表的一部分，和北欧语系不同，“ae”通常被当成“?”的正确拼字方法，反过来是不正确的，并且这两个字符不会组合到“?”中。对于德文字符，如U+00F6（“?”，带有分音符号的拉丁文小写字母o），则不能用于姓名（如“Goethe”）中。字符U+00E4也是在瑞典文字母表中的字母，但不能将“?”表述为“oe”，并且在挪威文字母表中不是“?”。

匹配和对比运算法则通常需要字符所在的语言环境信息，但是IDNA或者DNS中不存在这样的信息，因此IDNA2008无法以特殊的方式来处理组合字符（如连体字或和合体字）。

域名注册管理者要了解特定的语言环境，对于要注册的域名字段，某些语言环境会将两个字符看成组合形式，这时可以使用RFC 3743给出的模型，禁止其中一种形式的注册，从而减少以不同的形式进行域名注册而造成混淆和欺诈的可能性。

3.4.4 大小写映射和相关问题

在DNS中，ASCII字符保留了大小写形式，但在域名查询过程中是大小写不敏感的，在此过程中大小写所阐述的信息会丢失。因为DNS没有涉及IDN的解析，所以不能对IDN进行大小写不敏感匹配，因此在域名查询或域名注册过程中和在服务器中进行匹配时，要保持大小写的分离处理。

在IDNA2003中，所有的字符都是可以进行大小写转换的，但有些字符是没有大写形式的。例如，在进行Unicode字符的大小写转换操作时，字符U+03C2（“”，希腊语小写字母词尾Sigma）转换的中间形式是字符U+03C3（“σ”，希腊语小写字母Sigma），并最终转换成字符U+00DF（“?”，拉丁文小写字母SharpS），这些转换是不可逆的，因为字符U+03C3的大写形式是字符U+03A3（“Σ”，希腊文大写字母Sigma）。

在IDNA2003中，“σ”和“?”可能被转换成其他字符，并且这种转换是不可逆的，所以不论“σ”还是“?”，都不能在IDNA2003中用ACE编码的形式来表现，也不能用U-label格式来表现。

3.4.5 从右到左的字符

为了确保从右到左的字符方向性是正确的，在IDNA2003中，如果域名字段是从右到左的，则从右到左的字符都要在域名字段的开头和结尾出现，并且不包括任何带有从左到右的字符（但接受欧洲数字）。这是一种坚持整个域名字段的IDNA运算法则，而不仅仅是单独的字符。当在从右到左的域名字段中最后一个字符要求使用组合字符时，IDNA2003中的运算法则会拒绝这个域名字段。

对于使用辅音字母表，以及域名字段具有不同方向性字符这两种情况来说，这种禁止是不可接受的。在这两种情况下，组合字符就成为正确拼写的重要组成部分。例如，依地语（也称为犹太语）使用扩展的希伯来字母及迪维希语（马尔代夫的官方语言，也是从阿拉伯字母衍生而来的）来书写。IDNA2008去除了最终组合字符的限制，用最新从右到左的字符，以及在Bidi文件（见RFC 5893）中详细规定的规则来代替。