この文書はRFC 5137の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット界のために現在のインターネットの最良実践を
指定して、そして改良のために論議と提案を求めます。この文書の配布は
無制限です。
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.
プロトコルに関連して、直接表現や伝送できない文字キャラクタをコード
化するために、エスケープ機構が必要である多くの事情があります。ＡＳ
ＣＩＩコード化で、伝統的なエスケープは、さまざまな異なった方法で書
かれている文字の１０進数か１６進数の値のどちらかです。ユニコードへ
移行すると、文字は２オクテット以上であり、いくつかの異なる形式でコー
ド化されるかもしれないので、エスケープの問題を複雑にしました。この
文書は、現在使用中や、新しいＩＥＴＦプロトコルで使うための選択を議
論中のいくつかのオプションと、現在国際化されているプロトコルについ
て議論します。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Context and Background
1.1. 状況と背景
1.2. Terminology
1.2. 用語
1.3. Discussion List
1.3. 議論リスト
2. Encodings that Represent Unicode Code Points: Code Position versus UTF-8 or UTF-16 Octets
2. 代理ユニコードコードポイントのコード化：コードポイント対UTF-8やUTF-16オクテット
3. Referring to Unicode Characters
3. ユニコード文字を参照します。
4. Syntax for Code Point Escapes
4. コード・ポイントエスケープ構文
5. Recommended Presentation Variants for Unicode Code Point Escapes
5. ユニコードコード・ポイントエスケープのお勧めの表現形式
5.1. Backslash-U with Delimiters
5.1. 区切り付きバックスラッシュＵ
5.2. XML and HTML
5.2. ＸＭＬとＨＴＭＬ
6. Forms that Are Normally Not Recommended
6. 一般的には推奨されない形式
6.1. The C Programming Language: Backslash-U
6.1. Cプログラミング言語:バックスラッシュＵ
6.2. Perl: A Hexadecimal String
6.2. Perl: 16進文字列
6.3. Java: Escaped UTF-16
6.3. Java: UTF-16エスケープ
7. Security Considerations
7. セキュリティの考察
8. Acknowledgments
8. 謝辞
Appendix A. Formal Syntax for Forms Not Recommended
付録Ａ． 推薦しない形式の正式な構文
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]コード化の伝統的な
エスケープは、文字による１０進数か１６進数値のどちらかで、さまざま
な異なった方法で書かれています。例えば、状況によって、私たちは、
１０進数形式の%dNNや%NNや、１６進数形式の%NNや%xNNやX'nn'や%X'NN'
を見ました。近年は、"%NN"が制限なしに１６進値を表すために人気があり
ます、恐らくURLで使われ、その普及の結果です。８進数形式が使用され
ていアプリケーションもあり、一般的ではありませんが、ＭＩＭＥの
Quoted-Printable形式とEncoded-word形式はエスケープの違う考えかもし
れません。ＡＳＣＩＩのかなり簡単な場合と、ＩＳＯ８８５９ファミリの
ような、ＡＳＣＩＩの拡張の規格でも、私たちはいくつかの異なったエス
ケープ形式を受け入れていて、それぞれが何らかの歴史的な結果です。
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]では、エスケープの問題はさらに複雑になります。
ユニコードは文字をコードポイントと表現します：１６進数０から
１０ＦＦＦＦの範囲の数値です。文書上でコード・ポイントを示すとき、
これらはいわゆる「U+」記法を使用し、U+0000からU+10FFFFまでの値とし
て表されます。オクテット列にされるとき、これらのコード・ポイントは
異なる形式で表すことができます:
o in UTF-8 with one to four octets [RFC3629]
o １から４オクテットのUTF-8[RFC3629]
o in UTF-16 with two or four octets (or one or two seizets -- 16-bit
units)
o ２または４オクテット（または１６ビット単位が１つか２つ）のUTF-16
o in UTF-32 with exactly four octets (or one 32-bit unit)
o ちょうど４オクテット（３２ビット単位が１個）の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+形式
の両方の１６進数表現の大規模な使用を、コードポイントエスケープとして
見ました。
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)。
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)と提案します。
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.
この推薦は既にネイティブのＵＴＦ−８やユニコードの何れかのコード化
を受け入れるプロトコルに適切ではありません。一般に、プロトコルが国
際化されるとき、一般に、エスケープを使用するよりも、それらの形式を
受け入れるのが望ましいです。この推薦は、移行時など、実用的ではない
事例にも適用されます。
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)
にも現れます。この文章の指定するフォーマットと、その理由は、ＵＩ環
境でも適切かもしれませんが、これはＵＩや表示形式を標準化する提案で
はありません。
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-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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は、
[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. 代理ユニコードコードポイントのコード化：コードポイント対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:
ユニコード文字をエスケープする大きく２つの方法があります。１つは何
らかの表現にコード・ポイントを使用するもの(次章を見てください)、も
う一方は何らかの表現にUTF-8コード化のオクテットか他のコード化を使
用するものです。他の選択も可能ですが、実際にはまれです。この仕様は、
別の方法でやむにやまれない理由がない限り、UTF-8(またはUTF-16)オク
テットより、ユニコードコード・ポイントを使用することを勧めます
(SHOULD)。この理由がいくつかあります。
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 ＩＥＴＦプロトコルが成功した１つの理由は、それらが通信に、解読
するのにコンピュータ・プログラム(またはアルゴリズムの手作業での
実行)を必要とするコード化より、人間が読めるテキストを使用するた
めです。これは、表示形式はユニコード文字表で参照されであろうこ
とを示唆し、それが簡単に可能であるべき事を示唆します。
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オクテットを、
ユニコード表で見るために、ユニコードポイントに翻訳するのに、１手
順か２手順必要です、いくつかの場合、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 ユニコードの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コード化オクテット表現に適用されるのと同じ問題は、
"プニコード"プロファイルのあるなしにかかわらず、"ブート文字列"
コード化[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, Plane 0)
のポイント参照をコード化する時に同等ですが、上位プレーンを参照するサ
ロゲートを扱うのに２段階の手順が必要です。
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.
プロトコルや環境でどんな決定をするかにかかわらず、ユニコードコード・
ポイントを示すテキストでの、ユニコード文字のエスケープの際に、ユニコー
ド標準を指定するのにU+NNNN[N[N]]構文を使用するべきです、ここで
NNNN...は１６進数です。実際にユニコード文字を含むテキストが自動処理
により適した構文を使用するべきです(SHOULD)。
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.
コードポイントエスケープには多くの選択肢があります。いくつかは以下へ
まとめられます。すべてが内容と意味論で同等です--違いは構文です。特定
のプロトコルや他のアプリケーションの構文の最も良い選択はアプリケーショ
ン次第です:１つの形式が他のものよりその環境で単純に「よりよい」かもし
れません。しかしながら、１６進値が他の代替手段より望ましいのは明確で
す：１０進数や８進数のオフセットに基づくシステムは使用されるべきでは
ありません(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.
この仕様が１つの特定の構文を推薦しないので、エスケープを使用するプロ
トコル仕様は、エスケープシーケンスが文字通り使用されることを許可する
ためのエスケープも含め、それらが使用する構文を定義しなければなりませ
ん(MUST)。
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.
o ユニコードコードポイントが範囲がU+0000からU+10FFFFです。エスケー
プシステムによって、４桁か５桁か６桁か８桁の１６進数字を使用する
かもしれません。一般に、明らかな構文上のトリックと混乱と誤りの結
果の危険性を避けるために、明白な区切りを使用する形式は他の代替手
段より優先です。多くの文脈で、左右対称の対の区切りは、関係ないも
のより目視で認識しやすくて、分かりやすいです。
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"で始まる形式は、Ｃ言語の４か８桁構文
[ISO-C] (6.1章参照)や、ＪａｖａのUTF-16コード化[Java]
(6.3章参照)や、"\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)。
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.
ユニコードコードポイント位置を表す多くの異なった方法があります。
すべての状況で常に「最良」のは見当たりません。さらに、エスケープ
メカニズム自体にエスケープが必要な場合、それらの最適解はある状況
と別の状況で異なります。
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.
よく使用され、一般的に使用され、与えられたプロトコルにおける使用
に合理的と考えられるかもしれないいくつかの形式が、以下で説明され、
可能な場合は、現在使用されている状況が示されます。この章の２はイ
ンターネットプロトコルにおける使用のために推薦されます。現れる他
の一般的なものは、その欠点の議論と共に、６章に現れます。
5.1. Backslash-U with Delimiters
5.1. 区切り付きバックスラッシュＵ
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.
お勧め形式の１つは"\u"で始まる形式の１つで（例えば、下記のの6.1章
参照）、ほかの場所で議論した理由で明白な区切り文字を使います。
Specifically, in ABNF [RFC5234],
ＡＢＮＦ[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.
; 小文字の"\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.
; 事実上、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. ＸＭＬとＨＴＭＬ
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.
他のお勧め形式はＸＭＬで使用されるものです。これは"&#xNNNN;"形式を
使用します。Ｐｅｒｌ形式(6.2章)のように、この形式は明確な終了記号
があり、あいまいさを減少させます。ＨＴＭＬは同様の形式を使用します
が、いくつかの場合、セミコロンは省略されるかもしれません。もし省略
されると、終了記号の利点がなくなるので、セミコロンなしのＨＴＭＬが
形式は使用しないべきです(SHOULD NOT)。しかしながら、この形式はＨＴ
ＭＬとＸＭＬと類似の状況以外では不快でぶざまとしばしば考えられます。
In 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.
文字"&"自身は、このスタイルでは"&"と表現されます。
6. Forms that Are Normally Not Recommended
6. 一般的には推奨されない形式
6.1. The C Programming Language: Backslash-U
6.1. Cプログラミング言語:バックスラッシュＵ
The forms
形式
\UNNNNNNNN (for any Unicode character) and
\UNNNNNNNN (全てのユニコード文字のため)と
\uNNNN (for Unicode characters in plane 0)
\uNNNN (面０のユニコード文字のため)
are utilized in the C Programming Language [ISO-C] when an ASCII
escape for embedded Unicode characters is needed.
は、埋め込まれたユニコード文字のためのASCIIエスケープが必要な時に、
Ｃプログラムんぐ言語[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.
この形式は重大な欠陥があります。第一に、大文字と小文字が一般的に同
じと考えららるので、大文字と小文字の区別した使用(４桁形式では"u"、
８桁形式では"U")は不自然で、ラテン系のアルファベットに詳しくない人々
を混乱させるかもしれません(それらの人々は関連する英文と説明を読むこ
とに、さらに苦労するかもしれません)。第二に、４章で議論するように、
人々が不正確に物を見ると仮定をするとき、\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...}形式を使用します。この形式の利点は、明白な区切り記
号があるということ、可変長文字列や、面０とより一般的形式の区別の目的
での大文字小文字の変換機構の問題を解決します。他のあるプログラミング
言語は、１６進数文字列でX'NNNN...'を支持し、多分ユニコード文字列で
U'NNNN...'を支持する傾向があるでしょうが、これらの形式がＩＥＴＦで
使用しているようには見えません。
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(00)から\x(FF)の範囲のオクテットは、ユニコー
ドコード・ポイントではなく、ローカル文字集合の文字と解釈されるかもし
れないことに注意してください。この見かけのあいまいさとＩＥＴＦ文書が
pragmaの供給をしないことから(Perlの「コード化」pragmaとその他の詳細
の詳しい情報は[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コーディングと同
様になります。UTF-16形式、つまりJavaエスケープ記法が面０以外(すな
わち、U+FFFFより上)の文字をサロゲートペアを使ってのみ表現できる事
に注意してください、これは上で議論したUTF-8オクテットの使用と同じ
問題のいくつかを発生させます。面０の文字において、Java形式は6.1章
で説明した面０だけの形式と区別ができません。このため、この使用が自
然であるJavaでの使用を除いて、エスケープとして使用すべきではありま
せん(SHOULD NOT)。
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.
この文書は他の条件がない場合にユニコード文字をコード化するための規
則を提案します。全てのお勧めのコード化はあいまいさがなく、正規化問
題に関係しないので、それらがどのようにコード化されても、単純な非
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.
本書では指定されたものエスケープ機構などは、文字が複数の方法で表現
される事を許容します。または、ソフトウェアがエスケープ形式を解釈す
る場合、セキュリティ検査や、最小値や正規形などのその他の検査でリス
クがあります。
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.
この文書はＩＥＴＦアプリケーションエリアと電子メール国際化の仕事の
一部と国際化ドメイン名最新版についての一連の議論に対応して製作され
ました。これは強く評価された関係者の多くの議論とコメントの統合です。
代替表記と選択のリストを構成することにおける、Mark Davisの助けは特
に重要でした。
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.
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とJulian Reschkeがこの文書より前の様々な作業ドラフトで注意
深い読みといくつかの訂正と提案を提供しました。同時に、彼らの提案は
この文書の重要な改訂版とその推薦の００版と０１版と次の版の改良の動
機を与えました。
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とJulian 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[Unicode] The Unicode Consortium, "The Unicode Standard,
Version 5.0", 2006.
(Addison-Wesley, 2006. ISBN 0-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.
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.
[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>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in
Applications (IDNA)", RFC 3492, March 2003.
[UnicodeGlossary] The Unicode Consortium, "Glossary of Unicode
Terms", June 2007,
<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/>.
Appendix A. Formal Syntax for Forms Not Recommended
付録Ａ． 推薦しない形式の正式な構文
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.
上記（６章）で、使用してほしくないため、推薦されないエスケープの構文
を示していませんが、それらを使用すると選択する場合に整合している事を
望むためにこの付録で提供します。これらの書式のいくつかは正式な仕様書
に基づく定義ではないく、他のものもが時間がたつにつれて正確に整合して
いるとは限らない方法で発展するかもしれないと読者へ、警告します。その
結果、これらの定義は一般的ではなく、また正確に情報源の意図通りに解釈
されないかもしれません。
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. Ｃプログラミング言語
Specifically, in 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"
A.2. Perl Form
@@@@A.2. Perl形式
EmbeddedUnicodeChar = %x5C.78 "{" 2*6HEXDIG "}" ; starts with "\x"
A.3. Java Form
@@@@A.3. Java形式
EmbeddedUnicodeChar = %x5C.7A 4HEXDIG ; starts with "\u"
Author's Address
著者のアドレス
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 245 1457
EMail: john-ietf@jck.com
Full Copyright Statement
完全著作権表示
Copyright (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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とＩＥＴＦ信託とインターネット技術標準化タスクフォースは、明確にも暗
黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
の利用に適当である事の保障を含め、全ての保証を拒否します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。