[要約] RFC 5137は、Unicode文字のASCIIエスケープに関する規格であり、Unicode文字をASCIIエスケープ形式で表現する方法を提供します。このRFCの目的は、Unicode文字をASCIIエスケープ形式で表現することにより、異なるシステム間でのデータの互換性を確保することです。
Network Working Group J. Klensin
Request for Comments: 5137 February 2008
BCP: 137
Category: Best Current Practice
ASCII Escaping of Unicode Characters
Unicode文字のASCII脱出
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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コーディングでは、伝統的な脱出は、さまざまな方法で書かれた文字の小数または16進数の数値でした。文字が2つ以上のオクテットを占有し、いくつかの異なる形式でコード化される可能性のあるUnicodeへの移動は、エスケープの問題をさらに複雑にしています。このドキュメントでは、現在使用されているいくつかのオプションについて説明し、新しいIETFプロトコルで使用するためのものを選択するための考慮事項と、現在国際化されているプロトコルについて説明します。
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]コーディングでは、伝統的な脱出は、さまざまな方法で書かれた文字の小数または16進数の数値でした。たとえば、さまざまなコンテキストでは、小数形態で％dnnまたは％nn、％nn、％xnn、x'nn '、および16進数で％x'nn'を見ています。「％NN」は、おそらくURLでの使用とその有病率での使用の結果として、さらなる資格なしに六足数を表すために近年一般的になりました。オクタル形式が使用されるアプリケーションもいくつかあり、それらはうまく一般化されていませんが、引用された印刷可能でエンコードされた単語形式は、さらに別の脱出セットと考えることができます。したがって、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:
文字が2つ以上のオクテットを占有し、いくつかの異なる形でコード化される可能性があるUnicode [Unicode] [ISO10646]に移動すると、脱出の問題はさらに複雑になります。Unicodeは、文字をコードポイントとして表します。0から10ffffまでの数値。流れるテキストのコードポイントを参照する場合、u 0000からu 10ffffまでの値として、いわゆる「u」表記を使用して表現されます。オクテットにシリアル化すると、これらのコードポイントはさまざまな形式で表現できます。
o in UTF-8 with one to four octets [RFC3629]
o 1〜4オクテットのUTF-8で[RFC3629]
o in UTF-16 with two or four octets (or one or two seizets -- 16-bit units)
o 2つまたは4つのオクテット（または1つまたは2つの震え-16ビットユニット）を備えたUTF-16で
o in UTF-32 with exactly four octets (or one 32-bit unit)
o 正確に4オクテット（または1つの32ビットユニット）を備えたUTF-32で
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]に従って、人間の使用のためにテキストコンテンツを携帯するために必要な新しいプロトコルは、ユニコード文字の完全なレパートリーがそのテキストに表されるように設計する必要があります。
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.
このドキュメントでは、ユニコード文字列を処理するか、その内容について一般的な推奨事項を作成しません。逃げたいと思う文字列は有効かつ合理的であり、「有効で合理的」の定義は他の文書の州であると仮定しています。ユニコード文字列の一般的な処理に関する推奨事項は、ユニコード標準自体と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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Additional Unicode-specific terminology appears in [UnicodeGlossary], but is not necessary for understanding this specification.
追加のユニコード固有の用語は[UnicodeGlossary]に表示されますが、この仕様を理解するためには必要ありません。
Discussion of this document should be addressed to the discuss@apps.ietf.org mailing list.
このドキュメントの議論は、discuse@apps.ietf.orgメーリングリストに宛ててください。
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:
ユニコード文字を逃れる方法の2つの主要な家族があります。1つはいくつかの表現のコードポイントを使用し（次のセクションを参照）、もう1つはUTF-8エンコードのオクテットまたはいくつかの表現でその他のエンコードをエンコードします。他のいくつかのオプションは可能ですが、実際にはまれです。この仕様では、魅力的な理由がない場合は、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プロトコルが成功した理由の1つは、一般的にコンピュータープログラム（またはアルゴリズムのハンドシミュレーション）を必要とするエンコーディングではなく、人間が解釈可能なテキストフォームを使用して通信するためです。これは、プレゼンテーションフォームが文字の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.
o UTF-8の性質のため、人間がUTF-8オクテットの小数または六十数の数値表現を解釈するには、テーブル内の文字を検索するために使用できるユニコードコードポイントを決定するために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 UnicodeのASCIIサブセット（U 0000からU 007F）の文字を除き、コードポイントフォームは、一般に、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エンコーディングのオクテットの表現に適用される同じ考慮事項は、「Punycode」プロファイルの有無にかかわらず[RFC3492]エンコード[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.
同様の考慮事項は、Javaで使用されている\ unnnnフォームなど、UTF-16エンコーディングにも適用されます（セクション6.3を参照）。これらのフォームは、基本的な多言語平面（BMP、平面0）のコードポイント参照に相当しますが、サロゲートを処理してより高い平面にアクセスするには、2段階のデコードプロセスが必要です。
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.
プロトコルまたは同様のコンテキストでのユニコード文字のエスケープについてどの決定が下されているかに関係なく、Unicodeコードポイントを参照するテキストは、Uncode標準で指定されているように、u nnnn [n [n]]構文を使用する必要があります。文字列は16進数で構成されています。実際にユニコード文字を含むテキストは、自動処理に適した構文を使用する必要があります。
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.
コードポイントエスケープには多くのオプションがあり、その一部は以下に要約されています。すべてがコンテンツとセマンティクスに同等です - 違いは構文にあります。特定のプロトコルまたはその他のアプリケーションの構文の最良の選択は、そのアプリケーションに依存します。1つのフォームは、特定のコンテキストで他の形状よりも「適合」する場合があります。ただし、他の選択肢よりも16進数が好ましいことは明らかです。1進または眼窩のオフセットに基づくシステムは使用しないでください。
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 類似または関連するプロトコルがすでに1つのフォームを使用している場合、一貫性と予測可能性のためにそのフォームを選択するのが最善かもしれません。
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.
o Unicodeコードポイントは、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.
o 明示的な区切り文字なしの「\ u」から始まる構文形式は、C [ISO-C]の4桁または8桁の構文を含むいくつかの異なるエスケープシステムで使用されています（セクション6.1を参照）、JavaのUTF-16エンコーディング[Java]（セクション6.3を参照）、および「\ u」に続くのは4、5、または6桁である。実際にどのオプションが使用されているかについての混乱の可能性は、これらのフォームの使用に反対する可能性があります。
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.
ユニコードコードポイント位置を表すには、さまざまな方法があります。それらの誰も、すべてのコンテキストにとって「最良」であるようには見えません。さらに、エスケープメカニズム自体に脱出が必要な場合、それらの最適なメカニズムがコンテキストごとに異なる場合があります。
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つは、「\ u」で始まる多くのフォームのバリエーションです（例えば、セクション6.1、以下の>を参照）が、他の場所で説明する理由で明示的なデリミターを使用します。
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.
HEXDIG = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"A" / "B" / "C" / "D" / "E" / "F"
; effectively identical with definition in 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.
このフォームを使用したアプリケーションのプロトコル設計者は、必要に応じて、導入バックスラッシュ（ "\"）を逃れる方法を指定する必要があります。「\\」は明らかな可能性の1つですが、唯一の可能性はありません。
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.
もう1つの推奨フォームは、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 ";"
Note that a literal "&" can be expressed by "&" when using this style.
文字通りの「＆」は「＆＃x26;」で表現できることに注意してください。このスタイルを使用する場合。
The forms
フォーム
\UNNNNNNNN (for any Unicode character) and
\ unnnnnnnn（任意のユニコード文字用）および
\uNNNN (for Unicode characters in plane 0)
\ unnnn（平面0のユニコード文字用）
are utilized in the C Programming Language [ISO-C] when an ASCII escape for embedded Unicode characters is needed.
Cプログラミング言語[ISO-C]で使用されています。ASCIIが組み込まれたUnicode文字のエスケープが必要です。
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で説明したように、\ 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はフォーム\ x {nnnn ...}を使用します。この形式の利点は、明示的な区切り文字があり、さまざまな長さの文字列を持っているという問題を解決するか、提案された形式のケース変更メカニズムを使用して平面0とより一般的な形式を区別することです。他のプログラミング言語の中には、x'nnnnを支持する傾向があります... 'は16進の文字列と、おそらくU'nnnn ...' 'Forms for unicode固有の文字列を使用する傾向がありますが、これらのフォームは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.
この表記法の2文字または低い数のシーケンスがどのように理解されるかには曖昧さがあります。ユニコードコードポイントとしてではなく、設定します。この明らかなあいまいさのため、および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値への参照として、コードポイントではありません。セクション6.1で説明されているものと同様の構文を使用しますが、UTF-16とのこの関係は、多くの点で、Unicodeコードポイントを指定する脱出よりも上記のUTF-8のエンコーディングに似ています。UTF-16フォーム、したがって、Javaエスケープ表記は、サロゲートペアを使用することによってのみ平面0（つまり、U上記のU FFFF）の外側の文字を表すことができることに注意してください。上記のオクテット。平面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.
このドキュメントは、他の考慮事項が適用されない場合に、ユニコード文字をエンコードするための一連のルールを提案します。推奨されるすべてのエンコーディングは明確であり、正規化の問題は関係していないため、エンコードされていても、非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.
ティム・ブレイ、ピーター・コンスタブル、ステファン・ボルツマイヤー、クリス・ニューマン、フランク・エラーマン、クライヴD.W.Feather、Philip Guenther、Bjoern Hoehrmann、Simon Josefsson、Bill McQuillan、Der Mouse、Phil Pennock、およびJulian 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、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 Consortium、「Unicode Standard、バージョン5.0」、2006。（Addison-Wesley、2006。ISBN0-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] American National Standards Institute（以前のアメリカ合衆国標準研究所）、「米国情報インターチェンジのコード」、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.
ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットにとって決定的なままです。
[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] Sun Microsystems、Inc。、「Java Language Specification、Third Edition」、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"、Perl Documentation 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] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[UnicodeGlossary] The Unicode Consortium, "Glossary of Unicode Terms", June 2007, <http://www.unicode.org/glossary>.
[UnicodeGlossary] Unicode Consortium、「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。、「World Wide Web 1.0のキャラクターモデル」、W3C推奨、2005年2月、<http://www.w3.org/tr/charmod/>。
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に表示されます。
Specifically, in ABNF [RFC5234],
具体的には、ABNF [RFC5234]では、
EmbeddedUnicodeChar = BMP-form / Full-form
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.
Full-form = %x5C.55 8HEXDIG ; starting with uppercase "\U"
EmbeddedUnicodeChar = %x5C.78 "{" 2*6HEXDIG "}" ; starts with "\x"
EmbeddedUnicodeChar = %x5C.7A 4HEXDIG ; starts with "\u"
Author's Address
著者の連絡先
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 245 1457
EMail: john-ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。