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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

EditTextのソフトキーボードの『完了』を虫メガネアイコンなどに変更する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る