Internet Engineering Task Force (IETF) Y. Yoneya
Request for Comments: 7790 JPRS
Category: Informational T. Nemoto
ISSN: 2070-1721 Keio University
February 2016
Internet Engineering Task Force (IETF) Y. Yoneya
Request for Comments: 7790 JPRS
Category: Informational T. Nemoto
ISSN: 2070-1721 Keio University
February 2016
Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS)
国际化字符串（PRECIS）的准备、执行和比较类的映射字符
Abstract
摘要
The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.
用于准备、实施和比较国际化字符串（PRECIS）的框架定义了应用程序协议中使用的几类字符串。由于许多协议执行区分大小写或不区分大小写的字符串比较，因此有必要定义用于大小写映射的方法。此外，应用程序中的国际化域名（IDNA）和PRECIS问题语句都描述了国际化字符串的映射，这些映射不仅限于大小写，还包括宽度映射、分隔符映射和其他可以考虑的特殊字符。本文档为PRECIS概要文件的设计者提供了指南，并描述了在接收用户输入和将允许的代码点传递给国际化协议之间可以应用的几种映射。特别是，本文档描述了区域设置相关和上下文相关的大小写映射，以及分隔符和特殊字符的其他映射。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7790.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7790.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol-Dependent Mappings . . . . . . . . . . . . . . . . . 3
2.1. Delimiter Mapping . . . . . . . . . . . . . . . . . . . . 3
2.2. Special Mapping . . . . . . . . . . . . . . . . . . . . . 4
2.3. Local Case Mapping . . . . . . . . . . . . . . . . . . . 4
3. Order of Operations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Mapping Type List . . . . . . . . . . . . . . . . . 8
A.1. Mapping Type List for Each Protocol . . . . . . . . . . . 8
Appendix B. Why Local Case Mapping Is an Alternative to Case
Mapping in the PRECIS Framework . . . . . . . . . . 8
Appendix C. Limitations of Local Case Mapping . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol-Dependent Mappings . . . . . . . . . . . . . . . . . 3
2.1. Delimiter Mapping . . . . . . . . . . . . . . . . . . . . 3
2.2. Special Mapping . . . . . . . . . . . . . . . . . . . . . 4
2.3. Local Case Mapping . . . . . . . . . . . . . . . . . . . 4
3. Order of Operations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Mapping Type List . . . . . . . . . . . . . . . . . 8
A.1. Mapping Type List for Each Protocol . . . . . . . . . . . 8
Appendix B. Why Local Case Mapping Is an Alternative to Case
Mapping in the PRECIS Framework . . . . . . . . . . 8
Appendix C. Limitations of Local Case Mapping . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
In many cases, user input of internationalized strings is generated through the use of an input method editor ("IME") or through copy-and-paste from free text. Users generally do not care about the case and/or width of input characters because they consider those characters to be functionally equivalent or visually identical. Furthermore, users rarely switch the IME state to input special characters such as protocol elements.
在许多情况下，国际化字符串的用户输入是通过使用输入法编辑器（“IME”）或通过自由文本的复制和粘贴生成的。用户通常不关心输入字符的情况和/或宽度，因为他们认为这些字符在功能上等同或视觉上相同。此外，用户很少切换IME状态以输入协议元素等特殊字符。
For Internationalized Domain Names (IDNs), the IDNA Mapping specification [RFC5895] describes methods for handling these issues. For PRECIS strings, case mapping and width mapping are defined in the PRECIS framework specification [RFC7564]. The case and width mappings defined in the PRECIS framework do not handle other mappings such as delimiter characters, special characters, and locale-dependent or context-dependent cases; these mappings are also important in order to increase the probability that the resulting strings compare as users expect.
对于国际化域名（IDN），IDNA映射规范[RFC5895]描述了处理这些问题的方法。对于PRECIS字符串，大小写映射和宽度映射在PRECIS框架规范[RFC7564]中定义。PRECIS框架中定义的大小写和宽度映射不处理其他映射，例如分隔符字符、特殊字符以及与区域设置或上下文相关的大小写；为了增加结果字符串按用户预期进行比较的可能性，这些映射也很重要。
This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The delimiter mapping and special mapping rules described here are applied as "additional mappings" beyond those defined in the PRECIS framework, whereas the "local case mapping" rule provides locale-dependent and context-dependent alternative case mappings for specific target characters.
本文档为PRECIS框架协议配置文件的作者提供了指南，并描述了在接收用户输入和将允许的代码点传递到国际化协议之间可以应用的几种映射。此处描述的分隔符映射和特殊映射规则作为“附加映射”应用于PRECIS框架中定义的映射之外的映射，而“局部大小写映射”规则为特定目标字符提供与区域设置相关和与上下文相关的可选大小写映射。
The PRECIS framework defines several protocol-independent mappings. The additional mappings and local case mapping defined in this document are protocol dependent, i.e., they depend on the rules for a particular application protocol.
PRECIS框架定义了几个独立于协议的映射。本文档中定义的其他映射和本地案例映射依赖于协议，即，它们取决于特定应用程序协议的规则。
Some application protocols define delimiters for their own use, resulting in the fact that the delimiters are different for each protocol. The delimiter mapping table should therefore be based on a well-defined mapping table for each protocol.
某些应用程序协议定义分隔符供自己使用，从而导致每个协议的分隔符都不同。因此，分隔符映射表应基于每个协议的定义良好的映射表。
Delimiter mapping is used to map characters that are similar to protocol delimiters into the canonical delimiter characters. For example, there are width-compatible characters that correspond to the '@' in email addresses and the ':' and '/' in URIs. The '+', '-', '<' and '>' characters are other common delimiters that might require such mapping. For the FULL STOP character (U+002E), a delimiter in the visual presentation of domain names, some IMEs produce a character such as IDEOGRAPHIC FULL STOP (U+3002) when a user types FULL STOP on the keyboard. In all these cases, the visually similar characters that can come from user input need to be mapped to the correct protocol delimiter characters before the string is passed to the protocol.
分隔符映射用于将类似于协议分隔符的字符映射到规范分隔符字符中。例如，存在与电子邮件地址中的“@”和URI中的“：”和“/”相对应的宽度兼容字符。“+”、“-”、“<”和“>”字符是可能需要这种映射的其他常用分隔符。对于域名可视表示中的定界符句号字符（U+002E），当用户在键盘上键入句号时，某些IME会生成表意句号（U+3002）等字符。在所有这些情况下，在将字符串传递到协议之前，需要将来自用户输入的视觉上相似的字符映射到正确的协议分隔符字符。
Aside from delimiter characters, certain protocols have characters which need to be mapped in ways that are different from the rules specified in the PRECIS framework (e.g., mapping non-ASCII space characters to ASCII space). In this document, these mappings are called "special mappings". They are different for each protocol. Therefore, the special mapping table should be based on a well-defined mapping table for each protocol. Examples of special mapping are the following;
除了分隔符字符外，某些协议还具有需要以不同于PRECIS框架中指定规则的方式映射的字符（例如，将非ASCII空格字符映射到ASCII空格）。在本文档中，这些映射称为“特殊映射”。对于每个协议，它们是不同的。因此，特殊映射表应基于每个协议的定义良好的映射表。特殊映射的示例如下：；
o White spaces such as CHARACTER TABULATION (U+0009) or IDEOGRAPHIC SPACE (U+3000) are mapped to SPACE (U+0020)
o 空白（如字符表（U+0009）或表意空间（U+3000）映射到空格（U+0020）
o Some characters such as control characters are mapped to nothing (Deletion)
o 某些字符（如控制字符）映射为空（删除）
As examples, the Extensible Authentication Protocol (EAP) [RFC3748], IMAP4 Access Control List (ACL) [RFC4314], and LDAPprep [RFC4518] define the rule that some code points for the non-ASCII space are mapped to SPACE (U+0020).
例如，可扩展身份验证协议（EAP）[RFC3748]、IMAP4访问控制列表（ACL）[RFC4314]和LDAPprep[RFC4518]定义了将非ASCII空间的一些代码点映射到空间（U+0020）的规则。
The purpose of local case mapping is to increase the probability of results that users expect when character case is changed (e.g., map uppercase to lowercase) between input and use in a protocol. Local case mapping selectively affects characters whose case mapping depends on locale and/or context.
局部大小写映射的目的是增加在协议中输入和使用之间更改字符大小写（例如，将大写字母映射为小写字母）时用户期望的结果的概率。局部大小写映射选择性地影响大小写映射依赖于区域设置和/或上下文的字符。
(Note: The term "locale" in this document practically means "language" or "language and region" because the locale based on that language configuration of applications on POSIX is selected by "locale" information. See also the "Note" in Section 2.1.1 of RFC 5646 [RFC5646].)
（注：本文件中的术语“语言环境”实际上是指“语言”或“语言和地区”，因为基于POSIX上应用程序的语言配置的语言环境是由“语言环境”信息选择的。另请参见RFC 5646[RFC5646]第2.1.1节中的“注记”）
As an example of locale- and context-dependent mapping, LATIN CAPITAL LETTER I ("I", U+0049) is normally mapped to LATIN SMALL LETTER I ("i", U+0069); however, if the language is Turkish (or one of several other languages), unless an I is before a dot_above, the character should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).
作为区域设置和上下文相关映射的示例，拉丁文大写字母I（“I”，U+0049）通常映射为拉丁文小写字母I（“I”，U+0069）；但是，如果语言是土耳其语（或其他几种语言中的一种），除非I位于上面的点_之前，否则字符应映射为拉丁小写字母DOTLESS I（U+0131）。
Case mapping using Unicode Default Case Folding in the PRECIS framework does not consider such locale or context because it is a common framework for internationalization. Local case mapping defined in this document correspond to demands from applications that support users' locale and/or context. The complete set of possible target characters for local case mapping are the characters specified
在PRICIS框架中使用Unicode默认情况折叠的情况映射不考虑这样的区域或上下文，因为它是一个通用的国际化框架。本文档中定义的本地案例映射对应于支持用户区域设置和/或上下文的应用程序的需求。本地大小写映射的完整可能目标字符集是指定的字符
in SpecialCasing.txt [Specialcasing] in Section 3.13 of the Unicode Standard [Unicode], but the specific set of target characters selected for local case mapping depends on locale and/or context, as further explained in SpecialCasing.txt.
在Unicode标准[Unicode]第3.13节的SpecialCasing.txt[SpecialCasing]中，但为本地大小写映射选择的特定目标字符集取决于区域设置和/或上下文，如SpecialCasing.txt中进一步解释的。
The case-folding method for a selected target character is to map into lowercase as defined in SpecialCasing.txt. The case-folding method for all other, non-target characters is as specified in Section 5.2.3 of the PRECIS framework. When an application supports users' locale and/or context, use of local case mapping can increase the probability that string comparisons yield the results that users expect.
选定目标字符的大小写折叠方法是映射为SpecialCasing.txt中定义的小写。PRECIS框架第5.2.3节规定了所有其他非目标字符的大小写折叠方法。当应用程序支持用户的区域设置和/或上下文时，使用本地大小写映射可以增加字符串比较产生用户期望结果的概率。
If a PRECIS profile selects Unicode Default Case Folding as the preferred method of case mapping, the profile designers may consider whether local case mapping can be applied. And, if it can be applied, it is better to add "alternatively, local case mapping might be applicable" after "Unicode Default Case Folding" so that application developers are aware of the alternative. See Appendix B for a description of why local case mapping can be an alternative.
如果PRECIS配置文件选择Unicode默认情况折叠作为实例映射的优选方法，则配置文件设计者可以考虑是否可以应用局部情况映射。而且，如果可以应用，最好在“Unicode默认大小写折叠”之后添加“或者，本地大小写映射可能适用”，以便应用程序开发人员了解替代方法。有关为什么本地案例映射可以作为替代方案的说明，请参见附录B。
Delimiter mapping and special mapping as described in this document are expected to be applied as the "Additional Mapping Rule" mentioned in Section 5.2.2 of the PRECIS framework. Although the delimiter mapping and special mapping could be applied in either order, this document recommends the following order to minimize the effect of code-point changes introduced by the mappings and to be acceptable to the widest user community:
本文件中描述的分隔符映射和特殊映射预计将作为PRECIS框架第5.2.2节中提到的“附加映射规则”应用。虽然分隔符映射和特殊映射可以按任意顺序应用，但本文档建议按以下顺序应用，以最大限度地减少映射引入的代码点更改的影响，并使最广泛的用户群体能够接受：
1. Delimiter mapping
1. 定界符映射
2. Special mapping
2. 特殊映射
Detailed security considerations for PRECIS strings are discussed in the PRECIS framework specification [RFC7564]. This document inherits the considerations as well.
PRECIS框架规范[RFC7564]中讨论了PRECIS字符串的详细安全注意事项。本文档也继承了这些注意事项。
As with Mapping Characters for IDNA2008 [RFC5895], this document suggests creating mappings that might cause confusion for some users while alleviating confusion for other users. Such confusion is not covered in any depth in this document.
与IDNA2008[RFC5895]的映射字符一样，本文档建议创建可能导致某些用户混淆的映射，同时减轻其他用户的混淆。本文件未深入讨论此类混淆。
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.
[RFC7564]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备、实施和比较”，RFC 7564，DOI 10.17487/RFC7564，2015年5月<http://www.rfc-editor.org/info/rfc7564>.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 7.0.0", (Mountain View, CA: The Unicode Consortium, 2014. ISBN 978-1-936213-09-2), <http://www.unicode.org/versions/Unicode7.0.0/>.
[Unicode]Unicode联盟，“Unicode标准，7.0.0版”（加利福尼亚州山景城：Unicode联盟，2014年，ISBN 978-1-936213-09-2）<http://www.unicode.org/versions/Unicode7.0.0/>.
[Casefolding] The Unicode Consortium, "CaseFolding-7.0.0.txt", Unicode Character Database, July 2011, <http://www.unicode.org/Public/7.0.0/ucd/CaseFolding.txt>.
[CaseBolding]Unicode联盟，“CaseBolding-7.0.0.txt”，Unicode字符数据库，2011年7月<http://www.unicode.org/Public/7.0.0/ucd/CaseFolding.txt>.
[Specialcasing] The Unicode Consortium, "SpecialCasing-7.0.0.txt", Unicode Character Database, July 2011, <http://www.unicode.org/Public/7.0.0/ucd/ SpecialCasing.txt>.
[Specialcasing]Unicode联盟，“Specialcasing-7.0.0.txt”，Unicode字符数据库，2011年7月<http://www.unicode.org/Public/7.0.0/ucd/ SpecialCasing.txt>。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <http://www.rfc-editor.org/info/rfc3454>.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化字符串的准备（“stringprep”）”，RFC 3454，DOI 10.17487/RFC3454，2002年12月<http://www.rfc-editor.org/info/rfc3454>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <http://www.rfc-editor.org/info/rfc3490>.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 3490，DOI 10.17487/RFC3490，2003年3月<http://www.rfc-editor.org/info/rfc3490>.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <http://www.rfc-editor.org/info/rfc3491>.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，DOI 10.17487/RFC34912003年3月<http://www.rfc-editor.org/info/rfc3491>.
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, DOI 10.17487/RFC3722, April 2004, <http://www.rfc-editor.org/info/rfc3722>.
[RFC3722]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，DOI 10.17487/RFC3722，2004年4月<http://www.rfc-editor.org/info/rfc3722>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, <http://www.rfc-editor.org/info/rfc4314>.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，DOI 10.17487/RFC4314，2005年12月<http://www.rfc-editor.org/info/rfc4314>.
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, DOI 10.17487/RFC4518, June 2006, <http://www.rfc-editor.org/info/rfc4518>.
[RFC4518]Zeilenga，K.，“轻量级目录访问协议（LDAP）：国际化字符串准备”，RFC 4518，DOI 10.17487/RFC4518，2006年6月<http://www.rfc-editor.org/info/rfc4518>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，DOI 10.17487/RFC5646，2009年9月<http://www.rfc-editor.org/info/rfc5646>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <http://www.rfc-editor.org/info/rfc5895>.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 5895，DOI 10.17487/RFC5895，2010年9月<http://www.rfc-editor.org/info/rfc5895>.
This table is the mapping type list for each protocol that uses the Stringprep framework [RFC3454] and is a PRECIS framework customer candidate (as Stringprep and the related IDNA versions in the table below are now obsolete). Values marked "o" indicate that the protocol uses the type of mapping. Values marked "-" indicate that the protocol doesn't use the type of mapping.
此表是使用Stringprep框架[RFC3454]的每个协议的映射类型列表，并且是PRECIS框架的候选客户（因为下表中的Stringprep和相关IDNA版本现已过时）。标记为“o”的值表示协议使用映射类型。标记为“-”的值表示协议不使用映射类型。
+---------------------+-------------+-----------+------+---------+
| Protocol and | Width | Delimiter | Case | Special |
| mapping RFC | (NFKC) | | | |
+---------------------+-------------+-----------+------+---------+
| IDNA [RFC3490] | - | o | - | - |
| IDNA [RFC3491] | o | - | o | - |
| iSCSI [RFC3722] | o | - | o | - |
| EAP [RFC3748] | o | - | - | o |
| IMAP [RFC4314] | o | - | - | o |
| LDAP [RFC4518] | o | - | o | o |
+---------------------+-------------+-----------+------+---------+
+---------------------+-------------+-----------+------+---------+
| Protocol and | Width | Delimiter | Case | Special |
| mapping RFC | (NFKC) | | | |
+---------------------+-------------+-----------+------+---------+
| IDNA [RFC3490] | - | o | - | - |
| IDNA [RFC3491] | o | - | o | - |
| iSCSI [RFC3722] | o | - | o | - |
| EAP [RFC3748] | o | - | - | o |
| IMAP [RFC4314] | o | - | - | o |
| LDAP [RFC4518] | o | - | o | o |
+---------------------+-------------+-----------+------+---------+
Appendix B. Why Local Case Mapping Is an Alternative to Case Mapping in the PRECIS Framework
附录B.为什么本地案例映射是PRECIS框架中案例映射的替代方案
Local case mapping and Unicode Default Case Folding are alternatives. They can't be applied simultaneously or sequentially. One outstanding issue regarding full case folding for characters is that some lowercase characters like "LATIN SMALL LETTER SHARP S" (U+00DF) (hereinafter referred to as "eszett") and ligatures like "LATIN SMALL LIGATURE FF" (U+FB00) that are described in the "Unconditional mappings" section of SpecialCasing.txt become a different code point when the case mapping is performed using Unicode Default Case Folding in the PRECIS framework. In particular, German's eszett cannot keep the locale because eszett becomes two "LATIN SMALL LETTER S"s (U+0073 U+0073) when the case mapping is performed using Unicode Default Case Folding. (See also 00DF in CaseFolding.txt [Casefolding].) On the other hand, eszett doesn't become a different code point when performing the case mapping in SpecialCasing.txt. Therefore, if it is necessary to keep the locale of characters, PRECIS profile designers should select local case mapping as an alternative to Unicode Default Case Folding.
本地大小写映射和Unicode默认大小写折叠是可选的。它们不能同时或顺序应用。关于字符全大小写折叠的一个突出问题是“无条件映射”中描述的一些小写字符，如“拉丁小写字母夏普S”（U+00DF）（以下简称“eszett”）和连字，如“拉丁小写连字FF”（U+FB00）当在PRECIS框架中使用Unicode默认大小写折叠执行大小写映射时，SpecialCasing.txt的部分将成为不同的代码点。特别是，德语的eszett无法保留区域设置，因为当使用Unicode默认大小写折叠执行大小写映射时，eszett变成了两个“拉丁小写字母s”（U+0073 U+0073）。另一方面，在SpecialCasing.txt中执行案例映射时，eszett不会成为不同的代码点。因此，如果需要保留字符的区域设置，PRECIS配置文件设计者应该选择本地大小写映射作为Unicode默认大小写折叠的替代方案。
As described in Section 2.3, the possible target characters of local case mapping are specified in SpecialCasing.txt. The Unicode Standard (at least, up to version 7.0.0) does not define any context-dependent mappings between "GREEK SMALL LETTER SIGMA" (U+03C3) (hereinafter referred to as "small sigma") and "GREEK SMALL LETTER FINAL SIGMA" (U+03C2) (hereinafter referred to as "final sigma"). Thus, local case mapping is not applicable to small sigma or final sigma, so case mapping in the PRECIS framework always maps final sigma to small sigma, independent of context, as also specified by Unicode Default Case Folding. The following comments are from SpecialCasing.txt. (Line breaks have been added due to line-length limitations.)
如第2.3节所述，SpecialCase.txt中指定了本地案例映射的可能目标字符。Unicode标准（至少在版本7.0.0之前）未定义“希腊小写字母西格玛”（U+03C3）（以下简称“小西格玛”）和“希腊小写字母最终西格玛”（U+03C2）（以下简称“最终西格玛”）之间的任何上下文相关映射。因此，局部案例映射不适用于小sigma或最终sigma，因此PRECIS框架中的案例映射总是将最终sigma映射到小sigma，与上下文无关，这也是由Unicode默认案例折叠指定的。以下评论来自SpecialCasing.txt。（由于行长度限制，已添加换行符。）
# Note: the following cases are not included, since they would case-fold in lowercasing
#注意：以下情况不包括在内，因为它们将以小写形式折叠
# 03C3; 03C2; 03A3; 03A3; Final_Sigma; # GREEK SMALL LETTER SIGMA
# 03C2; 03C3; 03A3; 03A3; Not_Final_Sigma; # GREEK SMALL LETTER FINAL
SIGMA
# 03C3; 03C2; 03A3; 03A3; Final_Sigma; # GREEK SMALL LETTER SIGMA
# 03C2; 03C3; 03A3; 03A3; Not_Final_Sigma; # GREEK SMALL LETTER FINAL
SIGMA
Acknowledgments
致谢
Martin Duerst suggested a need for the case folding about the mapping (map final sigma to sigma, German sz to ss, etc.).
Martin Duerst建议需要对映射进行案例折叠（将最终sigma映射到sigma，将德语sz映射到ss，等等）。
Alexey Melnikov, Andrew Sullivan, Barry Leiba, David Black, Heather Flanagan, Joe Hildebrand, John Klensin, Marc Blanchet, Pete Resnick, and Peter Saint-Andre, et al., gave important suggestions for this document during working group discussions.
Alexey Melnikov、Andrew Sullivan、Barry Leiba、David Black、Heather Flanagan、Joe Hildebrand、John Klesins、Marc Blanchet、Pete Resnick和Peter Saint Andre等人在工作组讨论期间对本文件提出了重要建议。
Authors' Addresses
作者地址
Yoshiro YONEYA JPRS Chiyoda First Bldg. East 13F 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
日本东京101-0065西神田千代田区东13楼3-8-1 Yoshiro YONEYA JPRS Chiyoda First Bldg.东
Phone: +81 3 5215 8451
Email: yoshiro.yoneya@jprs.co.jp
Phone: +81 3 5215 8451
Email: yoshiro.yoneya@jprs.co.jp
Takahiro Nemoto Keio University Graduate School of Media Design 4-1-1 Hiyoshi, Kohoku-ku Yokohama, Kanagawa 223-8526 Japan
日本神奈川市横滨市小冈区Hiyoshi 4-1-1高广内本庆应大学媒体设计研究生院223-8526
Phone: +81 45 564 2517
Email: t.nemo10@kmd.keio.ac.jp
Phone: +81 45 564 2517
Email: t.nemo10@kmd.keio.ac.jp