Network Working Group J. Klensin
Request for Comments: 5137 February 2008
BCP: 137
Category: Best Current Practice
ASCII Escaping of Unicode Characters
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
抽象
There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized.
エスケープ機構が示されるか、または直接送信することができない文字をエンコードするためのプロトコルに関連して必要とされる状況は数多くあります。 ASCIIコード化して、伝統的なエスケープは、10進数または様々な異なる方法で書かれた文字の16進数値で、どちらかとなっています。文字が二つ以上のオクテットを占有し、いくつかの異なる形式で符号化することができるのUnicodeへの移行は、さらにエスケープの問題を複雑にしています。この文書では、現在使用中のいくつかのオプションについて説明し、新しいIETFプロトコルで使用するための1つを選択するための考慮事項について説明し、今や国際化されているプロトコル。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Context and Background . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Discussion List . . . . . . . . . . . . . . . . . . . . . 4
2. Encodings that Represent Unicode Code Points: Code
Position versus UTF-8 or UTF-16 Octets . . . . . . . . . . . . 4
3. Referring to Unicode Characters . . . . . . . . . . . . . . . 5
4. Syntax for Code Point Escapes . . . . . . . . . . . . . . . . 6
5. Recommended Presentation Variants for Unicode Code Point
Escapes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Backslash-U with Delimiters . . . . . . . . . . . . . . . 7
5.2. XML and HTML . . . . . . . . . . . . . . . . . . . . . . . 7
6. Forms that Are Normally Not Recommended . . . . . . . . . . . 8
6.1. The C Programming Language: Backslash-U . . . . . . . . . 8
6.2. Perl: A Hexadecimal String . . . . . . . . . . . . . . . . 8
6.3. Java: Escaped UTF-16 . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Formal Syntax for Forms Not Recommended . . . . . . . 12
A.1. The C Programming Language Form . . . . . . . . . . . . . 12
A.2. Perl Form . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. Java Form . . . . . . . . . . . . . . . . . . . . . . . . 12
There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII [ASCII] coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. For example, in different contexts, we have seen %dNN or %NN for the decimal form, %NN, %xNN, X'nn', and %X'NN' for the hexadecimal form. "%NN" has become popular in recent years to represent a hexadecimal value without further qualification, perhaps as a consequence of its use in URLs and their prevalence. There are even some applications around in which octal forms are used and, while they do not generalize well, the MIME Quoted-Printable and Encoded-word forms can be thought of as yet another set of escapes. So, even for the fairly simple cases of ASCII and standard built by extending ASCII, such as the ISO 8859 family, we have been living with several different escaping forms, each the result of some history.
エスケープ機構が示されるか、または直接送信することができない文字をエンコードするためのプロトコルに関連して必要とされる状況は数多くあります。 ASCII [ASCII]コーディングで、伝統的なエスケープは、10進数または様々な異なる方法で書かれた文字の16進数値で、どちらかとなっています。例えば、異なるコンテキストにおいて、我々は、16進フォームの％DNNまたは％NN小数点形式のため、％NN、％xNNエスケープ、X'nn「および％X'NN」を見ました。 「％NNは、」おそらく、URLでのその使用及びその有病率の結果として、更なる資格なし16進値を表現するために、近年、人気となっています。彼らはよく一般化していないながら進形式は、使用されているの周りにいくつかのアプリケーションは、MIME quoted-printable形式およびエンコードされたワード形式は、エスケープのまだ別のセットと考えることができ、さえあります。ですから、このようなISO 8859ファミリーのようASCIIおよびASCIIを拡張することによって構築された標準のかなり単純な場合のために、私たちは、それぞれいくつかの歴史の結果、いくつかの異なるエスケープ形式で暮らしています。
When one moves to Unicode [Unicode] [ISO10646], where characters occupy two or more octets and may be coded in several different forms, the question of escapes becomes even more complicated. Unicode represents characters as code points: numeric values from 0 to hex 10FFFF. When referencing code points in flowing text, they are represented using the so-called "U+" notation, as values from U+0000 to U+10FFFF. When serialized into octets, these code points can be represented in different forms:
一つの文字が二つ以上のオクテットを占有し、いくつかの異なる形式で符号化されてもよいユニコード[UNICODE] [ISO10646]に移動したときに、エスケープの問題はさらに複雑になります。 0から六角10FFFFの数値：ユニコードのコードポイントとして文字を表します。フローテキストのコード・ポイントを参照する場合、それらはU + 10FFFFにU + 0000からの値として、いわゆる「U +」表記法を使用して表されます。オクテットにシリアル化するとき、これらのコード・ポイントは、異なる形式で表すことができます。
o in UTF-8 with one to four octets [RFC3629]
1〜4個のオクテットとUTF-8 O [RFC3629]
o in UTF-16 with two or four octets (or one or two seizets -- 16-bit units)
UTF-16における2つのまたは4つのオクテット（ - 16ビット単位、又は1つ若しくは2つのseizets）とO
o in UTF-32 with exactly four octets (or one 32-bit unit)
UTF-32で正確に4オクテット（または1つの32ビット単位）とO
When escaping characters, we have seen fairly extensive use of hexadecimal representations of both the serialized forms and variations on the U+ notation, known as code point escapes.
文字をエスケープするとき、我々は、コードポイントエスケープとして知られているU +表記にシリアライズ形態および変形の両方を16進数表現のかなり広範な用途を見てきました。
In accordance with existing best-practices recommendations [RFC2277], new protocols that are required to carry textual content for human use SHOULD be designed in such a way that the full repertoire of Unicode characters may be represented in that text.
既存のベスト・プラクティスの推奨事項[RFC2277]に従って、ヒトへの使用のためのテキストコンテンツを運ぶために必要とされる新しいプロトコルは、Unicode文字の全レパートリーがそのテキストで表現することができるように設計されなければなりません。
This document proposes that existing protocols being internationalized, and those that need an escape mechanism, SHOULD use some contextually appropriate variation on references to code points as described in Section 2 unless other considerations outweigh those described here.
この文書では、既存のプロトコルが国際化されていることを提案し、第2節で説明したように、他の考慮事項はここに記載されているものを上回る場合を除き、エスケープメカニズムを必要とするものは、コード・ポイントへの参照にいくつかの文脈に適切なバリエーションを使用すべきです。
This recommendation is not applicable to protocols that already accept native UTF-8 or some other encoding of Unicode. In general, when protocols are internationalized, it is preferable to accept those forms rather than using escapes. This recommendation applies to cases, including transition arrangements, in which that is not practical.
この勧告は、すでにネイティブUTF-8またはUnicodeのいくつかの他のエンコーディングを受け入れるプロトコルには適用されません。プロトコルが国際化されたときに一般的には、エスケープを使用するのではなく、それらの形態を受け入れることが好ましいです。この勧告は、それが実用的ではないとした遷移手配を含め、ケースに適用されます。
In addition to the protocol contexts addressed in this specification, escapes to represent Unicode characters also appear in presentations to users, i.e., in user interfaces (UI). The formats specified in, and the reasoning of, this document may be applicable in UI contexts as well, but this is not a proposal to standardize UI or presentation forms.
本明細書で対処プロトコルコンテキストに加えて、Unicode文字を表すためにエスケープまた、ユーザインターフェース（UI）で、すなわち、ユーザにプレゼンテーションで表示されます。で指定されたフォーマット、およびの推論は、この文書では、同様のUIコンテキストでも適用できるが、これはUIやプレゼンテーションの形式を標準化する提案ではありません。
This document does not make general recommendations for processing Unicode strings or for their contents. It assumes that the strings that one might want to escape are valid and reasonable and that the definition of "valid and reasonable" is the province of other documents. Recommendations about general treatment of Unicode strings may be found in many places, including the Unicode Standard itself and the W3C Character Model [W3C-CharMod], as well as specific rules in individual protocols.
この文書では、Unicode文字列を処理するためか、その内容のための一般的な推奨事項を作成しません。それは1つが脱出したい場合があります文字列が有効かつ合理的であると仮定し、「有効かつ合理的」の定義は、他の文書の州であること。 Unicode文字列の一般的な治療に関する推奨事項は、Unicode標準自体とW3C文字モデル[W3C-CHARMOD]、ならびに個々のプロトコルに固有のルールを含む多くの場所で見つけることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Additional Unicode-specific terminology appears in [UnicodeGlossary], but is not necessary for understanding this specification.
追加のUnicode固有の用語は[UnicodeGlossary]に表示されますが、この仕様を理解する必要はありません。
Discussion of this document should be addressed to the discuss@apps.ietf.org mailing list.
本書の議論はdiscuss@apps.ietf.orgメーリングリストに対処する必要があります。
2. Encodings that Represent Unicode Code Points: Code Position versus UTF-8 or UTF-16 Octets
Unicodeのコードポイントを表し2.エンコーディング：UTF-8またはUTF-16オクテット対コードの位置
There are two major families of ways to escape Unicode characters. One uses the code point in some representation (see the next section), the other encodes the octets of the UTF-8 encoding or some other encoding in some representation. Some other options are possible, but they have been rare in practice. This specification recommends that, in the absence of compelling reasons to do otherwise, the Unicode code points SHOULD be used rather than a representation of UTF-8 (or UTF-16) octets. There are several reasons for this, including:
Unicode文字をエスケープする方法は2つの主要なファミリーが存在します。一つは、他のUTF-8エンコーディングまたはいくつかの表現でいくつかの他の符号化のオクテットをコードする、（次のセクションを参照）、いくつかの表現でコードポイントを使用します。いくつかの他のオプションも可能ですが、彼らは実際には稀でした。この仕様は、そうでなければ行うための魅力的な理由が存在しない場合に、UnicodeコードポイントはUTF-8（またはUTF-16）のオクテットの表現ではなく、使用されるべきであることをお勧めします。など、これにはいくつかの理由があります：
o One reason for the success of many IETF protocols is that they use human-interpretable text forms to communicate, rather than encodings that generally require computer programs (or hand simulation of algorithms) to decode. This suggests that the presentation form should reference the Unicode tables for characters and to do so as simply as possible.
O多くのIETFのプロトコルの成功の理由の一つは、彼らは人間が解釈可能なテキスト通信するためのフォームではなく、一般的に復号化するためにコンピュータプログラム（またはアルゴリズムの手のシミュレーションを）必要とエンコーディングを使用することです。これは、プレゼンテーション形式は文字のためのUnicodeテーブルを参照する必要がありますし、できるだけ簡単そうすることを示唆しています。
o Because of the nature of UTF-8, for a human to interpret a decimal or hexadecimal numeral representation of UTF-8 octets requires one or more decoding steps to determine a Unicode code point that can used to look up the character in a table. That may be appropriate in some cases where the goal is really to represent the UTF-8 form but, in general, it just obscures desired information and makes errors more likely and debugging harder.
そのためUTF-8の性質のO、ヒトは10進数またはUTF-8オクテットの16進数表現を解釈するためのテーブルで文字を検索するために使用することができるUnicodeコードポイントを決定するために、1つのまたは複数の復号化ステップを必要とします。それは目標がUTF-8形式を表すために実際にあるものの、一般的には、それだけで所望の情報をあいまいにし、困難のエラーが可能性が高いとデバッグになり、場合によっては適切かもしれません。
o Except for characters in the ASCII subset of Unicode (U+0000 through U+007F), the code point form is generally more compact than forms based on coding UTF-8 octets, sometimes much more compact.
O（U + 007Fを介してU + 0000）のUnicodeのASCIIサブセットの文字を除いて、コードポイントフォームは、一般に、UTF-8オクテット符号化に基づく形態よりもコンパクト時々はるかにコンパクトです。
The same considerations that apply to representation of the octets of UTF-8 encoding also apply to more compact ACE encodings such as the "bootstring" encoding [RFC3492] with or without its "Punycode" profile.
UTF-8エンコーディングのオクテットの表現に適用されるのと同じ考察はまた、またはその「ピュニコード」プロファイルことなく、そのような「ブートストリング」エンコーディング[RFC3492]などのよりコンパクトなACEエンコーディングに適用されます。
Similar considerations apply to UTF-16 encoding, such as the \uNNNN form used in Java (See Section 6.3). While those forms are equivalent to code point references for the Basic Multilingual Plane (BMP, Plane 0), a two-stage decoding process is needed to handle surrogates to access higher planes.
同様の考察は（セクション6.3を参照）、Java（登録商標）で使用される\ uNNNN形態として、UTF-16符号化に適用されます。これらの形態は、基本多言語面（BMP、プレーン0）のコードポイントの参照と同等であるが、二段階の復号処理は、より高い平面にアクセスするサロゲートを処理するために必要とされます。
Regardless of what decisions are made about escapes for Unicode characters in protocol or similar contexts, text referring to a Unicode code point SHOULD use the U+NNNN[N[N]] syntax, as specified in the Unicode Standard, where the NNNN... string consists of hexadecimal numbers. Text actually containing a Unicode character SHOULD use a syntax more suitable for automated processing.
かかわらず、NNNNユニコード規格に指定されるように、U + NNNN [N [N]の構文を使用するテキストは、Unicodeコードポイントを参照し、プロトコルのUnicode文字のエスケープまたは類似の状況について行われるもの決定の..文字列は、16進数で構成されています。実際にUnicode文字を含むテキストは、自動処理のためのより適切な構文を使用する必要があります。
There are many options for code point escapes, some of which are summarized below. All are equivalent in content and semantics -- the differences lie in syntax. The best choice of syntax for a particular protocol or other application depends on that application: one form may simply "fit" better in a given context than others. It is clear, however, that hexadecimal values are preferable to other alternatives: Systems based on decimal or octal offsets SHOULD NOT be used.
以下に要約されているそのうちのいくつかのコード・ポイント・エスケープのための多くのオプションがあります。すべてのコンテンツと意味論における等価です - の違いは、構文にあります。単に他より与えられた文脈で、より良い「フィット」も一つの形式：特定のプロトコルや他のアプリケーションのための構文の最良の選択は、そのアプリケーションに依存します。これは、16進数の値は、他の選択肢よりも好ましいことは明らかである：10進数または進オフセットに基づいてシステムが使用されるべきではありません。
Since this specification does not recommend one specific syntax, protocol specifications that use escapes MUST define the syntax they are using, including any necessary escapes to permit the escape sequence to be used literally.
この仕様は、ある特定の構文を推奨していませんので、エスケープを使用するプロトコル仕様は、文字通り、使用するエスケープシーケンスを可能にするために、任意の必要なエスケープを含め、彼らが使用している構文を定義しなければなりません。
The application designer selecting a format should consider at least the following factors:
形式を選択するアプリケーションの設計者は、少なくとも次の要因を考慮する必要があります。
o If similar or related protocols already use one form, it may be best to select that form for consistency and predictability.
類似または関連するプロトコルがすでに一つの形式を使用している場合は、O、それは一貫性と予測可能性のためにそのフォームを選択するのが最善かもしれません。
o A Unicode code point can fall in the range from U+0000 to U+10FFFF. Different escape systems may use four, five, six, or eight hexadecimal digits. To avoid clever syntax tricks and the consequent risk of confusion and errors, forms that use explicit string delimiters are generally preferred over other alternatives. In many contexts, symmetric paired delimiters are easier to recognize and understand than visually unrelated ones.
UnicodeコードポイントoをU + 0000からU + 10FFFFの範囲に入ることができます。別の脱出システムは4、5、6、または8桁の16進数を使用することができます。巧妙な構文のトリックと混乱とエラーの結果としてのリスクを回避するために、明示的な文字列の区切り文字を使用するフォームは、一般的に他の選択肢よりも優先されます。多くの状況では、対称性は、区切り文字を認識し、視覚的に無関係なものよりも理解しやすくなりますペア。
o Syntax forms starting in "\u", without explicit delimiters, have been used in several different escape systems, including the four or eight digit syntax of C [ISO-C] (see Section 6.1), the UTF-16 encoding of Java [Java] (see Section 6.3), and some arrangements that may follow the "\u" with four, five, or six digits. The possible confusion about which option is actually being used may argue against use of any of these forms.
明示的な区切り文字なし「\ U」で始まるO構文の形式は、Cの4または8桁の構文など、いくつかの異なる脱出システムで使用されている[ISO-C]、ジャワのUTF-16エンコーディングを（6.1節を参照してください） [Javaは]（6.3節を参照）、4、5、または6桁で「\ U」に続くかもしれないいくつかのアレンジメント。オプションは、実際に使用されているかについての可能な混乱は、これらの形態のいずれかの使用に反論します。
o Forms that require decoding surrogate pairs share most of the problems that appear with encoding of UTF-8 octets. Internet protocols SHOULD NOT use surrogate pairs.
サロゲートペアをデコードする必要がOフォームはUTF-8オクテットのエンコーディングで表示される問題のほとんどを共有しています。インターネットプロトコルは、サロゲートペアを使用しないでください。
There are a number of different ways to represent a Unicode code point position. No one of them appears to be "best" for all contexts. In addition, when an escape is needed for the escape mechanism itself, the optimal one of those might differ from one context to another.
Unicodeコードポイントの位置を表すために多くの異なる方法があります。彼らの誰もが、すべてのコンテキストのための「最善」と表示されません。また、エスケープはエスケープメカニズム自体のために必要とされるとき、それらの最適なものは、別のコンテキストから異なる場合があります。
Some forms that are in popular use and that might reasonably be considered for use in a given protocol are described below and identified with a current-use context when feasible. The two in this section are recommended for use in Internet Protocols. Other popular ones appear in Section 6 with some discussion of their disadvantages.
人気が使用されており、それが合理的に与えられたプロトコルで使用するために考えられるかもしれないいくつかの形態を以下に記載し、可能な場合、現在使用中のコンテキストで識別されています。このセクションでは2つのインターネットプロトコルで使用するために推奨されています。他の人気のあるものは、自分の欠点のいくつかの議論と、セクション6に表示されます。
One of the recommended forms is a variation of the many forms that start in "\u" (See, e.g., Section 6.1, below>), but uses explicit delimiters for the reasons discussed elsewhere.
推奨される形態の1つは、（>以下、例えば、6.1節を参照）は「\ U」でスタート多くの形態の変化であるが、他の場所で説明する理由の明示的な区切り文字を使用しています。
Specifically, in ABNF [RFC5234],
具体的には、ABNF [RFC5234]で、
EmbeddedUnicodeChar = %x5C.75.27 4*6HEXDIG %x27 ; starting with lowercase "\u" and "'" and ending with "'". ; Note that the encodings are considered to be abstractions ; for the relevant characters, not designations of specific ; octets.
EmbeddedUnicodeChar =％x5C.75.27 4 * 6HEXDIGの％のX27。小文字の「\ U」と「「」で始まるで終わります「」」。 ;エンコーディングを抽象化であると考えられていることに注意してください。関連する文字ではなく、特定の名称について。オクテット。
HEXDIG = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" ; effectively identical with definition in RFC 5234.
HEXDIG = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F"。 RFC 5234で定義して効果的に同じ。
Protocol designers of applications using this form should specify a way to escape the introducing backslash ("\"), if needed. "\\" is one obvious possibility, but not the only one.
必要な場合は、このフォームを使用してアプリケーションのプロトコル設計者は、導入バックスラッシュ（「\」）をエスケープする方法を指定する必要があります。 「\\」は、一つ明白な可能性ではなく、唯一のものです。
The other recommended form is the one used in XML. It uses the form "&#xNNNN;". Like the Perl form (Section 6.2), this form has a clear ending delimiter, reducing ambiguity. HTML uses a similar form, but the semicolon may be omitted in some cases. If that is done, the advantages of the delimiter disappear so that the HTML form without the semicolon SHOULD NOT be used. However, this format is often considered ugly and awkward outside of its native HTML, XML, and similar contexts.
その他の推奨形式はXMLで使用されるものです。これは、フォームを使用しています「＆#xNNNN;」。 Perlの形態（セクション6.2）のように、このフォームは、曖昧さを減らす、クリア終了デリミタを有します。 HTMLは、同様の形式を使用しますが、セミコロンは、いくつかの例では省略されてもよいです。それが行われている場合は、セミコロンなしでHTMLフォームを使用すべきでないように、区切り文字の利点が消えます。しかし、この形式は、多くの場合、そのネイティブHTML、XML、および同様の文脈の外で醜いとぎこちないと考えられています。
In ABNF:
ABNFには：
EmbeddedUnicodeChar = %x26.23.78 2*6HEXDIG %x3B ; starts with "&#x" and ends with ";"
EmbeddedUnicodeChar =％x26.23.78 2 * 6HEXDIG％のX3B。 「＆＃X」で始まるで終わります「;」
Note that a literal "&" can be expressed by "&" when using this style.
リテラル「＆」で表すことができることに注意してください「＃のX26＆;」このスタイルを使用した場合。
The forms
フォーム
\UNNNNNNNN (for any Unicode character) and
\（任意のUnicode文字用）UNNNNNNNNと
\uNNNN (for Unicode characters in plane 0)
（プレーン0にUnicode文字用）\ uNNNN
are utilized in the C Programming Language [ISO-C] when an ASCII escape for embedded Unicode characters is needed.
埋め込まれたUnicode文字のASCIIエスケープが必要な場合Cプログラミング言語[ISO-C]で利用されています。
There are disadvantages of this form that may be significant. First, the use of a case variation (between "u" for the four-digit form and "U" for the eight-digit form) may not seem natural in environments where uppercase and lowercase characters are generally considered equivalent and might be confusing to people who are not very familiar with Latin-based alphabets (although those people might have even more trouble reading relevant English text and explanations). Second, as discussed in Section 4, the very fact that there are several different conventions that start in \u or \U may become a source of confusion as people make incorrect assumptions about what they are looking at.
重要であるかもしれこの形式の欠点があります。まず、（4桁のフォームの「U」、8桁の形式は、「U」の間）ケース変形の使用は、大文字と小文字は、一般的等価であると考えられるとの混乱を招くかもしれない環境で自然に見えるないかもしれませんラテン語ベースのアルファベット（これらの人々は、さらにトラブル関連する英語のテキストと解説を読んを持っているかもしれませんが）に精通していない人。第4節で述べたように、第2、人々は、彼らが見ているのかについて間違った仮定を行うと混乱の原因になることがあり、\ uまたは\ Uで開始し、いくつかの異なる慣習があるという事実であることを。
Perl uses the form \x{NNNN...}. The advantage of this form is that there are explicit delimiters, resolving the issue of having variable-length strings or using the case-change mechanism of the proposed form to distinguish between Plane 0 and more general forms. Some other programming languages would tend to favor X'NNNN...' forms for hexadecimal strings and perhaps U'NNNN...' for Unicode-specific strings, but those forms do not seem to be in use around the IETF.
Perlは{...} NNNN形式\ xを使用します。この形態の利点は、可変長文字列を有するか、プレーン0、より一般的な形を区別するために提案されたフォームの場合変化機構を使用して問題を解決し、明示的な区切り文字があることです。いくつかの他のプログラミング言語には、「フォームU'NNNN 16進文字列のため、おそらく...」のUnicode固有の文字列のための... X'NNNNを好む傾向があるだろうが、これらのフォームは、IETFの周りに使用中であるように思えません。
Note that there is a possible ambiguity in how two-character or low-numbered sequences in this notation are understood, i.e., that octets in the range \x(00) through \x(FF) may be construed as being in the local character set, not as Unicode code points. Because of this apparent ambiguity, and because IETF documents do not contain provision for pragmas (see [PERLUniIntro] for more information about the "encoding" pragma in Perl and other details), the Perl forms should be used with extreme caution, if at all.
\ X（FF）までの範囲の\×（00）のオクテットがローカル文字であると解釈することができること、すなわち、この表記で2文字または低番号の配列が理解されている方法で可能な曖昧さがあることに注意してくださいないUnicodeコードポイントとして設定。 IETF文書はプラグマのための引当金（Perlやその他の詳細で「エンコーディング」プラグマの詳細については、[PERLUniIntro]参照）が含まれていないため、この明らかな曖昧さの、およびので、まったく場合は、Perlのフォームは、細心の注意を払って使用する必要があります。
Java [Java] uses the form \uNNNN, but as a reference to UTF-16 values, not to Unicode code points. While it uses a syntax similar to that described in Section 6.1, this relationship to UTF-16 makes it, in many respects, more similar to the encodings of UTF-8 discussed above than to an escape that designates Unicode code points. Note that the UTF-16 form, and hence, the Java escape notation, can represent characters outside Plane 0 (i.e., above U+FFFF) only by the use of surrogate pairs, raising some of the same issues as the use of UTF-8 octets discussed above. For characters in Plane 0, the Java form is indistinguishable from the Plane 0-only form described in Section 6.1. If only for that reason, it SHOULD NOT be used as an escape except in those Java contexts in which it is natural.
Javaは、[Javaは】uNNNN \フォームを使用するが、UTF-16値を参照としてではなく、Unicodeコードポイントへ。それは、セクション6.1に記載したのと同様の構文を使用しながら、UTF-16に、この関係は、Unicodeコードポイントを指定エスケープよりもUTF-8上述のエンコーディングにも、多くの点で、より類似させます。 UTF-16形は、従って、Javaのエスケープ表記は、UTF-の使用と同じ問題のいくつかを上げ、のみサロゲートペアを使用することによって（U + FFFF上記すなわち、）プレーン0以外の文字を表すことができることに注意してください8つのオクテットは、前述します。プレーン0の文字については、Javaフォームは、6.1節で説明したプレーン0のみの形式と区別できません。唯一その理由であれば、それは自然であるこれらのJavaのコンテキストを除いてエスケープとして使用しないでください。
This document proposes a set of rules for encoding Unicode characters when other considerations do not apply. Since all of the recommended encodings are unambiguous and normalization issues are not involved, it should not introduce any security issues that are not present as a result of simple use of non-ASCII characters, no matter how they are encoded. The mechanisms suggested should slightly lower the risks of confusing users with encoded characters by making the identity of the characters being used somewhat more obvious than some of the alternatives.
この文書では、他の考慮事項が適用されないときのUnicode文字をエンコードするための一連のルールを提案しています。推奨されるエンコーディングのすべてがあいまいであり、正規化の問題が関与していないので、それは関係なく、彼らがどのようにエンコードされるか非ASCII文字の簡単な使用の結果として存在していない任意のセキュリティ上の問題を導入していないではないはずです。提案メカニズムは少しの選択肢のいくつかよりもいくらか明らかに使用されている文字のアイデンティティを作ることによってエンコードされた文字と混乱のユーザーのリスクを下げる必要があります。
An escape mechanism such as the one specified in this document can allow characters to be represented in more than one way. Where software interprets the escaped form, there is a risk that security checks, and any necessary checks for, e.g., minimal or normalized forms, are done at the wrong point.
この文書で指定したものとエスケープメカニズムなどは、文字が複数の方法で表現することができるようにすることができます。ソフトウェアは、エスケープ形式を解釈する場合、セキュリティチェック、及び、のために必要なチェックは、例えば、最小または正規化された形態は、間違った時点で行われるおそれがあります。
This document was produced in response to a series of discussions within the IETF Applications Area and as part of work on email internationalization and internationalized domain name updates. It is a synthesis of a large number of discussions, the comments of the participants in which are gratefully acknowledged. The help of Mark Davis in constructing a list of alternative presentations and selecting among them was especially important.
この文書は、IETFアプリケーションエリア内や電子メールの国際化と国際化ドメイン名の更新に関する作業の一環として、議論の一連のに反応して生成しました。それは議論の多数、深く感謝している参加者のコメントの合成です。代替プレゼンテーションのリストを構築し、それらの間の選択でマーク・デイビスのヘルプが特に重要でした。
Tim Bray, Peter Constable, Stephane Bortzmeyer, Chris Newman, Frank Ellermann, Clive D.W. Feather, Philip Guenther, Bjoern Hoehrmann, Simon Josefsson, Bill McQuillan, der Mouse, Phil Pennock, and Julian Reschke provided careful reading and some corrections and suggestions on the various working drafts that preceded this document. Taken together, their suggestions motivated the significant revision of this document and its recommendations between version -00 and version -01 and further improvements in the subsequent versions.
ティム・ブレイ、ピーター・コンスタブル、ステファンBortzmeyer、クリス・ニューマン、フランク・Ellermann、クライヴD.W.フェザー、フィリップ・ギュンター、ビョルンHoehrmann、サイモンJosefsson氏は、ビルMcQuillan氏の説明による、デア・マウス、フィル・ペノック、そしてジュリアンReschkeは熟読し、この文書を先行し、様々な草案にいくつかの修正と提案を提供しました。まとめると、彼らの提案は、重要な、この文書の改訂とその後のバージョンでバージョン-00とバージョン-01とさらなる改善との勧告を動機。
[ISO10646] International Organization for Standardization, "Information Technology -- Universal Multiple-Octet Coded Character Set (UCS)", ISO/ IEC 10646:2003, December 2003.
[ISO10646]国際標準化機構、 "情報技術 - ユニバーサルマルチオクテット符号化文字セット（UCS）"、ISO / IEC 10646：2003、2003年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2006. (Addison-Wesley, 2006. ISBN 0-321-48091-0).
[UNICODE]ユニコードコンソーシアム、 "Unicode規格、バージョン5.0"、2006年（アディソン - ウェズリー、2006 ISBN 0-321-48091-0）。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4- 1968, 1968.
[ASCII]米国規格協会（アメリカ規格協会の旧米国）、「情報交換用米国コード」、ANSI X3.4- 1968、1968。
ANSI X3.4-1968 has been replaced by newer versions
with slight modifications, but the 1968 version
remains definitive for the Internet.
[ISO-C] International Organization for Standardization, "Information technology -- Programming languages -- C", ISO/IEC 9899:1999, 1999.
[ISO-C]国際標準化機構、 "情報技術 - プログラミング言語 - C"、ISO / IEC 9899：1999 1999。
[Java] Sun Microsystems, Inc., "Java Language Specification, Third Edition", 2005, <http:// java.sun.com/docs/books/jls/third_edition/html/ lexical.html#95413p>.
[Javaの]サン・マイクロシステムズ社、 "Java言語仕様第3版"、2005年、<のhttp：// java.sun.com/docs/books/jls/third_edition/html/ lexical.html＃95413p>。
[PERLUniIntro] Hietaniemi, J., "perluniintro", Perl documentation 5.8.8, 2002, <http://perldoc.perl.org/perluniintro.html>.
【PERLUniIntro] Hietaniemi、J.、 "perluniintro、" パール5.8.8ドキュメント2002 <http://perldoc.perl.org/perluniintro.html>。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、 "ピュニコード：アプリケーションにおける国際化ドメイン名のUnicodeのブートストリングのエンコード（IDNA）"、RFC 3492、2003年3月。
[UnicodeGlossary] The Unicode Consortium, "Glossary of Unicode Terms", June 2007, <http://www.unicode.org/glossary>.
[UnicodeGlossary]はUnicodeコンソーシアム、 "ユニコード用語集"、2007年6月、<http://www.unicode.org/glossary>。
[W3C-CharMod] Duerst, M., "Character Model for the World Wide Web 1.0", W3C Recommendation, February 2005, <http://www.w3.org/TR/charmod/>.
[W3C-CHARMOD] Duerst、M.、W3C勧告 "ワールド・ワイド・ウェブ1.0の文字モデル"、2005年2月、<http://www.w3.org/TR/charmod/>。
Appendix A. Formal Syntax for Forms Not Recommended
フォームの付録A.正式な構文は推奨されません
While the syntax for the escape forms that are not recommended above (see Section 6) are not given inline in the hope of discouraging their use, they are provided in this appendix in the hope that those who choose to use them will do so consistently. The reader is cautioned that some of these forms are not defined precisely in the original specifications and that others have evolved over time in ways that are not precisely consistent. Consequently, these definitions are not normative and may not even precisely match reasonable interpretations of their sources.
（セクション6を参照）上記の推奨されていないエスケープ形式の構文は、その使用を落胆の希望にインラインで与えられていないが、それらは、それらを使用することを選択した人たちがそう一貫して行いますことを期待して、この付録で提供されています。読者は、これらの形態のいくつかは、元の仕様に正確に定義し、他の人が正確に一致していない方法で、時間をかけて進化してきたことをされていないと警告しています。その結果、これらの定義は規範的ではないとさえ正確にそのソースの合理的な解釈と一致しない場合があります。
The definition of "HEXDIG" for the forms that follow appears in Section 5.1.
続くフォームのための「HEXDIG」の定義は、セクション5.1で表示されます。
A.1. The C Programming Language Form
A.1。 Cプログラミング言語フォーム
Specifically, in ABNF [RFC5234],
具体的には、ABNF [RFC5234]で、
EmbeddedUnicodeChar = BMP-form / Full-form
EmbeddedUnicodeChar = BMP形式/フルフォーム
BMP-form = %x5C.75 4HEXDIG ; starting with lowercase "\u" ; The encodings are considered to be abstractions for the ; relevant characters, not designations of specific octets.
BMP-形式=％x5C.75 4HEXDIG。小文字の「\ U」で始まります。エンコーディングがための抽象化であると考えられています。関連する文字ではなく、特定のオクテットの名称。
Full-form = %x5C.55 8HEXDIG ; starting with uppercase "\U"
フルフォーム=％x5C.55 8HEXDIG。大文字で始まる「\ U」
A.2. Perl Form
A.2。 Perlのフォーム
EmbeddedUnicodeChar = %x5C.78 "{" 2*6HEXDIG "}" ; starts with "\x"
EmbeddedUnicodeChar =％x5C.78 "{" 2 * 6HEXDIG "}"。 「\のX」で始まります
A.3. Java Form
A.3。 Javaのフォーム
EmbeddedUnicodeChar = %x5C.7A 4HEXDIG ; starts with "\u"
EmbeddedUnicodeChar =％x5C.7A 4HEXDIG。 「\ U」で始まります
Author's Address
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 245 1457 EMail: john-ietf@jck.com
電話：+1 617 245 1457 Eメール：john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。