[要約] RFC 5198は、ネットワーク間のデータ交換のためのUnicode形式についての規格です。その目的は、異なるシステム間でのテキストデータの正確な交換を可能にすることです。
Network Working Group J. Klensin
Request for Comments: 5198 M. Padlipsky
Obsoletes: 698 March 2008
Updates: 854
Category: Standards Track
Unicode Format for Network Interchange
ネットワークインターチェンジ用のユニコード形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences.
今日のインターネットは、国際化された「テキスト」情報を送信するための標準化されたフォームが必要であり、ARPANETの初期の時代からのASCIIの使用の仕様と並行しています。このドキュメントは、その形式を指定し、正規化と特定のライン終了シーケンスを備えたUTF-8を使用します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement for a Standardized Text Stream Format . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Net-Unicode Definition . . . . . . . . . . . . . . . . . . . . 3
3. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Versions of Unicode . . . . . . . . . . . . . . . . . . . . . 5
5. Applicability and Stability of this Specification . . . . . . 7
5.1. Use in IETF Applications Specifications . . . . . . . . . 7
5.2. Unicode Versions and Applicability . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. History and Context . . . . . . . . . . . . . . . . . 11
Appendix B. The ASCII NVT Definition . . . . . . . . . . . . . . 12
Appendix C. The Line-Ending Problem . . . . . . . . . . . . . . . 14
Appendix D. A Note about Related Future Work . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . . . 16
Historically, Internet protocols have been largely ASCII-based and references to "text" in protocols have assumed ASCII text and specifically text in Network Virtual Terminal ("NVT") or "Network ASCII" form (see Appendix A and Appendix B). Protocols and formats that have moved beyond ASCII have included arrangements to specifically identify the character set and often the language being used.
歴史的に、インターネットプロトコルは主にASCIIベースであり、プロトコルの「テキスト」への言及は、ASCIIテキストと特にネットワーク仮想端末（「NVT」）または「ネットワークASCII」フォームのテキストを想定しています（付録Aおよび付録Bを参照）。ASCIIを超えて移動したプロトコルとフォーマットには、文字セットと多くの場合使用される言語を具体的に識別するためのアレンジが含まれています。
In our more internationalized world, "text" clearly no longer equates unambiguously to "network ASCII". Fortunately, however, we are converging on Unicode [Unicode] [ISO10646] as a single international interchange character coding and no longer need to deal with per-script standards for character sets (e.g., one standard for each of Arabic, Cyrillic, Devanagari, etc., or even standards keyed to languages that are usually considered to share a script, such as French, German, or Swedish). Unfortunately, though, while it is certainly time to define a Unicode-based text type for use as a common text interchange format, "use Unicode" involves even more ambiguity than "use ASCII" did decades ago.
私たちのより国際化された世界では、「テキスト」は明らかに「ネットワークASCII」と明確に同等ではありません。しかし、幸いなことに、私たちは単一の国際的なインターチェンジ文字コーディングとしてUnicode [Unicode] [ISO10646]に収束しており、キャラクターセットのスクリプトごとの標準を処理する必要はなくなりました（たとえば、アラビア語、キリリック、デヴァナガリ、それぞれの標準の1つの標準を扱う必要がなくなりました。など、または通常、フランス語、ドイツ語、スウェーデン語などのスクリプトを共有すると考えられる言語に鍵をかけられている基準。残念ながら、一般的なテキストインターチェンジ形式として使用するためのユニコードベースのテキストタイプを定義する時間ですが、「Unicodeを使用する」には、数十年前に行った「ASCIIを使用する」よりもさらに曖昧さが含まれます。
Unicode identifies each character by an integer, called its "code point", in the range 0-0x10ffff. These integers can be encoded into byte sequences for transmission in at least three standard and generally-recognized encoding forms, all of which are completely defined in The Unicode Standard and the documents cited below:
Unicodeは、0-0x10ffffの範囲の「コードポイント」と呼ばれる整数によって各文字を識別します。これらの整数は、少なくとも3つの標準で一般的に認識されているエンコードフォームで伝送のためにバイトシーケンスにエンコードできます。これらはすべて、Unicode標準と以下に引用されているドキュメントで完全に定義されています。
o UTF-8 [RFC3629] defines a variable-length encoding that may be applied uniformly to all code points.
o UTF-8 [RFC3629]は、すべてのコードポイントに均一に適用できる可変長エンコードを定義します。
o UTF-16 [RFC2781] encodes the range of Unicode characters whose code points are less than 65536 straightforwardly as 16-bit integers, and provides a "surrogate" mechanism for encoding larger code points in 32 bits.
o UTF-16 [RFC2781]は、コードポイントが65536未満の16ビット整数として65536未満のユニコード文字の範囲をエンコードし、32ビットで大きなコードポイントをエンコードするための「サロゲート」メカニズムを提供します。
o UTF-32 (also known as UCS-4) simply encodes each code point as a 32-bit integer.
o UTF-32（UCS-4とも呼ばれます）は、各コードポイントを32ビット整数として単純にエンコードします。
Older forms and nomenclature, such as the 16-bit UCS-2, are now strongly discouraged.
16ビットUCS-2などの古い形態と命名法は、現在強く落胆しています。
As with ASCII, any of these forms may be used with different line-ending conventions. That flexibility can be an additional source of confusion with, e.g., index (offset) references into documents based on character counts.
ASCIIと同様に、これらのフォームのいずれかは、さまざまなライン終了規則で使用される場合があります。その柔軟性は、文字カウントに基づいたドキュメントへのインデックス（オフセット）参照を伴う追加の混乱の原因となる可能性があります。
This document proposes to establish "Net-Unicode" as a new standardized text transmission form for the Internet, to serve as an internationalized alternative for NVT ASCII when specified in new -- and, where appropriate, updated -- protocols. UTF-8 [RFC3629] is chosen for the coding because it has good compatibility properties with ASCII and for other reasons discussed in the existing IETF character set policy [RFC2277]. "Net-Unicode" is specified in Section 2; the subsequent sections of the document provide background and explanation.
このドキュメントは、「ネットユニコード」をインターネットの新しい標準化されたテキスト送信フォームとして確立することを提案し、NVT ASCIIの国際化された代替手段として機能し、必要に応じて更新されたプロトコルで指定された場合に役立ちます。UTF-8 [RFC3629]は、ASCIIとの良好な互換性プロパティや既存のIETF文字セットポリシー[RFC2277]で説明されている他の理由でコーディングに選択されます。「Net-Unicode」はセクション2で指定されています。ドキュメントの後続のセクションは、背景と説明を提供します。
Whenever there is a choice, Unicode SHOULD be used with the text encoding specified here. This combination is preferred to the double-byte encoding of "extended ASCII" [RFC0698] or the assorted per-language or per-country character coding systems.
選択がある場合は、ここで指定されているテキストエンコードでUnicodeを使用する必要があります。この組み合わせは、「拡張ASCII」[RFC0698]の二重バイトエンコーディングまたは言語ごとまたは国ごとの文字コーディングシステムのエンコードよりも好まれます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The Network Unicode format (Net-Unicode) is defined as follows. Parts of this definition are deliberately informal, providing guidance for specific profiles or rules in the protocols that reference this one rather than firm rules that apply globally.
ネットワークユニコード形式（Net-Unicode）は次のように定義されます。この定義の一部は意図的に非公式であり、グローバルに適用されるしっかりしたルールではなく、これを参照するプロトコル内の特定のプロファイルまたはルールのガイダンスを提供します。
1. Characters MUST be encoded in UTF-8 as defined in [RFC3629].
1. [RFC3629]で定義されているように、文字はUTF-8でエンコードする必要があります。
2. If the protocol has the concept of "lines", line-endings MUST be indicated by the sequence Carriage-Return (CR, U+000D) followed by Line-Feed (LF, U+000A), often known just as CRLF. CR SHOULD NOT appear except when followed by LF. The only other allowed context in which CR is permitted is in the combination CR NUL, which is not recommended (see the note at the end of this section).
2. プロトコルに「ライン」の概念がある場合、ラインエンドは、しばしばCRLFとして知られていることがよくあるシーケンスキャリッジリターン（CR、U 000D）に続いて、ラインフィード（LF、U 000A）で示さなければなりません。LFが続く場合を除き、CRは表示されません。CRが許可されている他の唯一の許可されたコンテキストは、CR NULの組み合わせですが、これは推奨されません（このセクションの最後のメモを参照）。
3. The control characters in the ASCII range (U+0000 to U+001F and U+007F to U+009F) SHOULD generally be avoided. Space (SP, U+0020), CR, LF, and Form Feed (FF, U+000C) are exceptions to this principle, but use of all but the first requires care as discussed elsewhere in this document. The so-called "C1 Controls" (U+0080 through U+009F), which did not appear in ASCII, MUST NOT appear.
3. ASCII範囲の制御文字（U 0000〜U 001FおよびU 007FからU 009F）は、一般的に避ける必要があります。スペース（SP、U 0020）、CR、LF、およびフォームフィード（FF、U 000C）はこの原則の例外ですが、最初を除くすべての使用には、このドキュメントの他の場所で説明するようにケアが必要です。いわゆる「C1コントロール」（U 0080からU 009F）は、ASCIIには表示されませんでしたが、表示されてはなりません。
FF should be used only with caution: it does not have a standard and universal interpretation and, in particular, if its use assumes a page length, such assumptions may not be appropriate in international contexts (e.g., considering 8.5x11 inch paper versus A4). Other control characters are used to affect display format, control devices, or to structure files. None of those uses is appropriate for streams of plain text.
FFは注意してのみ使用する必要があります。標準的で普遍的な解釈はありません。特に、その使用がページの長さを想定している場合、そのような仮定は国際的な文脈では適切ではないかもしれません（たとえば、8.5x11インチの論文とA4を考慮して）。他の制御文字は、表示形式、制御デバイス、またはファイルを構成するために使用されます。これらの使用のいずれも、プレーンテキストのストリームに適していません。
4. Before transmission, all character sequences SHOULD be normalized according to Unicode normalization form "NFC" (see Section 3).
4. 伝送の前に、すべての文字シーケンスは、ユニコード正規化フォーム「NFC」に従って正規化する必要があります（セクション3を参照）。
5. As suggested in Section 6 of RFC 3629, the Byte Order Mark ("BOM") signature MUST NOT appear at the beginning of these text strings.
5. RFC 3629のセクション6で示唆されているように、これらのテキスト文字列の先頭にバイトオーダーマーク（ "BOM"）署名が表示されてはなりません。
6. Systems conforming to this specification MUST NOT transmit any string containing any code point that is unassigned in the version of Unicode on which they are dependent. The version of NFC and the version of Unicode used by that system MUST be consistent.
6. この仕様に準拠したシステムは、依存しているUnicodeのバージョンで割り当てられていないコードポイントを含む文字列を送信してはなりません。NFCのバージョンとそのシステムで使用されるUnicodeのバージョンは一貫している必要があります。
The use of LF without CR is questionable; see Appendix B for more discussion. The newer control characters IND (U+0084) and NEL ("Next Line", U+0085) might have been used to disambiguate the various line-ending situations, but, because their use has not been established on the Internet, because many protocols require CRLF, and because IND and NEL fall within the "C1 Controls" group (see below), they MUST NOT be used. Similar observations apply to the yet newer line and paragraph separators at U+2028 and U+2029 and any future characters that might be defined to serve these functions. For this specification and protocols that depend on it, lines end in CRLF and only in CRLF. Anything that does not end in CRLF is either not a line or is severely malformed.
CRのないLFの使用には疑わしい。詳細については、付録Bを参照してください。新しいコントロール文字Ind（U 0084）とNEL（ "Next Line"、U 0085）は、さまざまなライン終了の状況を乱用するために使用されている可能性がありますが、多くのプロトコルには使用がインターネット上で確立されていないため、多くのプロトコルが必要とするためCRLF、およびIndとNelは「C1 Controls」グループ内に分類されるため（以下を参照）、使用してはなりません。同様の観察結果は、U 2028およびU 2029のまだ新しいラインと段落セパレーター、およびこれらの機能を提供するために定義される可能性のある将来のキャラクターに適用されます。それに依存するこの仕様とプロトコルの場合、線はCRLFおよびCRLFでのみ終了します。CRLFで終わらないものはすべて、ラインではないか、ひどく奇形です。
The NVT specification contained a number of additional provisions, e.g., for the optional use of backspacing and "bare CR" (sent as CR NUL) to generate overstruck character sequences. The much greater number of precomposed characters in Unicode, the availability of combining characters, and the growing use of markup conventions of various types to show, e.g., emphasis (rather than attempting to do that via the use of special characters), should make such sequences largely unnecessary. These sequences SHOULD be avoided if at all possible. However, because they were optional in NVT applications and this specification is an NVT superset, they cannot be prohibited entirely. The most important of these rules is that CR MUST NOT appear unless it is immediately followed by LF (indicating end of line) or NUL. Because NUL (an octet whose value is all zeros, i.e., %x00 in the notation of [RFC5234]) is hostile to programming languages that use that character as a string delimiter, the CR NUL sequence SHOULD be avoided for that reason as well.
NVT仕様には、たとえば、バックスペースと「裸のCR」（Cr Nulとして送信）をオプションの使用して、過負荷の文字シーケンスを生成するための多くの追加の規定が含まれていました。Unicodeのはるかに多くの先入観のある文字、キャラクターの組み合わせの可用性、およびさまざまなタイプのマークアップ規則の使用が増えていることは、例えば（特殊文字の使用を介してそれを行おうとするのではなく）、そのようなものにする必要がありますシーケンスはほとんど不要です。これらのシーケンスは、可能な限り避ける必要があります。ただし、NVTアプリケーションではオプションであり、この仕様はNVTスーパーセットであるため、完全に禁止することはできません。これらのルールの中で最も重要なのは、すぐにLF（行の終わりを示す）またはNULが続いていない限り、CRが表示されないことです。Nul（価値がすべてゼロ、つまり[RFC5234]の表記の％x00）は、そのキャラクターを文字列デリミッターとして使用する言語をプログラミングすることに敵対的であるため、その理由でcr nulシーケンスも回避する必要があります。
There are cases where strings of Unicode are fundamentally equivalent, essentially representing the same text. These are called "canonical equivalents" in the Unicode Standard. For example, the following pairs of strings are canonically equivalent:
ユニコードの文字列が基本的に同等であり、本質的に同じテキストを表す場合があります。これらは、Unicode標準の「正規同等物」と呼ばれます。たとえば、次の文字列のペアは標準的に同等です。
U+2126 OHM SIGN U+03A9 GREEK CAPITAL LETTER OMEGA
u 2126オームサインu 03a9ギリシャのキャピタルレターオメガ
U+0061 LATIN SMALL LETTER A, U+0300 COMBINING GRAVE ACCENT U+00E0 LATIN SMALL LETTER A WITH GRAVE
u 0061ラテン語の小文字a、u 0300墓アクセントu 00e0ラテン小文字aと墓aを組み合わせて
Comparison of strings becomes much easier if any such cases are always represented by a single unique form. The Unicode Consortium specifies a normalization form, known as NFC [NFC], which provides the necessary mappings and mechanisms to convert all canonically equivalent sequences to a single unique form. Typically, this form produces precomposed characters for any sequences that can be represented in that fashion. It also reorders other combining marks so that they have a unique and unambiguous order.
そのようなケースが常に単一の一意のフォームで表される場合、文字列の比較ははるかに簡単になります。Unicodeコンソーシアムは、NFC [NFC]として知られる正規化フォームを指定します。これは、すべての標準的に同等のシーケンスを単一の一意のフォームに変換するために必要なマッピングとメカニズムを提供します。通常、このフォームは、その方法で表現できる任意のシーケンスに対して不定期の文字を生成します。また、他の組み合わせマークを再配置して、ユニークで明確な順序を持つようにします。
Of the various normalization forms defined as part of Unicode, NFC is closest to actual use in practice, minimizes side-effects due to considering characters equivalent that may not be equivalent in all situations, and typically requires the least work when converting from non-Unicode encodings.
Unicodeの一部として定義されたさまざまな正規化形式のうち、NFCは実際の実際の使用に最も近く、すべての状況で同等ではない可能性のあるキャラクターを考慮して副作用を最小限に抑え、通常非Unicodeから変換する場合に最小の作業を必要とする場合は、通常エンコーディング。
The section above requires that, except in very unusual circumstances, all Net-Unicode strings be transmitted in normalized form. Recognition of the fact that some implementations of applications may rely on operating system libraries over which they have little control and adherence to the robustness principle suggests that receivers of such strings should be prepared to receive unnormalized ones and to not react to that in excessive ways.
上記のセクションでは、非常に異常な状況を除き、すべてのネットユニコード文字列を正規化された形式で送信する必要があります。アプリケーションのいくつかの実装が、制御がほとんどないオペレーティングシステムライブラリに依存している可能性があるという事実の認識は、そのような文字列の受信者が非正規化されたものを受け取り、それに過度の方法で反応しないように準備する必要があることを示唆しています。
Unicode changes and expands over time. Large blocks of space are reserved for future expansion. New versions, which appear at regular intervals, add new scripts and characters. Occasionally they also change some property definitions. In retrospect, one of the advantages of ASCII [ASCII] when it was chosen was that the code space was full when the Standard was first published. There was no practical way to add characters or change code point assignments without being obviously incompatible.
Unicodeは変更され、時間の経過とともに拡張されます。将来の拡張のために、大きな空間ブロックが予約されています。定期的に表示される新しいバージョンは、新しいスクリプトと文字を追加します。時折、いくつかのプロパティ定義も変更します。振り返ってみると、ASCII [ASCII]が選択されたときの利点の1つは、標準が最初に公開されたときにコードスペースがいっぱいだったということでした。明らかに互換性がないことなく、文字を追加したり、コードポイントの割り当てを変更する実用的な方法はありませんでした。
While there are some security issues if people deliberately try to trick the system (see Section 6), Unicode version changes should not have a significant impact on the text stream specification of this document for the following reasons:
人々が故意にシステムをだまそうとする場合（セクション6を参照）、いくつかのセキュリティの問題がありますが、Unicodeバージョンの変更は、次の理由でこのドキュメントのテキストストリーム仕様に大きな影響を与えるべきではありません。
o The transformation between Unicode code table positions and the corresponding UTF-8 code is algorithmic; it does not depend on whether a code point has been assigned or not.
o
o The normalization recommended here, NFC (see Section 3), performs a very limited set of mappings, much more limited than those of the more extensive NFKC used in, e.g., Nameprep [RFC3491].
o ここで推奨される正規化、NFC（セクション3を参照）は、非常に限られたマッピングセットを実行します。これは、NAMEPREP [RFC3491]で使用されるより広範なNFKCのマッピングよりもはるかに限られたセットよりもはるかに限られています。
The NFC tables may be updated over time as new characters are added, but the Unicode Consortium has guaranteed the stability of all NFC strings. That is, if a string does not contain any unassigned characters, and it is normalized according to NFC, it will always be normalized according to all future versions of the Unicode Standard. The stability of the Net-Unicode format is thus guaranteed when any implementation that converts text into Net-Unicode format does not permit unassigned characters.
NFCテーブルは、新しい文字が追加されると時間の経過とともに更新される場合がありますが、UnicodeコンソーシアムはすべてのNFC文字列の安定性を保証しています。つまり、文字列に未割り当て文字が含まれておらず、NFCに従って正規化されている場合、Unicode標準のすべての将来のバージョンに従って常に正規化されます。したがって、ネットユニコード形式の安定性は、テキストをネットユニコード形式に変換する実装が割り当てられていない文字を許可しない場合に保証されます。
Because Unicode code points that are reserved for private use do not have standard definitions or normalization interpretations, they SHOULD be avoided in strings intended for Internet interchange.
プライベート使用のために予約されているユニコードコードポイントには、標準の定義や正規化解釈がないため、インターネットインターチェンジを目的とした文字列では避ける必要があります。
Were Unicode to be changed in a way that violated these assumptions, i.e., that either invalidated the byte string order specified in RFC 3629 or that changed the stability of NFC as stated above, this specification would not apply. Put differently, this specification applies only to versions of Unicode starting with version 5.0 and extending to, but not including, any version for which changes are made in either the UTF-8 definition or to NFC stability. Such changes would violate established Unicode policies and are hence unlikely, but, should they occur, it would be necessary to evaluate them for compatibility with this specification and other Internet uses of NFC.
If the specification of a protocol references this one, strings that are received by that protocol and that appear to be UTF-8 and are not otherwise identified (e.g., by charset labeling) SHOULD be treated as using UTF-8 in conformance with this specification.
プロトコルの仕様がこれを参照する場合、そのプロトコルによって受信され、UTF-8のように見える文字列は、そうでなければ識別されない（例えば、charsetラベル付けによって）、この仕様に準拠してUTF-8を使用して扱う必要があります。。
During the development of this specification, there was some confusion about where it would be useful given that, e.g., the individual MIME media types used in email and with HTTP have their own rules about UTF-8 character types and normalization, and the application transport protocols impose their own conventions about line endings. There are three answers. The first is that, in retrospect, it would have been better to have those protocols and content types standardized in the way specified here, even though it is certainly too late to change them at this time. The second is that we have several protocols that are dependent on either the original Telnet design or other arrangements requiring a standard, interoperable, string definition without specific content-labels of one sort or another. Whois [RFC3912] is an example member of this group. As consideration is given to upgrading them for non-ASCII use, this specification provides a normative reference that provides the same stability that NVT has provided the ASCII forms. This specification is intended for use by other specifications that have not yet defined how to use Unicode. Having a preferred standard Internet definition for Unicode text streams -- rather than just one for transmission codings -- may help improve the specification and interoperability of protocols to be developed in the future. This specification is not intended for use with specifications that already allow the use of UTF-8 and precisely define that use.
この仕様の開発中に、たとえば、電子メールやHTTPで使用されている個々のMIMEメディアタイプが、UTF-8の文字タイプと正規化、およびアプリケーショントランスポートに関する独自のルールがあることを考えると、どこで有用なのかについて、いくつかの混乱がありました。プロトコルは、ラインエンディングについて独自の慣習を課します。3つの答えがあります。1つ目は、振り返ってみると、現時点で変更するには手遅れであるにもかかわらず、これらのプロトコルとコンテンツタイプをここで指定された方法で標準化する方が良いでしょう。2つ目は、ある種の特定のコンテンツラベルなしに標準の相互運用可能な文字列定義を必要とする、元のTelnet設計またはその他の配置のいずれかに依存するいくつかのプロトコルがあることです。WHOIS [RFC3912]は、このグループの例メンバーです。ASCII以外の使用のためにそれらをアップグレードすることを考慮して、この仕様は、NVTがASCIIフォームを提供したのと同じ安定性を提供する規範的な参照を提供します。この仕様は、Unicodeの使用方法をまだ定義していない他の仕様が使用することを目的としています。単コードテキストストリームの優先標準的なインターネット定義を持つことは、送信コーディング用の1つではなく、将来開発されるプロトコルの仕様と相互運用性を改善するのに役立ちます。この仕様は、UTF-8を既に使用し、その使用を正確に定義する仕様で使用することを目的としていません。
The IETF faces a practical dilemma with regard to versions of Unicode. Each new version brings with it new characters and sometimes new combining characters. Version 5.0 introduces the new concept of sequences of characters named as if they were individual characters (see [NamedSequences]). The normalization represented by NFC is stable if all strings are transmitted and stored in normalized form if corrections are never made to character definitions or normalization tables and if unassigned code points are never used. The latter is important because an unassigned code point always normalizes to itself. However, if the same code point is assigned to a character in a future version, it may participate in some other normalization mapping (some specific difficulties in this regard are discussed in [RFC4690]). It is worth noting that transmission in normalized form is not required by either the IETF's UTF-8 Standard [RFC3629] or by standards dependent on the current version of Stringprep [RFC3454].
All would be well with this as described in Section 4 except for one problem: Applications typically do not perform their own conversions to Unicode and may not perform their own normalizations but instead rely on operating system or language library functions -- functions that may be upgraded or otherwise changed without changes to the application code itself. Consequently, there may be no plausible way for an application to know which version of Unicode, or which version of the normalization procedures, it is utilizing, nor is there any way by which it can guarantee that the two will be consistent.
1つの問題を除いてセクション4で説明されているようにこれはすべてうまくいきます。アプリケーションは通常、ユニコードへの独自の変換を実行せず、独自の正常化を実行することはできませんが、オペレーティングシステムまたは言語ライブラリの機能に依存する可能性があります - アップグレードできる機能または、アプリケーションコード自体に変更せずに変更されます。したがって、アプリケーションがどのバージョンのUnicode、またはどのバージョンの正規化手順を知ることができない場合も、それが利用されていることも、2つが一貫していることを保証する方法もありません。
Because of per-version changes in definitions and tables, Stringprep and documents depending on it are now tied to Unicode Version 3.2 [Unicode32] and full interoperability of Internet Standard UTF-8 [RFC3629], when used with normalization as specified here, is dependent on normalization definitions and the definition of UTF-8 itself not changing after Unicode Version 5.0. These assumptions seem fairly safe, but they are still assumptions. Rather than being linked to the latest available version of Unicode, version 5.0 [Unicode] or broader concepts of version independence based on specific assumptions and conditions, this specification could reasonably have been tied, like Stringprep and Nameprep to Unicode 3.2 [Unicode32] or some more recent intermediate version, but, in addition to the obvious disadvantages of having different IETF standards tied to different versions of Unicode, the library-based application implementation behavior described above makes these version linkages nearly meaningless in practice.
定義と表のバージョンごとの変化のため、それに依存する文字列とドキュメントは、現在、ここで指定された正規化とともに使用する場合、インターネット標準UTF-8 [RFC3629]のユニコードバージョン3.2 [Unicode32]と完全な相互運用性に関連付けられています。正規化定義とUTF-8自体の定義は、Unicodeバージョン5.0の後に変更されません。これらの仮定はかなり安全に思えますが、それでも依然として仮定です。Unicodeの最新バージョン、バージョン5.0 [Unicode]、または特定の仮定と条件に基づいてバージョンの独立性のより広範な概念にリンクするのではなく、この仕様は、StringPrepやnameprep to Unicode 3.2 [unicode32]または一部のように合理的に結ばれている可能性があります。より最近の中間バージョンですが、異なるバージョンのUnicodeに関連する異なるIETF標準を持っていることの明らかな欠点に加えて、上記のライブラリベースのアプリケーションの実装動作により、これらのバージョンのリンケージは実際にはほとんど意味がありません。
In theory, one can get around this problem in four ways:
理論的には、4つの方法でこの問題を回避できます。
1. Freeze on a particular version of Unicode and try to insist that applications enforce that version by, e.g., containing lists of unassigned characters and prohibiting their use. Of course, this would prohibit evolution to include newly-added scripts and the tables of unassigned code points would be cumbersome.
1. Unicodeの特定のバージョンをフリーズし、アプリケーションが、たとえば、割り当てられていない文字のリストを含み、その使用を禁止することによってそのバージョンを強制することを主張しようとします。もちろん、これは新しく添付されたスクリプトを含めるように進化を禁止し、割り当てられていないコードポイントのテーブルは面倒です。
2. Require that every Unicode "text" string or file start with a version indication, somewhat akin to the "byte order mark" indicator. It is unlikely that this provision would be practical. More important, it would require that each application implementation be prepared to either support multiple normalization tables and versions or that it reject text from Unicode versions with which it was not prepared to deal.
2.
3. Devise a different set of normalization rules that would, e.g., guarantee that no character assigned to a previously-unassigned code point in Unicode was ever normalized to anything but itself and use those rules instead of NFC. It is not clear whether or not such a set of rules is possible or whether some other completely stable set of rules could be devised, perhaps in combination with restrictions on the ways in which characters were added in future versions of Unicode.
3. たとえば、Unicodeの以前に認定されていないコードポイントに割り当てられた文字がそれ自体以外のものに正規化され、NFCの代わりにそれらのルールを使用しないことを保証する異なる一連の正規化ルールを考案します。そのような一連のルールが可能かどうか、または他の完全に安定したルールのセットを考案できるかどうかは、おそらくUnicodeの将来のバージョンでキャラクターが追加された方法の制限と組み合わせて考案できるかどうかは明らかではありません。
4. Devise a normalization process that is otherwise equivalent to NFC but that rejects code points that are unassigned in the current version of Unicode, rather than mapping those code points to themselves. This would still leave some risk of incompatible corrections in Unicode and possibly a few edge cases, but it is probably stable enough for Internet use in the overwhelming number of cases. This process has been discussed in the Unicode Consortium under the name "Stable NFC".
4. NFCに相当するが、これらのコードポイントを自分自身にマッピングするのではなく、現在のUnicodeで割り当てられていないコードポイントを拒否する正規化プロセスを考案します。これにより、Unicodeおよびおそらくいくつかのエッジケースで互換性のない補正のリスクが残りますが、圧倒的な数のケースではインターネット使用に十分に安定している可能性があります。このプロセスは、「安定したNFC」という名前でUnicodeコンソーシアムで議論されています。
None of these approaches seems ideal: the ideal procedure would be as stable and predictable as ASCII has been. But that level is simply not feasible as long as Unicode continues to evolve by the addition of new code points and scripts. The fourth option listed above appears to be a reasonable compromise.
これらのアプローチはどれも理想的ではありません。理想的な手順は、ASCIIと同じくらい安定して予測可能です。しかし、Unicodeが新しいコードポイントとスクリプトの追加によって進化し続ける限り、そのレベルは単に実行不可能です。上記の4番目のオプションは、合理的な妥協のようです。
This specification provides a standard form for the use of Unicode as "network text". Most of the same security issues that apply to UTF-8, as discussed in [RFC3629], apply to it, although it should be slightly less subject to some risks by virtue of requiring NFC normalization and generally being somewhat more restrictive. However, shifts in Unicode versions, as discussed in Section 5.2, may introduce other security issues.
この仕様は、「ネットワークテキスト」としてUnicodeを使用するための標準フォームを提供します。[RFC3629]で説明されているように、UTF-8に適用される同じセキュリティの問題のほとんどが適用されますが、NFCの正常化を必要とし、一般的にやや制限的であるためにリスクの対象となるはずです。ただし、セクション5.2で説明したように、Unicodeバージョンのシフトは、他のセキュリティの問題を導入する可能性があります。
Programs that receive these streams should use extreme caution about assuming that incoming data are normalized, since it might be possible to use unnormalized forms, as well as invalid UTF-8, as part of an attack. In particular, firewalls and other systems that interpret UTF-8 streams should be developed with the clear knowledge that an attacker may deliberately send unnormalized text, for instance, to avoid detection by naive text-matching systems.
これらのストリームを受け取るプログラムは、攻撃の一部として非正規化されたフォームと無効なUTF-8を使用することが可能である可能性があるため、着信データが正規化されていると仮定することに関して非常に注意を払う必要があります。特に、UTF-8ストリームを解釈するファイアウォールや他のシステムは、攻撃者が素朴なテキスト一致システムによる検出を避けるために、攻撃者が意図的に非正規化テキストを送信する可能性があるという明確な知識を持って開発する必要があります。
NVT contains a requirement, of necessity repeated here (see Section 2), that the CR character be immediately followed by either LF or ASCII NUL (an octet with all bits zero). NUL may be problematic for some programming languages that use it as a string terminator, and hence a trap for the unwary, unless caution is used. This may be an additional reason to avoid the use of CR entirely, except in sequence with LF, as suggested above.
NVTには、ここで繰り返される必要性（セクション2を参照）を含む要件が含まれています。CR文字の後にLFまたはASCIIヌル（すべてのビットゼロを持つオクテット）が続くということです。NULは、文字列ターミネーターとして使用するいくつかのプログラミング言語では問題がある可能性があり、したがって、注意が使用されない限り、不注意な人のためのトラップです。これは、上記のように、LFとの順序でCRの使用を完全に回避する追加の理由である可能性があります。
The discussion about Unicode versions above (see Section 4 and Section 5.2) makes several assumptions about future versions of Unicode, about NFC normalization being applied properly, and about UTF-8 being processed and transmitted exactly as specified in RFC 3629. If any of those assumptions are not correct, then there are cases in which strings that would be considered equivalent do not compare equal. Robust code should be prepared for those possibilities.
上記のUnicodeバージョンに関する議論（セクション4およびセクション5.2を参照）は、Unicodeの将来のバージョン、NFCの正規化が適切に適用されていること、UTF-8がRFC 3629で指定されたとおりに処理および送信されることについてのいくつかの仮定を行います。仮定は正しくありません、そして、同等と見なされる文字列が等しく比較されない場合があります。これらの可能性のために堅牢なコードを準備する必要があります。
Many thanks to Mark Davis, Martin Duerst, and Michel Suignard for suggestions about Unicode normalization that led to the format described here, and especially to Mark for providing the paragraphs that describe the role of NFC. Thanks also to Mark, Doug Ewell, Asmus Freytag for corrected text describing Unicode transmission forms, and to Tim Bray, Carsten Bormann, Stephane Bortzmeyer, Martin Duerst, Frank Ellermann, Clive D.W. Feather, Ted Hardie, Bjoern Hoehrmann, Alfred Hoenes, Kent Karlsson, Bill McQuillan, George Michaelson, Chris Newman, and Marcos Sanz for a number of helpful comments and clarification requests.
Mark Davis、Martin Duerst、およびMichel Suignardは、ここで説明されている形式につながったUnicodeの正規化についての提案に感謝します。また、Unicodeトランスミッションフォームを説明する修正されたテキストのMark、Doug Ewell、Asmus Freytag、およびTim Bray、Carsten Bormann、Stephane Bortzmeyer、Martin Duerst、Frank Ellermann、Clive D.W.フェザー、テッド・ハーディー、Bjoern Hoehrmann、Alfred Hoenes、Kent Karlsson、Bill McQuillan、George Michaelson、Chris Newman、Marcos Sanzの多くの有益なコメントと明確化のリクエスト。
This subsection contains a review of prior work in the ARPANET and Internet to establish a standard text type, work that establishes the context and motivation for the approach taken in this document. The text is explanatory rather than normative: nothing in this section is intended to change or update any current specification. Those who are uninterested in this review and analysis can safely skip this section.
このサブセクションには、標準的なテキストタイプ、このドキュメントで取得したアプローチのコンテキストと動機を確立する作業を確立するためのArpanetおよびインターネットでの以前の作業のレビューが含まれています。テキストは規範ではなく説明的です。このセクションでは、現在の仕様を変更または更新することは何もありません。このレビューと分析に興味がない人は、このセクションを安全にスキップできます。
One of the earlier application design decisions made in the development of ARPANET, a decision that was carried forward into the Internet, was the decision to standardize on a single and very specific coding for "text" to be passed across the network [RFC0020]. Hosts on the network were then responsible for translating or mapping from whatever character coding conventions were used locally to that common intermediate representation, with sending hosts mapping to it and receiving ones mapping from it to their local forms as needed. It is interesting to note that at the time the ARPANET was being developed, participating host operating systems used at least three different character coding standards: the antiquated BCD (Binary Coded Decimal), the then-dominant major manufacturer-backed EBCDIC (Extended BCD Interchange Code), and the then-still emerging ASCII (American Standard Code for Information Interchange). Since the ARPANET was an "open" project and EBCDIC was intimately linked to a particular hardware vendor, the original Network Working Group agreed that its standard should be ASCII. That ASCII form was precisely "7-bit ASCII in an 8-bit field", which was in effect a compromise between hosts that were natively 7-bit oriented (e.g., with five seven-bit characters in a 36-bit word), those that were 8-bit oriented (using eight-bit characters) and those that placed the seven-bit ASCII characters in 9-bit fields with two leading zero bits (four characters in a 36-bit word).
Arpanetの開発において行われた以前のアプリケーション設計の決定の1つは、インターネットに進められた決定であり、ネットワーク全体に渡される「テキスト」の単一かつ非常に具体的なコーディングを標準化する決定でした[RFC0020]。ネットワーク上のホストは、その一般的な中間表現にローカルに使用された文字コーディングコンベンションからの翻訳またはマッピングを担当し、必要に応じてホストマッピングを送信し、そこからローカルフォームへのマッピングを受信しました。ARPANETが開発されている時点で、参加ホストオペレーティングシステムは少なくとも3つの異なる文字コーディング標準を使用していたことに注意してください：時代遅れのBCD（バイナリコーディング10進数）、当時の主要メーカー支援EBCDIC（拡張BCDインターチェンジ（拡張されたBCDインターチェンジ）コード）、および当時の新興ASCII（情報交換のためのアメリカの標準コード）。Arpanetは「オープン」プロジェクトであり、EBCDICは特定のハードウェアベンダーに密接にリンクされていたため、元のネットワークワーキンググループは、その基準がASCIIであることに同意しました。そのASCIIフォームは、まさに「8ビットフィールドで7ビットASCII」であり、実際には、ネイティブに7ビット指向のホスト間の妥協点でした（たとえば、36ビット語で5つの7ビット文字があります）。8ビット指向（8ビット文字を使用）であったものと、2つの主要なゼロビット（36ビットワードで4文字）を持つ9ビットフィールドに7ビットASCII文字を配置したもの。
More standardization was suggested in the first preliminary description of the Telnet protocol [RFC0097]. With the iterations of that protocol [RFC0137] [RFC0139] and the drawing together of an essentially formal definition somewhat later [RFC0318], a standard abstraction, the Network Virtual Terminal (NVT) was established. NVT character-coding conventions (initially called "Telnet ASCII" and later called "NVT ASCII", or, more casually, "network ASCII") included the requirement that Carriage Return followed by Line Feed (CRLF) be the common representation for ending lines of text (given that some participating "Host" operating systems used the one natively, some the other, at least one used both, and a few used neither (preferring variable-length lines with counts or special delimiters or markers instead) and specified conventions for some other characters. Also, since NVT ASCII was restricted to seven-bit characters, use of the high-order bit in octets was reserved for the transmission of control signaling information.
Telnetプロトコル[RFC0097]の最初の予備記述では、より標準化が提案されました。そのプロトコル[RFC0137] [RFC0139]の反復と、標準的な抽象化である標準的な抽象化であるネットワーク仮想端子（NVT）が確立された、本質的に正式な定義[RFC0318]の描画が確立されました。NVTキャラクターコーディングコンベンション（最初は「Telnet ascii」と呼ばれ、後に「NVT ASCII」と呼ばれる、またはよりさりげなく「ネットワークASCII」と呼ばれる）には、キャリッジリターンに続いてラインフィード（CRLF）が終了ラインの共通の表現であるという要件が含まれていました。テキスト（一部の参加「ホスト」オペレーティングシステムはネイティブに使用し、もう1つは少なくとも1つは両方を使用し、いくつかはどちらも使用しませんでした（代わりにカウントまたは特別なデリミターまたはマーカーを使用して可変長線を好む）および指定された規則また、他のいくつかのキャラクターの場合。また、NVT ASCIIは7ビット文字に制限されていたため、オクテットでの高次ビットの使用は、制御シグナリング情報の送信のために予約されていました。
At a very high level, the concept was that a system could use whatever character coding and line representations were appropriate locally, but text transmitted over the network as text must conform to the single "network virtual terminal" convention. Virtually all early Internet protocols that presume transfer of "text" assume this virtual terminal model, although different ones assume or limit it in different ways. Telnet, the command stream and ASCII Type in FTP [RFC0542], the message stream in SMTP transfer [RFC2821], and the strings passed to finger [RFC0742] and whois [RFC0954] are the classic examples. More recently, HTTP [RFC1945] [RFC2616] follows the same general model but permits 8-bit data and leaves the line end sequence unspecified (the latter has been the source of a significant number of problems).
非常に高いレベルであるコンセプトは、システムが文字コーディングとライン表現がローカルで適切であるものを使用できることでしたが、テキストが単一の「ネットワーク仮想端末」条約に準拠する必要があるため、ネットワークを介して送信されるテキストでした。「テキスト」の転送を推定する事実上すべての初期のインターネットプロトコルは、この仮想端末モデルを想定していますが、異なる方法で異なる方法で想定または制限しています。Telnet、FTP [RFC0542]のコマンドストリーム、およびASCIIタイプ、SMTP転送のメッセージストリーム[RFC2821]、および指に渡された文字列は、whois [rfc0954]に渡されます。最近では、HTTP [RFC1945] [RFC2616]は同じ一般モデルに従いますが、8ビットデータを許可し、ラインエンドシーケンスを不特定のままにします（後者はかなりの数の問題の原因となっています）。
The main body of this specification is intended as an update to, and internationalized version of, the Net-ASCII definition. The specification is self-contained in that parts of the Net-ASCII definition that are no longer recommended are not included above. Because Net-ASCII evolved somewhat over time and there has been debate about which specification is the "official" Net-ASCII, it is appropriate to review the key elements of that definition here. This review is informal with regard to the contents of Net-ASCII and should not be considered as a normative update or summary of the earlier specifications (Section 2 does specify some normative updates to those specifications and some comments below are consistent with it).
この仕様の本体は、ネットASCII定義の更新および国際化バージョンとして意図されています。仕様は、もはや推奨されていないネットASCII定義の部分では、上記に含まれていません。Net-Asciiは時間とともに多少進化し、どの仕様が「公式」Net-Asciiであるかについて議論があるため、ここでその定義の重要な要素をレビューすることが適切です。このレビューは、Net-ASCIIの内容に関して非公式であり、以前の仕様の規範的な更新または要約と見なされるべきではありません（セクション2はそれらの仕様のいくつかの規範的更新を指定し、以下のコメントはそれと一致しています）。
The first part of the section titled "THE NVT PRINTER AND KEYBOARD" in RFC 854 [RFC0854] is generally, although not universally, considered to be the normative definition of the (ASCII) Network Virtual Terminal and hence of Net-ASCII. It includes not only the graphic ASCII characters but a number of control characters. The latter are given Internet-specific meanings that are often more specific than the definitions in the ASCII specification. In today's usage, and for the present specification, the following clarifications and updates to that list should be noted. Each one is accompanied by a brief explanation of the reason why the original specification is no longer appropriate.
RFC 854 [RFC0854]の「NVTプリンターとキーボード」というタイトルのセクションの最初の部分は、一般的ではありませんが、（ASCII）ネットワーク仮想端子の規範的定義であり、したがってNet-ASCIIの規範的定義であると考えられています。グラフィックASCII文字だけでなく、多くのコントロール文字が含まれます。後者には、ASCII仕様の定義よりも具体的なインターネット固有の意味が与えられています。今日の使用法と現在の仕様では、そのリストの次の明確化と更新に注意する必要があります。それぞれには、元の仕様がもはや適切でない理由の簡単な説明が伴います。
1. The "defined but not required" codes -- BEL (U+0007), BS (U+0008), HT (U+0009), VT (U+000B), and FF (U+000C) -- and the undefined control codes ("C0") SHOULD NOT be used unless required by exceptional circumstances. Either their original "network printer" definitions are no longer in general use, common practice has evolved away from the formats specified there, or their use to simulate characters that are better handled by Unicode is no longer appropriate. While the appearance of some of these characters on the list may seem surprising, BS now has an ambiguous interpretation in practice (erasing in some systems but not in others), the width associated with HT varies with the environment, and VT and FF do not have a uniform effect with regard to either vertical positioning or the associated horizontal position result. Of course, telnet escapes are not considered part of the data stream and hence are unaffected by this provision.
1. 「定義されているが必須ではない」コード - BEL（U 0007）、BS（U 0008）、HT（U 0009）、VT（U 000B）、およびFF（U 000C） - および未定義の制御コード（ "C0"）例外的な状況で要求されない限り、使用しないでください。元の「ネットワークプリンター」の定義が一般的に使用されなくなった場合、一般的な実践は、そこで指定された形式から離れて進化しました。また、Unicodeによってより適切に処理される文字をシミュレートするための使用はもはや適切ではありません。リストにこれらのキャラクターの一部の外観は驚くべきように思えるかもしれませんが、BSは現在、実際には曖昧な解釈を持っています（一部のシステムでは消去されますが、他のシステムでは消去されません）、HTに関連する幅は環境によって異なり、VTとFFは環境とは異なります垂直方向の位置または関連する水平位置の結果に関して、均一な効果があります。もちろん、Telnetの脱出はデータストリームの一部とは見なされないため、この規定の影響を受けません。
2. In Net-ASCII, CR MUST NOT appear except when immediately followed by either NUL or LF, with the latter (CR LF) designating the "new line" function. Today and as specified above, CR should generally appear only when followed by LF. Because page layout is better done in other ways, because NUL has a special interpretation in some programming languages, and to avoid other types of confusion, CR NUL should preferably be avoided as specified above.
2. Net-Asciiでは、すぐにNULまたはLFが続く場合を除き、CRが表示されてはなりません。後者（CR LF）は「新しいライン」関数を指定します。今日および上記で指定されているように、CRは通常、LFが続く場合にのみ表示されるはずです。Nulはいくつかのプログラミング言語で特別な解釈があり、他の種類の混乱を避けるために、ページレイアウトは他の方法でより良い行為を行うため、上記のようにCr nulはできれば避ける必要があります。
3. LF CR SHOULD NOT appear except as a side-effect of multiple CR LF sequences (e.g., CR LF CR LF).
3. LF CRは、複数のCr LFシーケンス（Cr LF Cr LFなど）の副作用を除いて表示されません。
4. The historical NVT documents do not call out either "bare LF" (LF without CR) or HT for special treatment. Both have generally been understood to be problematic. In the case of LF, there is a difference in interpretation as to whether its semantics imply "go to same position on the next line" or "go to the first position on the next line" and interoperability considerations suggest not depending on which interpretation the receiver applies. At the same time, misinterpretation of LF is less harmful than misinterpretation of "bare" CR: in the CR case, text may be erased or made completely unreadable; in the LF one, the worst consequence is a very funny-looking display. Obviously, HT is problematic because there is no standard way to transmit intended tab position or width information in running text. Again, the harm is unlikely to be great if HT is simply interpreted as one or more spaces, but, in general, it cannot be relied upon to format information.
4. 歴史的なNVT文書は、特別な治療のために「むき出しのLF」（LF）またはHTのいずれかを呼び出しません。どちらも一般的に問題があると理解されています。LFの場合、そのセマンティクスが「次の行で同じ位置に移動する」または「次の行の最初の位置に行く」と相互運用性の考慮事項が、どの解釈がどの解釈に依存しないかを示唆するかどうかについて、解釈に違いがあります。受信機が適用されます。同時に、LFの誤解は、「裸」CRの誤解よりも有害ではありません。CRケースでは、テキストが消去または完全に読めない場合があります。LFでは、最悪の結果は非常に面白いディスプレイです。明らかに、HTは、実行中のテキストで意図したタブの位置または幅情報を送信する標準的な方法がないため、問題があります。繰り返しになりますが、HTが単に1つ以上のスペースとして解釈される場合、害が大きくなることはほとんどありませんが、一般的に、情報のフォーマットに依存することはできません。
It is worth noting that the telnet IAC character (an octet consisting of all ones, i.e., %xFF) itself is not a problem for UTF-8 since that particular octet cannot appear in a valid UTF-8 string. However, while few of them have been used, telnet permits other command-introducer characters whose bit sequences in an octet may be part of valid UTF-8 characters. While it causes no ambiguity in UTF-8, Unicode assigns a graphic character ("Latin Small Letter Y with Diaeresis") to U+00FF (octets C3 B0 in UTF-8). Some caution is clearly in order in this area.
Telnet IACのキャラクター（すべてのものからなるオクテット、つまり％XFF）自体がUTF-8の問題ではないことは注目に値します。ただし、それらの使用はほとんど使用されていませんが、Telnetは、Octetのビットシーケンスが有効なUTF-8文字の一部である可能性のある他のコマンドイントロデューサー文字を許可します。UTF-8に曖昧さはありませんが、Unicodeはグラフィック文字（「ダイアエレシスを伴うラテン小文字Y」）をU 00FF（UTF-8のオクテットC3 B0）に割り当てます。この分野では、ある程度の注意が整っています。
The definition of how a line ending should be denoted in plain text strings on the wire for the Internet has been controversial from even before the introduction of NVT. Some have argued that recipients should be required to interpret almost anything that a sender might intend as a line ending as actually a line ending. Others have pointed out that this would lead to some ambiguities of interpretation and presentation and would violate the principle that we should minimize the number of forms that are permitted on the wire in order to promote interoperability and eliminate the "every recipient needs to understand every sender format" problem. The design of this specification, like that of NVT, takes the latter approach. Its designers believe that there is little point in a standard if it is to specify "anyone can do whatever they like and the receiver just needs to cope".
インターネットのワイヤー上の単純なテキスト文字列で行の終わりをどのように示すべきかの定義は、NVTの導入前でさえ議論の余地があります。受信者は、送信者が実際にラインエンディングとして終了するラインとして意図する可能性のあるほとんどすべてのものを解釈する必要があると主張している人もいます。他の人たちは、これが解釈とプレゼンテーションの曖昧さにつながり、相互運用性を促進し、「すべての受信者がすべての送信者を理解する必要がある」を排除するためにワイヤで許可されているフォームの数を最小限に抑えるべきであるという原則に違反することを指摘しています。フォーマット「問題。NVTのように、この仕様の設計は後者のアプローチを取ります。そのデザイナーは、「誰でも好きなことができること、レシーバーがただ対処する必要がある」を指定することである場合、標準にはほとんど意味がないと考えています。
A further discussion of the nature and evolution of the line-ending problem appears in Section 5.8 of the Unicode Standard [Unicode] and is suggested for additional reading. If we were starting with the Internet today, it would probably be sensible to follow the recommendation there and use LS (U+2028) exclusively, in preference to CRLF. However, the installed base of use of CRLF and the importance of forward compatibility with NVT and protocols that assume it makes that impossible, so it is necessary to continue using CRLF as the "New Line Function" ("NLF", see the terminology section in that reference).
ライン終了問題の性質と進化のさらなる議論は、Unicode標準[Unicode]のセクション5.8に表示され、追加の読み取りのために提案されています。今日インターネットから始めていた場合、CRLFを好むために、そこでの推奨に従い、LS（U 2028）のみを使用することはおそらく賢明でしょう。ただし、CRLFの使用のベースと、それを不可能にすると仮定するNVTおよびプロトコルとのフォワード互換性の重要性は、CRLFを「新しいライン関数」（「NLF」として使用し続ける必要があります。用語セクションを参照してください。その参照で）。
Consideration should be given to a Telnet (or SSH [RFC4251]) option to specify this type of stream and an FTP extension [RFC0959] to permit a new "Unicode text" data TYPE.
このタイプのストリームとFTP拡張[RFC0959]を指定して、新しい「ユニコードテキスト」データタイプを許可するTelnet（またはSSH [RFC4251]）オプションを考慮する必要があります。
References
参考文献
Normative References
引用文献
[ISO10646] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO/ IEC 10646-1:2000, October 2000.
[ISO10646]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - パート1：アーキテクチャと基本的な多言面」、ISO/ IEC 10646-1：2000、2000年10月。
[NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", October 2006, <http://www.unicode.org/reports/tr15/>.
[NFC] Davis、M。and M. Duerst、「Unicode Standard Annex＃15：Unicode Normalization Forms」、2006年10月、<http://www.unicode.org/reports/tr15/>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007.
Boston, MA, USA: Addison-Wesley. ISBN 0-321-48091-0
米国マサチューセッツ州ボストン：Addison-Wesley。ISBN 0-321-48091-0
[Unicode32] The Unicode Consortium, "The Unicode Standard, Version 3.0", 2000.
[Unicode32] Unicode Consortium、「Unicode Standard、バージョン3.0」、2000。
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5). Version 3.2 consists of the definition in that book as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
（Reading、Ma、Addison-Wesley、2000。ISBN0-201- 61633-5）。バージョン3.2は、Unicode Standard Annex＃27：Unicode 3.1（http://www.unicode.org/reports/tr27/）およびUnicode Standard Annex＃28：Unicode 3.2（http（http）によって修正されたその本の定義で構成されています。：//www.unicode.org/reports/tr28/）。
Informative References
参考引用
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII] American National Standards Institute（以前の米国標準研究所）、「米国情報交換のコード」、ANSI X3.4-1968、1968。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. ISO 646 International Reverence Version (IRV) [ISO.646.1991] is usually considered equivalent to ASCII.
ANSI X3.4-1968は、わずかな変更で新しいバージョンに置き換えられましたが、1968年のバージョンはインターネットにとって決定的なままです。ISO 646 International Reverenceバージョン（IRV）[ISO.646.1991]は通常、ASCIIに相当すると考えられています。
[ISO.646.1991] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991.
[ISO.646.1991]国際標準化機関、「情報技術 - 情報交換用のISO 7ビットコード化された文字セット」、ISO Standard 646、1991。
[NamedSequences] The Unicode Consortium, "NamedSequences-4.1.0.txt", 2005, <http://www.unicode.org/Public/UNIDATA/ NamedSequences.txt>.
[名前を付けた順番] Unicodeコンソーシアム、「Angement-4.1.0.txt」、2005、<http://www.unicode.org/public/unidata/ namedsevences.txt>。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020] Cerf、V。、「ネットワークインターチェンジ用ASCII形式」、RFC 20、1969年10月。
[RFC0097] Melvin, J. and R. Watson, "First Cut at a Proposed Telnet Protocol", RFC 97, February 1971.
[RFC0097] Melvin、J。およびR. Watson、「提案されたTelnetプロトコルで最初にカット」、RFC 97、1971年2月。
[RFC0137] O'Sullivan, T., "Telnet Protocol - a proposed document", RFC 137, April 1971.
[RFC0137] O'Sullivan、T。、「Telnet Protocol -A Propoded Document」、RFC 137、1971年4月。
[RFC0139] O'Sullivan, T., "Discussion of Telnet Protocol", RFC 139, May 1971.
[RFC0139] O'Sullivan、T。、「Telnet Protocolの議論」、RFC 139、1971年5月。
[RFC0318] Postel, J., "Telnet Protocols", RFC 318, April 1972.
[RFC0318] Postel、J。、「Telnet Protocols」、RFC 318、1972年4月。
[RFC0542] Neigus, N., "File Transfer Protocol", RFC 542, August 1973.
[RFC0542] Neigus、N。、「ファイル転送プロトコル」、RFC 542、1973年8月。
[RFC0698] Mock, T., "Telnet extended ASCII option", RFC 698, July 1975.
[RFC0698] Mock、T。、「Telnet拡張ASCIIオプション」、RFC 698、1975年7月。
[RFC0742] Harrenstien, K., "NAME/FINGER Protocol", RFC 742, December 1977.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[RFC0954] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[RFC0954] Harrenstien、K.、Stahl、M。、およびE. Feinler、「Nicname/Whois」、RFC 954、1985年10月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945] Berners-Lee、T.、Fielding、R。、およびH. Nielsen、「HyperText Transfer Protocol-HTTP/1.0」、RFC 1945、1996年5月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491] Hoffman、P。およびM. Blanchet、「NamePrep：Internationalized Domain Name（IDN）のStringPrepプロファイル」、RFC 3491、2003年3月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690] Klensin、J.、Faltstrom、P.、Karp、C。、およびIAB、「国際化されたドメイン名（IDN）のレビューと推奨事項」、RFC 4690、2006年9月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Michael A. Padlipsky 8011 Stewart Ave. Los Angeles, CA 90045 USA
Michael A. Padlipsky 8011 Stewart Ave. Los Angeles、CA 90045 USA
Phone: +1 310-670-4288
EMail: the.map@alum.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。