RFC5137 日本語訳
5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT=27742 bytes) (Also BCP0137) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 5137 February 2008 BCP: 137 Category: Best Current Practice
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5137 2008年2月のBCP: 137カテゴリ: 最も良い現在の習慣
ASCII Escaping of Unicode Characters
ユニコードキャラクターの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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネット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コード化で、伝統的なエスケープは、小数かさまざまな異なった方法で書かれているキャラクタの16進の数値値のどちらかです。 ユニコードへの移動はキャラクタが2つ以上の八重奏を占領して、いくつかの異なったフォームでコード化されるかもしれないところでさらにエスケープの問題を複雑にしました。 このドキュメントは、新しいIETFプロトコル、および現在国際的にされているプロトコルで、現在使用中のいくつかのオプションについて議論して、使用のための1つを選択するために問題について議論します。
Klensin Best Current Practice [Page 1] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[1ページ]RFC5137ユニコードは2008年2月に逃げられます。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 文脈とバックグラウンド. . . . . . . . . . . . . . . . . . 3 1.2。 用語. . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 ディスカッション・リスト. . . . . . . . . . . . . . . . . . . . . 4 2。 Encodings、そのRepresentユニコードCode Points: UTF-8かUTF-16八重奏. . . . . . . . . . . . 4 3に対して位置をコード化してください。 ユニコードキャラクター. . . . . . . . . . . . . . . 5 4を参照します。 コード・ポイント構文は.6 5から逃げます。 ユニコードコードのためのお勧めのプレゼンテーション異形はミッドナイト・ゾーン. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1を指します。 デリミタ. . . . . . . . . . . . . . . 7 5.2があるバックスラッシュU。 XMLとHTML. . . . . . . . . . . . . . . . . . . . . . . 7 6。 そのAre Normally Not Recommended. . . . . . . . . . . 8 6.1を形成します。 Cプログラミング言語: バックスラッシュU.86.2。 Perl: 16進ストリング. . . . . . . . . . . . . . . . 8 6.3。 Java: UTF-16. . . . . . . . . . . . . . . . . . . 9 7から逃げました。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 10 9.2。 フォームのための有益な参照. . . . . . . . . . . . . . . . . . 10の付録のA.の正式な構文は.12A.1を推薦しませんでした。 Cプログラミング言語形式. . . . . . . . . . . . . 12A.2。 Perlフォーム. . . . . . . . . . . . . . . . . . . . . . . . 12A.3。 Javaフォーム. . . . . . . . . . . . . . . . . . . . . . . . 12
Klensin Best Current Practice [Page 2] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[2ページ]RFC5137ユニコードは2008年2月に逃げられます。
1. Introduction
1. 序論
1.1. Context and Background
1.1. 文脈とバックグラウンド
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」は近年さらなる資格なしで16進値を表すためにポピュラーになりました、恐らくURLの使用の結果と彼らの普及として。 フォームがどの8進が使用されているかの周りにいくつかの利用さえあります、そして、よく総合しませんが、Quoted印刷可能なMIMEとEncoded-語形はまだもう1セットのエスケープという考えであるかもしれません。 ASCIIのかなり簡単なケースとASCIIを広げることによって造られた8859年のISO家などの規格のためにさえ、私たちはいくつかの異なったエスケープフォームを受け入れていて、それぞれが何らかの歴史の結果です。
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つ以上の八重奏を占領するユニコード[ユニコード][ISO10646]に動いて、いくつかの異なったフォームでコード化されるとき、エスケープの問題はさらに複雑になります。 コードが指すとき、ユニコードはキャラクタの代理をします: 数値は0〜十六進法まで10FFFFを評価します。 流れているテキストでコード・ポイントに参照をつけるとき、それらはいわゆる「U+」記法を使用することで表されます、U+0000からU+10FFFFまでの値として。 八重奏に連載されると、異なったフォームでこれらのコード・ポイントを表すことができます:
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つの八重奏があるUTF-16でまたは、(1か2seizets--、16ビットのユニット)
o in UTF-32 with exactly four octets (or one 32-bit unit)
o まさに4つの八重奏があるUTF-32で(32ビットの1個のユニット)
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.
キャラクタから逃げるとき、私たちは両方の連載された形式の16進表現とコードポイントエスケープとして知られているU+記法の変化の大規模な使用を公正に見ました。
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]、人間が使うために原文の内容SHOULDを運ぶのに必要である新しいプロトコルに従って、ユニコード文字の完全なレパートリーがそのテキストに表されるかもしれないような方法で設計されてください。
Klensin Best Current Practice [Page 3] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[3ページ]RFC5137ユニコードは2008年2月に逃げられます。
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.
このドキュメントは国際的にされる、その既存のプロトコル、および逃避機制を必要とするものを提案して、SHOULDは、他の問題がここで説明されたものより重くないならセクション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を受け入れるプロトコルかユニコードのある他のコード化に適切ではありません。 プロトコルが国際的にされるとき、一般に、エスケープを使用するよりむしろそれらのフォームを受け入れるのは望ましいです。 この推薦は変遷アレンジメントを含むケースに適用されます。そこでは、それが実用的ではありません。
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.
また、この仕様に記述されたプロトコル文脈に加えて、ユニコード文字の代理をするエスケープはプレゼンテーションにユーザにとって現れます、すなわち、ユーザインタフェース(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.
このドキュメントは処理ユニコードストリングかそれらのコンテンツのために一般的な推薦状をしません。 それは人が逃げたがっているかもしれないストリングが有効であって、妥当であり、「有効で妥当」の定義が他のドキュメントの州であると仮定します。 ユニコードストリングの一般的な処理に関する推薦は多くの場所で見つけられるかもしれません、ユニコードStandard自身とW3CキャラクターModel[W3C-CharMod]を含んでいて、個々のプロトコルの特定の規則と同様に。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Additional Unicode-specific terminology appears in [UnicodeGlossary], but is not necessary for understanding this specification.
追加ユニコード特有の用語は、[UnicodeGlossary]に現れますが、この仕様を理解するのに必要ではありません。
1.3. Discussion List
1.3. ディスカッション・リスト
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
2. Encodings、そのRepresentユニコードCode Points: コード位置対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
ユニコード文字から逃げる方法の主要な2つの家族があります。 1つが何らかの表現にコード・ポイントを使用する、(次を見てください。
Klensin Best Current Practice [Page 4] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[4ページ]RFC5137ユニコードは2008年2月に逃げられます。
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:
セクション)、もう片方がUTF-8コード化か何らかの表現におけるある他のコード化の八重奏をコード化します。 ある他のオプションは可能ですが、それらは実際にはまれです。 この仕様は、別の方法でするやむにやまれない理由がないときユニコードコード・ポイントSHOULDが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つの理由は一般に、解読するために、コンピュータ・プログラム(または、アルゴリズムの手のシミュレーション)を必要とするencodingsよりむしろ交信するのに人間解明できるテキストフォームを使用するということです。 これは、表示形は単に同じくらい可能であることで、ユニコードがキャラクタ、するために見送る参照がそうするべきであると示唆します。
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の自然のために、人間が小数か16進を解釈するように、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 ユニコード(U+007Fを通したU+0000)の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コード化の八重奏の表現に適用されるのと同じ問題は、"Punycode"というプロフィールのあるなしにかかわらず[RFC3492]をコード化しながら、「bootstringなど」の、よりコンパクトなACE encodingsに適用されます。
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.
同様の問題はuNNNNフォームがJavaに使用した\などのようにUTF-16コード化に適用されます(セクション6.3を見てください)。 それらのフォームが基本多言語水準(BMP、Plane0)のポイント参照をコード化するために同等である間、2ステージの解読過程が、より高い飛行機にアクセスするために代理を扱うのに必要です。
3. Referring to Unicode Characters
3. ユニコードキャラクターを参照します。
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.
ユニコードコード・ポイントを示すプロトコルか同様の文脈、テキストのユニコード文字のためにエスケープの周りでどんな決定をするかにかかわらずSHOULDはU+NNNNを使用します。[ユニコードStandard(NNNN…ストリングは16進数から成る)で指定されるようなN[N]]構文。 実際にユニコード文字SHOULDを含むテキストが自動化された処理により適した構文を使用します。
Klensin Best Current Practice [Page 5] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[5ページ]RFC5137ユニコードは2008年2月に逃げられます。
4. Syntax for Code Point Escapes
4. コード・ポイント構文は逃げられます。
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進値が他の代替手段より望ましいのは、明確です: 小数か8進に基づくシステムはSHOULD NOTを相殺します。使用されます。
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.
この仕様が1つの特定の構文を推薦しないので、エスケープを使用するプロトコル仕様はそれらが使用している構文を定義しなければなりません、エスケープシーケンスが文字通り使用されることを許可するためにどんな必要なエスケープも含んでいて。
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 ユニコードコード・ポイントは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[Java]のUTF-16コード化(セクション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八重奏のコード化で現れる問題の大部分を共有します。 インターネットプロトコルSHOULD NOTは代理の組を使用します。
Klensin Best Current Practice [Page 6] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[6ページ]RFC5137ユニコードは2008年2月に逃げられます。
5. Recommended Presentation Variants for Unicode Code Point Escapes
5. ユニコードコード・ポイントミッドナイト・ゾーンのためのお勧めのプレゼンテーション異形
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.
ユニコードコードポイント位置を表す多くの異なった方法があります。 彼らのだれも、すべての文脈に「最も良い」ように見えません。 エスケープが逃避機制自体に必要であるときに、さらに、それらの力の最適の1つはある文脈から別の文脈まで異なります。
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にそれらの損失の何らかの議論で現れます。
5.1. Backslash-U with Delimiters
5.1. デリミタがあるバックスラッシュU
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.
EmbeddedUnicodeChar=%x5C.75.27 4*6HEXDIG%x27。 そして、そして、「小文字をきっかけに」\u」、「'、「終わる、「'「.'」 ; encodingsが抽象化であると考えられることに注意してください。 特定の名称ではなく、関連キャラクタのために。 八重奏。
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」」 事実上、RFC5234との定義と同じです。
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つの明白な可能性です。
5.2. XML and HTML
5.2. XMLとHTML
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がセミコロンSHOULD NOTなしで形成されるなら、使用されてください。 しかしながら、この形式は外で固有のHTML、XML、および同様の文脈で醜くて、無器用であるとしばしば考えられます。
Klensin Best Current Practice [Page 7] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[7ページ]RFC5137ユニコードは2008年2月に逃げられます。
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が文字通りの“&"を急送できることに注意してください」 このスタイルを使用するとき。
6. Forms that Are Normally Not Recommended
6. そのAre Normally Not Recommendedを形成します。
6.1. The C Programming Language: Backslash-U
6.1. Cプログラミング言語: バックスラッシュU
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.
埋め込まれたユニコード文字のためのASCIIエスケープが必要であるときに、C Programming Language[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」の間の)の使用は、一般に、大文字していて小文字のキャラクタが同等であると考えられる環境で自然に見えないで、それほどラテン語ベースのアルファベットに詳しくない人々に混乱させられるかもしれません(それらの人々は関連英文と説明を読むことにおけるさらに多くの苦労をするかもしれませんが)。 2番目に、セクション4で議論するように、人々がそれらが何を見るかに関する不正確な仮定をするとき、\uか\Uで始まる数人の異なったコンベンションがあるというまさしくその事実は混乱の源になるかもしれません。
6.2. Perl: A Hexadecimal String
6.2. Perl: 16進ストリング
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を…使用します。 このフォームの利点は明白なデリミタがあるということです、可変長文字列を持っているか、またはPlane0と、より一般的な用紙を見分けるのに提案されたフォームのケース変化メカニズムを使用する問題を解決して。ある他のプログラミング言語は、X'NNNNを支持する傾向があるでしょう…'16進ストリングと恐らくU'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
この記法による2キャラクタか低番号付の系列がどう理解されているかの可能なあいまいさがあって、すなわち、\x(FF)を通した範囲\x(00)の八重奏がローカルキャラクターセットにはユニコードコード・ポイントにあるのではなく、あるのに理解されるかもしれないことに注意してください。 この見かけのあいまいさ、IETFドキュメントがそうしない、含有
Klensin Best Current Practice [Page 8] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[8ページ]RFC5137ユニコードは2008年2月に逃げられます。
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.
pragmas(pragmaのPerlと他の詳細に「コード化」であることに関する詳しい情報に関して[PERLUniIntro]を見る)への支給、Perlフォームは細心の注意を払ってせいぜい使用されるべきです。
6.3. Java: Escaped UTF-16
6.3. Java: 逃げられたUTF-16
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とのこの関係で、それはあらゆる点でコード・ポイントにユニコードを指定するエスケープより上で議論したUTF-8のencodingsと同様になります。 UTF-16フォーム、およびしたがって、Javaエスケープ記法がPlane0(すなわち、U+FFFFの上の)の外で単に代理の組の使用でキャラクタの代理をすることができることに注意してください、上で議論したUTF-8八重奏の使用と同じ問題のいくつかを提起して。 Plane0のキャラクタにおいて、Javaフォームはセクション6.1で説明されたPlane0だけフォームから区別がつきません。 それは推論して、それはSHOULD NOTです。唯一、エスケープとして、それが当然であるそれらのJava文脈を除いて、使用されてください。
7. Security Considerations
7. セキュリティ問題
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.
このドキュメントは他の問題が適用されないときユニコード文字をコード化するための1セットの規則を提案します。 お勧めのencodingsのすべてが明白であり、正常化問題がかかわらないので、少しの非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.
本書では指定されたものなどの逃避機制は、キャラクタが1つ以上の方法で代理をされるのを許容できます。 または、ソフトウェアが逃げられたフォームを解釈して、あるところでは、aがそのセキュリティチェック、およびどんな必要なチェックも危険にさらす、例えば、最小量、正規形はして、悪事が指すということです。
8. Acknowledgments
8. 承認
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 Applications Areaと仕事の一部としたメール国際化と国際化ドメイン名最新版についての一連の議論に対応して製作されました。 それは多くの議論の統合、どれが感謝してそうかで承認された関係者のコメントです。 それらの中の代替のプレゼンテーションと選択のリストを構成することにおける、マーク・デイビスの助けは特に重要でした。
Klensin Best Current Practice [Page 9] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[9ページ]RFC5137ユニコードは2008年2月に逃げられます。
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.
ティムBray、ピーター・コンスタブル、ステファーヌBortzmeyer、クリス・ニューマン、フランクEllermann、クライヴD.W.Feather、フィリップ・グンサー、ビョルンHoehrmann、サイモンJosefsson、ビル・マッキラン、der Mouse、フィル・ペノック、およびジュリアンReschkeはこのドキュメントに先行した様々な概要版で熟読、いくつかの修正、および提案を提供しました。 一緒に取って、彼らの提案はバージョン-00とバージョン-01の間のこのドキュメントとその推薦とその後のバージョンにおけるさらなる改良の重要な改正を動機づけました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[Unicode] The Unicode Consortium, "The Unicode Standard,
Version 5.0", 2006.
(Addison-Wesley, 2006. ISBN 0-321-48091-0).
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン5インチ、2006。」 (アディソン-ウエスリー、2006ISBN0-321-48091-0。)
9.2. Informative References
9.2. 有益な参照
[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 Institut(以前アメリカ合衆国規格研究所)、「米国情報交換用符号。」(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。
Klensin Best Current Practice [Page 10] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[10ページ]RFC5137ユニコードは2008年2月に逃げられます。
[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/本/jls/第3_版/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ドキュメンテーション、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方針」、BCP18、RFC2277、1998年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]コステロ、A.、「Punycode:」 「Applications(IDNA)のInternationalized Domain Namesのためにユニコードをコード化するBootstring」、RFC3492、2003年3月。
[UnicodeGlossary] The Unicode Consortium, "Glossary of Unicode
Terms", June 2007,
<http://www.unicode.org/glossary>.
[UnicodeGlossary] ユニコード共同体、「ユニコード用語の用語集」、2007年6月、<http://www.unicode.org/用語集>。
[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.、「WWW1インチ、W3C推薦、2005年2月、<http://www.w3.org/TR/charmod/>のキャラクターモデル。」
Klensin Best Current Practice [Page 11] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[11ページ]RFC5137ユニコードは2008年2月に逃げられます。
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」。 encodingsが抽象化であると考えられる、。 特定の八重奏の名称ではなく、関連キャラクタ。
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
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 245 1457 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 1457年の617 245メール: john-ietf@jck.com
Klensin Best Current Practice [Page 12] RFC 5137 Unicode Escapes February 2008
Klensinの最も良い現在の習慣[12ページ]RFC5137ユニコードは2008年2月に逃げられます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Klensin Best Current Practice [Page 13]
Klensinの最も良い現在の習慣[13ページ]
一覧
スポンサーリンク
