この文書はRFC 5137の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                         J. Klensin
Request for Comments: 5137                                 February 2008
BCP: 137
Category: Best Current Practice


                  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.
   この文書はインターネット界のために現在のインターネットの最良実践を
   指定して、そして改良のために論議と提案を求めます。この文書の配布は
   無制限です。

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.
   プロトコルに関連して、直接表現や伝送できない文字キャラクタをコード
   化するために、エスケープ機構が必要である多くの事情があります。AS
   CIIコード化で、伝統的なエスケープは、さまざまな異なった方法で書
   かれている文字の10進数か16進数の値のどちらかです。ユニコードへ
   移行すると、文字は2オクテット以上であり、いくつかの異なる形式でコー
   ド化されるかもしれないので、エスケープの問題を複雑にしました。この
   文書は、現在使用中や、新しいIETFプロトコルで使うための選択を議
   論中のいくつかのオプションと、現在国際化されているプロトコルについ
   て議論します。


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.  区切り付きバックスラッシュU
     5.2.  XML and HTML
     5.2.  XMLとHTML
   6.  Forms that Are Normally Not Recommended
   6.  一般的には推奨されない形式
     6.1.  The C Programming Language: Backslash-U
     6.1.  Cプログラミング言語:バックスラッシュU
     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
   付録A. 推薦しない形式の正式な構文

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]コード化の伝統的な
   エスケープは、文字による10進数か16進数値のどちらかで、さまざま
   な異なった方法で書かれています。例えば、状況によって、私たちは、
   10進数形式の%dNNや%NNや、16進数形式の%NNや%xNNやX'nn'や%X'NN'
   を見ました。近年は、"%NN"が制限なしに16進値を表すために人気があり
   ます、恐らくURLで使われ、その普及の結果です。8進数形式が使用され
   ていアプリケーションもあり、一般的ではありませんが、MIMEの
   Quoted-Printable形式とEncoded-word形式はエスケープの違う考えかもし
   れません。ASCIIのかなり簡単な場合と、ISO8859ファミリの
   ような、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] [ISO10646]では、エスケープの問題はさらに複雑になります。
   ユニコードは文字をコードポイントと表現します:16進数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オクテット(または16ビット単位が1つか2つ)のUTF-16

   o  in UTF-32 with exactly four octets (or one 32-bit unit)
   o  ちょうど4オクテット(32ビット単位が1個)の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]よると、人間が使うためにテキストを
   運ぶ必要がある新しいプロトコルはユニコード文字全部がテキストで表せる
   ように設計されるべきです(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.
   この文書は、国際化にされる既存のプロトコル、およびエスケープ機構を
   必要とするプロトコルが、ここで説明していない他の問題が重大でなければ、
   2章で説明する状況により適切なコードポイントのに変形を使用するべき
   (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.
   この推薦は既にネイティブの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.
   この文書はユニコード文字列処理やその他の状況の一般的な推薦はしませ
   ん。エスケープしようとする文字列は、他の文書で定義される「有効で妥
   当」に従って有効で妥当であると仮定します。ユニコード文字列の一般的
   な処理に関する推薦は個々のプロトコルの特定の規則とだけでなく、ユニ
   コード標準自身とW3C文字モデル[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:
   ユニコード文字をエスケープする大きく2つの方法があります。1つは何
   らかの表現にコード・ポイントを使用するもの(次章を見てください)、も
   う一方は何らかの表現に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  IETFプロトコルが成功した1つの理由は、それらが通信に、解読
      するのにコンピュータ・プログラム(またはアルゴリズムの手作業での
      実行)を必要とするコード化より、人間が読めるテキストを使用するた
      めです。これは、表示形式はユニコード文字表で参照されであろうこ
      とを示唆し、それが簡単に可能であるべき事を示唆します。

   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の性質により、人間が10進数か16進数のUTF-8オクテットを、
      ユニコード表で見るために、ユニコードポイントに翻訳するのに、1手
      順か2手順必要です、いくつかの場合、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)
   のポイント参照をコード化する時に同等ですが、上位プレーンを参照するサ
   ロゲートを扱うのに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.
   プロトコルや環境でどんな決定をするかにかかわらず、ユニコードコード・
   ポイントを示すテキストでの、ユニコード文字のエスケープの際に、ユニコー
   ド標準を指定するのにU+NNNN[N[N]]構文を使用するべきです、ここで
   NNNN...は16進数です。実際にユニコード文字を含むテキストが自動処理
   により適した構文を使用するべきです(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.
   コードポイントエスケープには多くの選択肢があります。いくつかは以下へ
   まとめられます。すべてが内容と意味論で同等です--違いは構文です。特定
   のプロトコルや他のアプリケーションの構文の最も良い選択はアプリケーショ
   ン次第です:1つの形式が他のものよりその環境で単純に「よりよい」かもし
   れません。しかしながら、16進値が他の代替手段より望ましいのは明確で
   す:10進数や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つの特定の構文を推薦しないので、エスケープを使用するプロ
   トコル仕様は、エスケープシーケンスが文字通り使用されることを許可する
   ためのエスケープも含め、それらが使用する構文を定義しなければなりませ
   ん(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  同様、または、関連するプロトコルが既に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言語の4か8桁構文
      [ISO-C] (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オクテットをコー
      ド化する場合と同様の問題を生じます。インターネットプロトコルは
      サロゲートペアを使用しないべきです(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.
   よく使用され、一般的に使用され、与えられたプロトコルにおける使用
   に合理的と考えられるかもしれないいくつかの形式が、以下で説明され、
   可能な場合は、現在使用されている状況が示されます。この章の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"で始まる形式の1つで(例えば、下記のの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.
      ; 小文字の"\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.  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)。しかしながら、この形式はHT
   MLと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.
   文字"&"自身は、このスタイルでは"&"と表現されます。

6.  Forms that Are Normally Not Recommended
6.  一般的には推奨されない形式

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プログラムんぐ言語[ISO-C]で利用されます。

   There are disadvantages of this form that may be significant.  First,
   the use of a case variation (between "u" for the four-digit form and
   "U" for the eight-digit form) may not seem natural in environments
   where uppercase and lowercase characters are generally considered
   equivalent and might be confusing to people who are not very familiar
   with Latin-based alphabets (although those people might have even
   more trouble reading relevant English text and explanations).
   Second, as discussed in Section 4, the very fact that there are
   several different conventions that start in \u or \U may become a
   source of confusion as people make incorrect assumptions about what
   they are looking at.
   この形式は重大な欠陥があります。第一に、大文字と小文字が一般的に同
   じと考えららるので、大文字と小文字の区別した使用(4桁形式では"u"、
   8桁形式では"U")は不自然で、ラテン系のアルファベットに詳しくない人々
   を混乱させるかもしれません(それらの人々は関連する英文と説明を読むこ
   とに、さらに苦労するかもしれません)。第二に、4章で議論するように、
   人々が不正確に物を見ると仮定をするとき、\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...}形式を使用します。この形式の利点は、明白な区切り記
   号があるということ、可変長文字列や、面0とより一般的形式の区別の目的
   での大文字小文字の変換機構の問題を解決します。他のあるプログラミング
   言語は、16進数文字列でX'NNNN...'を支持し、多分ユニコード文字列で
   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
   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文字あるいは短い文字列がどう解釈されるかにはあいまい
   さがあります、すなわち、\x(00)から\x(FF)の範囲のオクテットは、ユニコー
   ドコード・ポイントではなく、ローカル文字集合の文字と解釈されるかもし
   れないことに注意してください。この見かけのあいまいさとIETF文書が
   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エスケープ記法が面0以外(すな
   わち、U+FFFFより上)の文字をサロゲートペアを使ってのみ表現できる事
   に注意してください、これは上で議論したUTF-8オクテットの使用と同じ
   問題のいくつかを発生させます。面0の文字において、Java形式は6.1章
   で説明した面0だけの形式と区別ができません。このため、この使用が自
   然である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.
   この文書はIETFアプリケーションエリアと電子メール国際化の仕事の
   一部と国際化ドメイン名最新版についての一連の議論に対応して製作され
   ました。これは強く評価された関係者の多くの議論とコメントの統合です。
   代替表記と選択のリストを構成することにおける、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がこの文書より前の様々な作業ドラフトで注意
   深い読みといくつかの訂正と提案を提供しました。同時に、彼らの提案は
   この文書の重要な改訂版とその推薦の00版と01版と次の版の改良の動
   機を与えました。

   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
付録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],

   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).
   著作権(C)IETF信託(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.
   この文書は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は何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   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に情報を伝えてください。

Japanese translation by Ishida So