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.
私たちのより多くの国際化の世界では、「text」がはっきりもはや「ネットワークASCII」に明確に相当しません。しかし、幸いなことに、我々は、単一国際交流の文字の符号化としてUnicode [UNICODE] [ISO10646]に収束し、もはや文字セットごとのスクリプト標準規格（例えば、アラビア語、キリル文字ごとに1つの標準に対処する必要があり、デーヴァナーガリーされていますなど、あるいは、フランス語、ドイツ語、またはスウェーデン語など通常のスクリプトを共有するために考えられている言語にキーにも基準）。しかし、残念ながら、確かに一般的なテキスト交換フォーマットとして使用するためのUnicodeベースのテキストタイプを定義するための時間がある一方で、「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に、その「コードポイント」と呼ばれる整数により各文字を識別する。これらの整数は、完全にUnicode標準で定義され、ドキュメントが以下に引用される全ては、少なくとも3つの標準と一般に認識された符号化形式で伝送するためのバイトシーケンスに符号化することができます。
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ビット整数であるUnicode文字の範囲を符号化し、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]で説明した他の理由のための良好な互換性を有しているため符号化のために選択されます。 「ネット-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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
次のようにネットワークユニコードフォーマット（ネットユニコード）が定義されています。この定義の一部は、グローバルに適用会社のルールではなく、この1を参照するプロトコルに特定のプロファイルやルールのためのガイダンスを提供し、故意に非公式です。
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.、行末は、キャリッジリターン（CR、U + 000D）はしばしば単にCRLFとして知られている改行（LF、U + 000A）、続いて配列により示さなければなりません。 CRはLFが続くとき以外は表示されません。 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.（U + 001FおよびU + 009FにU + 007FにU + 0000）ASCIIの範囲内の制御文字は、一般的に避けるべきです。スペース（SP、U + 0020）は、CR、LF、およびフォームフィード（FF、U + 000C）は、この原則の例外はありますが、他の場所で、この文書で説明したように、すべてが、最初の使用には注意が必要です。 ASCIIには表示されませんでした、いわゆる「C1コントロール」（U + 009FによるU + 0080）が、現れてはなりません。
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.
4. Before transmission, all character sequences SHOULD be normalized according to Unicode normalization form "NFC" (see Section 3).
4.送信する前に、すべての文字列は、Unicode正規形「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.
RFC 3629のセクション6で示唆したように5、バイトオーダーマーク（「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.システムは、それらが依存されているユニコードのバージョンに割り当てられていない任意のコードポイントを含む任意の文字列を送信してはいけません。 NFCのバージョンと、そのシステムで使用されるユニコードのバージョンが一致していなければなりません。
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（「次の行」、U + 0085）は、様々な行末の状況を明確にするために使用されているが、可能性がある新しい制御文字INDとNELが「C1コントロール」グループに入るためのプロトコルは、（下記参照）CRLFを必要とし、それらを使用してはいけません。同様の観察は、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 NULとして送信）「裸CR」の任意の使用のために、例えば、追加の規定の数を含んでいました。例えばユニコード、結合文字の可用性における合成済み文字のはるかに大きい数、および表示する様々な種類のマークアップ規則の使用増加、（むしろ特殊文字を使用することによってそれを行うにしようとするよりも）、重点は、そのようにする必要があります大部分は不要な配列を含みます。これらの配列はすべての可能であれば避けるべきです。彼らはNVTアプリケーションではオプションだったし、この仕様はNVTのスーパーセットであるため、しかし、彼らは完全に禁止することはできません。これらのルールの中で最も重要なのは、それがすぐにまたはNUL（行の終わりを示す）LFが続くされない限り、CRが表示されてはならないということです。 （その値がすべてゼロであるオクテット、[RFC5234]の表記、すなわち、％のX00）は、文字列の区切り文字としてその文字を使用するプログラミング言語に敵対的であるNULは、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文字の文字列は、基本的に同等である場合があります。これらは、Unicode標準では「標準的な同等物」と呼ばれています。例えば、文字列の次のペアは、標準的に等価です。
U+2126 OHM SIGN U+03A9 GREEK CAPITAL LETTER OMEGA
U + 2126 OHMのSIGN U + 03A9 GREEK CAPITAL LETTER OMEGA
U+0061 LATIN SMALL LETTER A, U+0300 COMBINING GRAVE ACCENT U+00E0 LATIN SMALL LETTER A WITH GRAVE
GRAVE WITH U + 0061ラテン文字A、U + 0300 COMBINING GRAVEアクセントU + 00E0ラテン小文字の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.
どのような場合は、常に単一のユニークな形で表現されている場合は、文字列の比較は非常に容易になります。ユニコードコンソーシアムは、単一の一意の形式にすべての正準等価な配列に変換するために必要なマッピングとメカニズムを提供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.
ユニコードの一部として定義され、種々の正規化形態の、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]標準が最初に発行されたとき、コードスペースが満杯であったことでした。明らかに互換性がないことなく、文字または変更するコードポイントの割り当てを追加するための実用的な方法はありませんでした。
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:
人が故意にシステムをだまししようとした場合、いくつかのセキュリティ上の問題がある一方で、Unicodeバージョンの変更は、以下の理由により、この文書のテキストストリームの仕様に重大な影響を与えてはならない（第6節参照）。
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.
Unicodeコードテーブルの位置と対応するUTF-8コードの間の変換は、アルゴリズムは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、はるかに限られたより広範NFKCのものよりNFC（セクション3を参照）、マッピングの非常に限られたセットを実行するには、例えば、NAMEPREP [RFC3491]で使用しました。
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テーブルは、新しい文字が追加されると、時間の経過とともに更新されることがありますが、ユニコードコンソーシアムは、すべてのNFC文字列の安定性を保証しています。文字列が割り当てられていない文字が含まれていない場合には、であり、NFCによると、それは常にUnicode標準の将来のすべてのバージョンに応じて正規化されます正規化されています。ネットUnicode形式にテキストを変換任意の実装が割り当てられていない文字を許可しないときのNet-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.
私的使用のために予約されているUnicodeコードポイントは、標準的な定義や正規の解釈を持っていないので、彼らは、インターネット交換のために意図された文字列では避けるべきです。
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.
これらの仮定に違反した方法で変更するUnicodeは、すなわち、いずれかがRFC 3629で指定されたバイト列の順序を無効化または上述のようにそれがNFCの安定性を変更することを、本明細書は適用されないであろうました。言い換えると、本明細書は、変更がいずれかのUTF-8定義またはNFC安定性に作られているいずれかのバージョンをバージョン5.0で始まりまで延びるが、を含むだけでなく、ユニコードのバージョンに適用されます。このような変化は、この仕様とNFCの他のインターネットの使用との互換性のためにそれらを評価することが必要であろう、彼らが発生した場合、Unicodeの方針を確立し、それ故にそうですが、違反することになります。
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であることが表示され、そうでない場合（例えば、文字セットの標識によって）識別されないれるプロトコル参照このいずれか、文字列の仕様は、本明細書に準拠して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つの答えがあります。最初は振り返ってみると、確かに、この時点でそれらを変更するには遅すぎであっても、ここで指定した方法で標準化され、それらのプロトコルとコンテンツタイプを持っている方が良いされているだろう、ということです。二つ目は、我々は、元のTelnet設計または1つの並べ替えまたは別の特定のコンテンツ・ラベルのない標準、相互運用可能、文字列の定義を必要とする他の構成のいずれかに依存しているいくつかのプロトコルを持っているということです。 WHOIS [RFC3912]このグループの例メンバーです。考察は、非ASCIIの使用のためにそれらをアップグレードするに与えられたように、この仕様はNVTがASCII形式を提供した同じ安定性を提供する規範的基準を提供します。この仕様はまだUnicodeを使用する方法を定義していない他の仕様で使用するためのものです。むしろただ一つの伝送コーディングのためのより - - Unicodeテキストストリームのために好ましい標準的なインターネットの定義を持つことは、将来開発されるプロトコルの仕様と相互運用性を向上させることがあります。この仕様は、既に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].
IETFは、Unicodeのバージョンに関して実用的なジレンマに直面しています。それぞれの新しいバージョンでは、それを新しい文字、時には新しい結合文字をもたらします。バージョン5.0は、彼らが個々の文字（[NamedSequences]参照）であるかのように名前の文字列の新しい概念を導入しています。補正が文字定義または正規化テーブルに対して行われることはありません場合に割り当てられていないコードポイントは決して使用されない場合、すべての文字列が送信され、正規化された形式で格納されている場合、NFCで表される正規化が安定しています。未割り当てコードポイントは、常に自分自身に正規化しているため、後者は重要です。同じコードポイントが、将来のバージョンの文字に割り当てられている場合は、それはいくつかの他の正規化マッピングに参加することができる（この点でいくつかの特定の問題は、[RFC4690]に記載されています）。これは、正規化された形式でその送信がIETFのUTF-8標準[RFC3629]のいずれかによって、またはの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.
- アップグレードすることができる機能のアプリケーションは通常、Unicodeに、独自の変換を実行しないと、自分の正規化を行う代わりに、オペレーティングシステムや言語ライブラリ関数に依存しないことがあります。一つの問題を除いて、セクション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.
そのため、文字列準備し、それに応じて、文書が今Unicodeバージョン3.2 [Unicode32]とインターネット標準のUTF-8の完全な相互運用性[RFC3629]に関連付けられている定義とテーブルのあたりのバージョンの変更は、ここで指定された正規化で使用した場合、依存しているの正規化の定義とUTF-8の定義に、それ自体はUnicodeバージョン5.0の後に変化していません。これらの仮定はかなり安全なように見えるが、彼らはまだ仮定しています。むしろ、特定の前提条件に基づいて、バージョン独立のユニコード、バージョン5.0 [UNICODE]または広い概念の利用可能な最新バージョンにリンクされているよりも、この仕様は合理的に[Unicode32]または一部のUnicode 3.2に文字列準備やNAMEPREPのように、縛られている可能性がより最近の中間バージョンは、しかし、ユニコードの異なるバージョンに縛ら異なるIETF標準を持っていることの明白な欠点に加えて、前述したライブラリベースのアプリケーションの実装の振る舞いは、実際にはこれらのバージョンの結合はほぼ無意味になります。
In theory, one can get around this problem in four ways:
理論的には、1は、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.フリーズとは、アプリケーションが割り当てられていない文字のリストを含む、その使用を禁止する、例えば、でそのバージョンを施行することを主張してみてください。もちろん、これは新しく追加されたスクリプトを含めるように進化を禁止すると、未割り当てコードポイントの表には、面倒なことでしょう。
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.すべてのUnicodeの「テキスト」の文字列またはファイルが「バイトオーダーマーク」表示にやや似バージョン表示、で始まることが必要です。この規定は、実用的になることはほとんどありません。さらに重要なこと、それは、各アプリケーションの実装は、複数の正規化テーブルとバージョンをサポートするか、対処する準備ができていないだったとUnicodeのバージョンからテキストを拒否し、そのいずれかに調製されることが必要となります。
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のそれらの規則を使用する正規化ルールの異なるセットを考案。おそらく文字はユニコードの将来のバージョンで追加された方法の制限と組み合わせて、規則のこのようなセットが可能であるか否か、またはルールのいくつかの他の完全に安定したセットを考案することができるかどうかは明らかではありません。
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を使用するための標準的な形式を提供します。それはNFC正規化を必要とし、一般的に多少制限さによって僅かに小さい被写体いくつかのリスクにすべきである[RFC3629]で説明したように、UTF-8に適用されるのと同じセキュリティ上の問題のほとんどは、それに適用されます。しかし、他のセキュリティ問題を導入することができる、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はCR文字が直ちにLFまたはASCII NUL（全ビットがゼロのオクテット）のいずれかに続いていることが、ここでは繰り返さ必要性の要件を、（セクション2を参照）を含みます。注意が使用されない限り、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
上記のUnicodeバージョンに関する議論（第4および第5.2節を参照）が正しく適用されているNFC正規約ユニコードの将来のバージョンに関するいくつかの仮定を行い、約
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.
これらの仮定のいずれかが正しくない場合、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.
NFCの役割を説明する段落を提供するために、ここで説明したフォーマットに、特にマークにつながったUnicode正規化についての提案のためのマーク・デイビス、マーティンDuerst、そしてミシェルSuignardに感謝します。また、Unicodeの伝送フォームを記述修正テキストのマーク、ダグイーウェル、Asmusフライタークに、そしてティム・ブレイ、カルステンボルマン、ステファンBortzmeyer、マーティンDuerst、フランクEllermann、クライヴD.W.のおかげで有益なコメントと明確化要求の数についてフェザー、テッドハーディー、ビョルンHoehrmann、アルフレッドHoenes、ケント・カールソン、ビルMcQuillan氏の説明による、ジョージ・マイケルソン、クリス・ニューマン、そしてマルコスサンス。
Appendix A. History and Context
付録A.歴史とコンテキスト
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の開発で行われた以前のアプリケーション設計上の決定の一つ、インターネットに進めた決定は、ネットワーク経由で渡される「テキスト」[RFC0020]のための単一かつ非常に特定のコードを標準化することを決定しました。ネットワーク上のホストは、それまでのホストマッピングを送信し、必要に応じて、地元のフォームに、そこからのもののマッピングを受信し、その共通の中間表現にローカルで使用して翻訳するか、どんな文字コーディング規則からのマッピングを担当しました。時代遅れのBCD（二進化十進数）、当時の支配的な大手メーカー担保EBCDIC（拡張BCDインターチェンジ：少なくとも3つの異なる文字コーディング標準を使用し、ホスト・オペレーティング・システムに参加、一度にARPANETが開発されていたことは興味深いことですコード）、その後、まだ新興ASCII（情報交換用米国標準コード）。 ARPANETは、「オープン」プロジェクトだったとEBCDICが密接に特定のハードウェア・ベンダーにリンクされていたので、オリジナルのネットワークワーキンググループは、その標準はASCIIでなければならないことで合意しました。そのASCII形式がネイティブ7ビット配向されたホストとの間の妥協が有効であった、正確に「8ビットのフィールドで7ビットASCII」であった（例えば、36ビットワードで5 7ビット文字で）、 （8ビット文字を使用）は、8ビット指向た二つ先行ゼロビット（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]と本質的に正式な定義を一緒に描画多少後で[RFC0318]の反復で、標準的な抽象化は、ネットワーク仮想端末（NVT）が設立されました。 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).
非常に高いレベルでは、コンセプトは、システムは、文字符号化とライン表現がローカルで適切であったものは何でも使うことができますが、テキストなどのネットワークを介して送信テキストは、単一の「ネットワーク仮想端末」の規則に適合しなければならないということでした。事実上、「テキスト」の移転を前提とし、すべての初期のインターネットプロトコルは異なるものが想定するものの、この仮想端末モデルを前提としたり、さまざまな方法でそれを制限します。テルネット、FTP [RFC0542]、SMTP転送[RFC2821]のメッセージストリームにおけるコマンドストリームとASCII型、指[RFC0742]とWHOIS [RFC0954]に渡された文字列は、古典的な例です。より最近では、HTTP [RFC1945]、[RFC2616]は、同じ一般的なモデルに従うが、8ビットのデータを可能にし、不特定のライン終了シーケンス（後者は、問題のかなりの数の源となっている）の葉。
Appendix B. The ASCII NVT Definition
付録B. ASCIIのNVTの定義
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定義の部分は上記に含まれていないことです。ネット-ASCIIが時間をかけてやや進化と仕様が「公式」のNet-ASCIIであるかについての議論があったので、ここではその定義の重要な要素を検討することが適切です。このレビューはネット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）ネットワーク仮想端末の定義、したがってネット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.
ネットASCII 2.、CRは（CR LF）後者の「改行」機能を指定すると、直ちにNULまたは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」（CRなしのLF）またはHTのいずれかを呼び出すことはありません。両方は、一般的に問題であると理解されています。 LFの場合は、そのセマンティクスが「次の行に同じ位置に移動」または「次の行の最初の位置に行く」と相互運用性の考慮事項は、どの解釈に依存しない示唆を暗示かどうかの解釈の違いがあります受信機が適用されます。同時に、LFの誤解は、「裸」のCRの誤解より少ない有害である：CRの場合、テキストは、消去または完全に読めなくてもよいです。 LF 1で、最悪の結果は非常に面白いに見えるディスプレイです。テキストを実行している中で意図したタブ位置や幅の情報を伝送するための標準的な方法がないので、明らかに、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,
その特定のオクテットが有効なUTF-8文字列に表示することができないため、telnetのIAC文字（すべてのものから成るオクテット、すなわち、％のXFF）自体はUTF-8のための問題ではないことは注目に値します。それらのいくつかが使用されてきたがしかし、は、telnetは、そのビット列のオクテットで有効なUTF-8文字の一部であってもよい他のコマンドイントロ文字を許可します。それは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.
Unicodeは、U + 00FF（UTF-8のオクテットC3のB0）に図形文字（ "分音符付きラテン小文字Y"）を割り当てます。いくつかの注意がこの分野での順序で明確にあります。
Appendix C. The Line-Ending Problem
付録C.行末の問題
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標準のセクション5.8 [UNICODE]に表示され、追加の読み取りのために提案されます。私たちは今日、インターネットで始めていた場合、おそらくそこに勧告に従うと、CRLFに優先し、独占的にLS（U + 2028）を使用する賢明だろう。しかし、CRLFの使用のインストールベースと、それはそれは不可能なので、「ニューライン機能」（「NLF」としてCRLFを使用し続けることが必要であると仮定しNVTとプロトコルとの上位互換性の重要性は、専門用語のセクションを参照してくださいその参照で）。
Appendix D. A Note about Related Future Work
付録D.関連今後の作業についての注意事項
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.
対価は、Telnet（またはSSH [RFC4251]）に与えられるべきである新しい「Unicodeのテキスト」データ型を可能にするために、ストリームのこのタイプとFTPの拡張子を指定するオプション[RFC0959]。
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]デイビス、M.とM. Duerst、 "Unicode規格附属書＃15：Unicode正規化フォーム"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 5.0", 2007.
[ユニコード]のUnicodeコンソーシアム、 "Unicode標準、バージョン5.0"、2007年。
Boston, MA, USA: Addison-Wesley. ISBN
0-321-48091-0
[Unicode32] The Unicode Consortium, "The Unicode Standard, Version 3.0", 2000.
[Unicode32]はUnicodeコンソーシアム、 "Unicode標準、バージョン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/).
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]米国規格協会（アメリカ規格協会の旧米国）、「情報交換用米国コード」、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.
[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規格646、1991。
[NamedSequences] The Unicode Consortium, "NamedSequences-4.1.0.txt", 2005, <http://www.unicode.org/Public/UNIDATA/ NamedSequences.txt>.
【NamedSequences]ユニコードコンソーシアム、 "NamedSequences-4.1.0.txt" 2005年、<http://www.unicode.org/Public/UNIDATA/ NamedSequences.txt>。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020]サーフ、V.、 "ネットワークの交換のためのASCIIフォーマット"、RFC 20、1969年10月。
[RFC0097] Melvin, J. and R. Watson, "First Cut at a Proposed Telnet Protocol", RFC 97, February 1971.
[RFC0097]メルビン、J.及びR.ワトソン、 "提案のTelnetプロトコルで最初のカット"、RFC 97、1971年2月。
[RFC0137] O'Sullivan, T., "Telnet Protocol - a proposed document", RFC 137, April 1971.
[RFC0137]オサリバン、T.、 "TELNETプロトコル - 提案文書"、RFC 137、1971年4月。
[RFC0139] O'Sullivan, T., "Discussion of Telnet Protocol", RFC 139, May 1971.
[RFC0139]オサリバン、T.、 "Telnetの議定書の議論"、RFC 139、1971年5月。
[RFC0318] Postel, J., "Telnet Protocols", RFC 318, April 1972.
[RFC0318]ポステル、J.、 "Telnetのプロトコル"、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]モック、T.、1975年7月、RFC 698 "TelnetはASCIIの拡張オプション"。
[RFC0742] Harrenstien, K., "NAME/FINGER Protocol", RFC 742, December 1977.
[RFC0742] Harrenstien、K.、 "NAME / FINGERプロトコル"、RFC 742、1977年1月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC0954] Harrenstien, K., Stahl, M., and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
[RFC0954] Harrenstien、K.、スタール、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]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、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]バーナーズ=リー、T.、フィールディング、R.、およびH.ニールセン、 "ハイパーテキスト転送プロトコル - 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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC3912] Daigle氏、L.、 "WHOISプロトコル仕様"、RFC 3912、2004年9月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonenと、T.とC. Lonvick、 "セキュアシェル（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.、カープ、C.、およびIAB、RFC 4690 "国際化ドメイン名（IDNの）のレビューと提言"、2006年9月。
Authors' Addresses
著者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Michael A. Padlipsky 8011 Stewart Ave. Los Angeles, CA 90045 USA
マイケル・A・パドリップスキー8011スチュワートアベニュー。ロサンゼルス、CA 90045 USA
Phone: +1 310-670-4288 EMail: the.map@alum.mit.edu
電話：+1 310-670-4288電子メール：the.map@alum.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。