Network Working Group M. Crispin
Request for Comments: 4042 Panda Programming
Category: Informational 1 April 2005
UTF-9 and UTF-18
Efficient Transformation Formats of Unicode
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。 いかなる種類のインターネット標準も指定していません。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 646 track each other, so that the character repertoires and code point assignments remain in synchronization.
ISO-10646は、Universal Character Set（UCS）と呼ばれる大きな文字セットを定義します。これは、世界のほとんどの書記体系を網羅しています。 同じコードポイントのセットがUnicodeによって定義され、追加の文字プロパティおよびその他の実装の詳細がさらに定義されます。 関連する標準化委員会のポリシーにより、Unicodeの変更とISO / IEC 646への修正と追加が相互に追跡されるため、キャラクターのレパートリーとコードポイントの割り当ては同期したままになります。
The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.
Unicodeの現在の表現形式（UTF-7、UTF-8、UTF-16）は、8ビットオクテットの代わりに9ビットのnonetを自然なストレージユニットとして利用するプラットフォームでは、ストレージおよび計算効率が良くありません。
This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient.
このドキュメントでは、フォーマットがストレージおよび計算効率に優れるように、nonetを利用するUnicodeの変換フォーマットについて説明します。
A number of Internet sites utilize platforms that are not based upon the traditional 8-bit byte or octet. One such platform is the PDP-10, which is based upon a 36-bit word. On these platforms, it is wasteful to represent data in octets, since 4 bits are left unused in each word. The 9-bit nonet is a much more sensible representation.
多くのインターネットサイトは、従来の8ビットバイトまたはオクテットに基づいていないプラットフォームを利用しています。 そのようなプラットフォームの1つがPDP-10で、36ビットワードに基づいています。 これらのプラットフォームでは、各ワードで4ビットが使用されないため、データをオクテットで表すのは無駄です。 9ビットのnonetは、より賢明な表現です。
Although these platforms support IETF standards, many of these platforms still utilize a text representation based upon the septet, which is only suitable for [US-ASCII] (although it has been used for various ISO 10646 national variants).
これらのプラットフォームはIETF標準をサポートしていますが、これらのプラットフォームの多くは、[US-ASCII]にのみ適したセプテットに基づいたテキスト表現を使用しています（ただし、さまざまなISO 10646各国のバリエーションに使用されています）。
To maximize international and multi-lingual interoperability, the IAB has recommended ([IAB-CHARACTER]) that [ISO-10646] be the default coded character set.
国際および多言語の相互運用性を最大化するために、IABは[ISO-10646]をデフォルトのコード化文字セットにすることを推奨しています（[IAB-CHARACTER]）。
Although other transformation formats of [UNICODE] exist, and conceivably can be used on nonet-oriented machines (most notably [UTF-8]), they suffer significant disadvantages:
[UNICODE]の他の変換フォーマットが存在し、おそらくnonet指向のマシン（特に[UTF-8]）で使用できますが、重大な欠点があります。
[UTF-8] requires one to three octets to represent codepoints in the Basic Multilingual Plane (BMP), four octets to represent [UNICODE] codepoints outside the BMP, and six octets to represent non-[UNICODE] codepoints. When stored in nonets, this results in as many as four wasted bits per [UNICODE] character.
[UTF-8]は、Basic Multilingual Plane（BMP）のコードポイントを表す1〜3オクテット、BMP外の[UNICODE]コードポイントを表す4オクテット、および非[UNICODE]コードポイントを表す6オクテットを必要とします。 nonetに保存すると、[UNICODE]文字ごとに最大4ビットの無駄なビットが発生します。
[UTF-16] requires a hexadecet to represent codepoints in the BMP, and two hexadecets to represent [UNICODE] codepoints outside the BMP. When stored in nonet pairs, this results in as many as four wasted bits per [UNICODE] character. This transformation format requires complex surrogates to represent codepoints outside the BMP, and can not represent non-[UNICODE] codepoints at all.
[UTF-16]は、BMPのコードポイントを表すために16進数、およびBMPの外部の[UNICODE]コードポイントを表すために2つの16進数を必要とします。 nonetペアで保存すると、[UNICODE]文字ごとに最大4ビットの無駄なビットが発生します。 この変換形式では、BMPの外側のコードポイントを表す複雑なサロゲートが必要であり、非[UNICODE]コードポイントを表すことはできません。
[UTF-7] requires one to five septets to represent codepoints in the BMP, and as many as eight septets to represent codepoints outside the BMP. When stored in nonets, this results in as many as sixteen wasted bits per character. This transformation format requires very complex and computationally expensive shifting and "modified BASE64" processing, and can not represent non-[UNICODE] codepoints at all.
[UTF-7]は、BMPのコードポイントを表すために1〜5個のセプテットを必要とし、BMPの外側のコードポイントを表すために最大8個のセプテットを必要とします。 nonetに保存すると、1文字あたり最大16個の無駄なビットが発生します。 この変換フォーマットは、非常に複雑で計算コストの高いシフトと「修正BASE64」処理を必要とし、非[UNICODE]コードポイントをまったく表現できません。
By comparison, UTF-9 uses one to two nonets to represent codepoints in the BMP, three nonets to represent [UNICODE] codepoints outside the BMP, and three or four nonets to represent non-[UNICODE] codepoints. There are no wasted bits, and as the examples in this document demonstrate, the computational processing is minimal.
比較すると、UTF-9は、1〜2つのnonetを使用してBMPのコードポイントを表し、3つのnonetを使用してBMP外の[UNICODE]コードポイントを表し、3〜4つのnonetを使用して非[UNICODE]コードポイントを表します。 無駄なビットはありません。このドキュメントの例が示すように、計算処理は最小限です。
Transformation between [UTF-8] and UTF-9 is straightforward, with most of the complexity in the handling of [UTF-8]. It is hoped that future extensions to protocols such as SMTP will permit the use of UTF-9 in these protocols between nonet platforms without the use of [UTF-8] as an "on the wire" format.
[UTF-8]とUTF-9間の変換は簡単で、[UTF-8]の処理のほとんどの複雑さがあります。 SMTPなどのプロトコルの将来の拡張により、「on the wire」形式として[UTF-8]を使用せずに、nonetプラットフォーム間でこれらのプロトコルでUTF-9を使用できるようになることが望まれます。
Similarly, transformation between [UNICODE] codepoints and UTF-18 is also quite simple. Although (like UCS-2) UTF-18 only represents a subset of the available [UNICODE] codepoints, it encompasses the non-private codepoints that are currently assigned in [UNICODE].
同様に、[UNICODE]コードポイントとUTF-18間の変換も非常に簡単です。 （UCS-2のように）UTF-18は利用可能な[UNICODE]コードポイントのサブセットのみを表しますが、[UNICODE]で現在割り当てられている非プライベートコードポイントを含みます。
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 BCP 14, RFC 2119 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は BCP 14、RFC 2119 [KEYWORDS]で説明されているように解釈されます。
UTF-9 encodes [UNICODE] codepoints in the low order 8 bits of a nonet, using the high order bit to indicate continuation. Surrogates are not used.
UTF-9は、継続を示すために高位ビットを使用して、ノネットの下位8ビットで[UNICODE]コードポイントをエンコードします。 サロゲートは使用されません。
[UNICODE] codepoints in the range U+0000 - U+00FF ([US-ASCII] and Latin 1) are represented by a single nonet; codepoints in the range U+0100 - U+FFFF (the remainder of the BMP) are represented by two nonets; and codepoints in the range U+1000 - U+10FFFF (remainder of [UNICODE]) are represented by three nonets.
U + 0000-U + 00FF（[US-ASCII]およびLatin 1）の範囲の[UNICODE]コードポイントは、単一のnonetで表されます。 U + 0100-U + FFFF（BMPの残り）の範囲のコードポイントは、2つのnonetで表されます。 U + 1000-U + 10FFFF（[UNICODE]の残り）の範囲のコードポイントは、3つのnonetで表されます。
Non-[UNICODE] codepoints in [ISO-10646] (that is, codepoints in the range 0x110000 - 0x7fffffff) can also be represented in UTF-9 by obvious extension, but this is not discussed further as these codepoints have been removed from [ISO-10646] by ISO.
[ISO-10646]の非[UNICODE]コードポイント（つまり、0x110000〜0x7fffffffの範囲のコードポイント）は、UTF-9で明白な拡張子で表すこともできますが、これらのコードポイントは[ ISO-10646] ISOによる。
UTF-18 encodes [UNICODE] codepoints in the Basic Multilingual Plane (BMP, plane 0), Supplementary Multilingual Plane (SMP, plane 1), Supplementary Ideographic Plane (SIP, plane 2), and Supplementary Special-purpose Plane (SSP, plane 14) in a single 18-bit value. It does not encode planes 3 though 13, which are currently unused; nor planes 15 or 16, which are private spaces.
UTF-18は、基本多言語面（BMP、プレーン0）、補足多言語面（SMP、プレーン1）、補足表意文字面（SIP、プレーン2）、および補足特殊目的面（SSP、プレーン）で[UNICODE]コードポイントをエンコードします 14）単一の18ビット値。 現在使用されていないプレーン3〜13をエンコードしません。 プライベートスペースであるプレーン15または16もありません。
Normally, UTF-9 and UTF-18 should only be used in the context of 9 bit storage and transport. Although some protocols, e.g., [FTP], support transport of nonets, the current IETF protocol suite is quite deficient in this area. The IETF is urged to take action to improve IETF protocol support for nonets.
通常、UTF-9およびUTF-18は、9ビットのストレージおよびトランスポートのコンテキストでのみ使用する必要があります。 [FTP]などの一部のプロトコルはnonetのトランスポートをサポートしますが、現在のIETFプロトコルスイートはこの分野ではかなり不十分です。 IETFは、nonetのIETFプロトコルサポートを改善するための措置を講じることを求められています。
A UTF-9 stream represents [ISO-10646] codepoints using 9 bit nonets. The low order 8-bits of a nonet is an octet, and the high order bit indicates continuation.
UTF-9ストリームは、9ビットのnonetを使用して[ISO-10646]コードポイントを表します。 nonetの下位8ビットはオクテットであり、上位ビットは継続を示します。
UTF-9 does not use surrogates; consequently a UTF-16 value must be transformed into the UCS-4 equivalent, and U+D800 - U+DBFF are never transmitted in UTF-9.
UTF-9はサロゲートを使用しません。 したがって、UTF-16値はUCS-4に相当するものに変換する必要があり、U + D800-U + DBFFはUTF-9で送信されません。
Octets of the [UNICODE] codepoint value are then copied into successive UTF-9 nonets, starting with the most-significant non-zero octet. All but the least significant octet have the continuation bit set in the associated nonet.
[UNICODE]コードポイント値のオクテットは、最上位のゼロ以外のオクテットから開始して、連続するUTF-9ノネットにコピーされます。 最下位のオクテットを除くすべての関連ビットには、継続ビットが設定されています。
Examples:
例：
Character Name UTF-9 (in octal)
--------- ---- ----------------
U+0041 LATIN CAPITAL LETTER A 101
U+00C0 LATIN CAPITAL LETTER A WITH GRAVE 300
U+0391 GREEK CAPITAL LETTER ALPHA 403 221
U+611B <CJK ideograph meaning "love"> 541 33
U+10330 GOTHIC LETTER AHSA 401 403 60
U+E0041 TAG LATIN CAPITAL LETTER A 416 400 101
U+10FFFD <Plane 16 Private Use, Last> 420 777 375
0x345ecf1b (UCS-4 value not in [UNICODE]) 464 536 717 33
A UTF-18 stream represents [ISO-10646] codepoints using a pair of 9 bit nonets to form an 18-bit value.
UTF-18ストリームは、[ISO-10646]コードポイントを表し、9ビットのnonetのペアを使用して18ビット値を形成します。
UTF-18 does not use surrogates; consequently a UTF-16 value must be transformed into the UCS-4 equivalent, and U+D800 - U+DBFF are never transmitted in UTF-18.
UTF-18はサロゲートを使用しません。 したがって、UTF-16値はUCS-4に相当するものに変換する必要があり、U + D800-U + DBFFはUTF-18で送信されません。
[UNICODE] codepoint values in the range U+0000 - U+2FFFF are copied as the same value into a UTF-18 value. [UNICODE] codepoint values in the range U+E0000 - U+EFFFF are copied as values 0x30000 - 0x3ffff; that is, these values are shifted by 0x70000. Other codepoint values can not be represented in UTF-18.
[UNICODE] U + 0000-U + 2FFFFの範囲のコードポイント値は、同じ値としてUTF-18値にコピーされます。 [UNICODE] U + E0000-U + EFFFFの範囲のコードポイント値は、値0x30000-0x3ffffとしてコピーされます。 つまり、これらの値は0x70000だけシフトされます。 他のコードポイント値はUTF-18で表現できません。
Examples:
例：
Character Name UTF-18 (in octal)
--------- ---- ----------------
U+0041 LATIN CAPITAL LETTER A 000101
U+00C0 LATIN CAPITAL LETTER A WITH GRAVE 000300
U+0391 GREEK CAPITAL LETTER ALPHA 001621
U+611B <CJK ideograph meaning "love"> 060433
U+10330 GOTHIC LETTER AHSA 201460
U+E0041 TAG LATIN CAPITAL LETTER A 600101
The following routines demonstrate conversion from UCS-4 to UTF-9. For simplicity, these routines do not do any validity checking. Routines used in applications SHOULD reject invalid UTF-9 sequences; that is, the first nonet with a value of 400 octal (0x100), or sequences that result in an overflow (exceeding 0x10ffff for [UNICODE]), or codepoints used for UTF-16 surrogates.
次のルーチンは、UCS-4からUTF-9への変換を示しています。 簡単にするために、これらのルーチンは妥当性検査を行いません。 アプリケーションで使用されるルーチンは、無効なUTF-9シーケンスを拒否する必要があります。 つまり、値が8進数（0x100）の最初のnonet、またはオーバーフロー（[UNICODE]の0x10ffffを超える）になるシーケンス、またはUTF-16サロゲートに使用されるコードポイント。
; Return UCS-4 value from UTF-9 string (PDP-10 assembly version) ; Accepts: P1/ 9-bit byte pointer to UTF-9 string ; Returns +1: Always, T1/ UCS-4 value, P1/ updated byte pointer ; Clobbers T2
; UTF-9文字列（PDP-10アセンブリバージョン）からUCS-4値を返します。 受け入れ：P1 / UTF-9文字列への9ビットバイトポインター。 +1を返します：常に、T1 / UCS-4値、P1 /更新されたバイトポインター。 クローバーT2
UT92U4: TDZA T1,T1 ; start with zero U92U41: XOR T1,T2 ; insert octet into UCS-4 value LSH T1,^D8 ; shift UCS-4 value ILDB T2,P1 ; get next nonet TRZE T2,400 ; extract octet, any continuation? JRST U92U41 ; yes, continue XOR T1,T2 ; insert final octet POPJ P,
UT92U4：TDZA T1、T1; ゼロから開始U92U41：XOR T1、T2; UCS-4値LSH T1、^ D8にオクテットを挿入します。 UCS-4値ILDB T2、P1をシフトします。 次のnonet TRZE T2,400を取得します。 オクテットを抽出しますか？ JRST U92U41; はい、XOR T1、T2を続行します。 最後のオクテットPOPJ Pを挿入し、
/* Return UCS-4 value from UTF-9 string (C version)
* Accepts: pointer to pointer to UTF-9 string
* Returns: UCS-4 character, nonet pointer updated
*/
UINT31 UTF9_to_UCS4 (UINT9 **utf9PP)
{
UINT9 nonet;
UINT31 ucs4;
for (ucs4 = (nonet = *(*utf9PP)++) & 0xff;
nonet & 0x100;
ucs4 |= (nonet = *(*utf9PP)++) & 0xff)
ucs4 <<= 8;
return ucs4;
}
The following routines demonstrate conversion from UTF-9 to UCS-4. For simplicity, these routines do not do any validity checking. Routines used in applications SHOULD reject invalid UCS-4 codepoints; that is, codepoints used for UTF-16 surrogates or codepoints with values exceeding 0x10ffff for [UNICODE].
次のルーチンは、UTF-9からUCS-4への変換を示しています。 簡単にするために、これらのルーチンは妥当性検査を行いません。 アプリケーションで使用されるルーチンは、無効なUCS-4コードポイントを拒否する必要があります。 つまり、UTF-16サロゲートに使用されるコードポイント、または[UNICODE]の値が0x10ffffを超えるコードポイント。
; Write UCS-4 character to UTF-9 string (PDP-10 assembly version) ; Accepts: P1/ 9-bit byte pointer to UTF-9 string ; T1/ UCS-4 character to write ; Returns +1: Always, P1/ updated byte pointer ; Clobbers T1, T2; (T1, T2) must be an accumulator pair
; UCS-4文字をUTF-9文字列（PDP-10アセンブリバージョン）に書き込みます。 受け入れ：P1 / UTF-9文字列への9ビットバイトポインター。 書き込むT1 / UCS-4文字。 +1を返します：常に、P1 /更新されたバイトポインター。 クロバーT1、T2; （T1、T2）はアキュムレーターペアでなければなりません
U42UT9: SETO T2, ; we'll need some of these 1-bits later ASHC T1,-^D8 ; low octet becomes nonet with high 0-bit U32U91: JUMPE T1,U42U9X ; done if no more octets LSHC T1,-^D8 ; shift next octet into T2 ROT T2,-1 ; turn it into nonet with high 1 bit PUSHJ P,U42U91 ; recurse for remainder U42U9X: LSHC T1,^D9 ; get next nonet back from T2 IDPB T1,P1 ; write nonet POPJ P,
U42UT9：瀬戸T2、; これらの1ビットの後でASHC T1、-^ D8が必要になります。 下位のオクテットは上位の0ビットU32U91でノネットになります：JUMPE T1、U42U9X; オクテットLSHC T1、-^ D8がこれ以上ない場合に実行されます。 次のオクテットをT2 ROT T2、-1にシフトします。 上位1ビットPUSHJ P、U42U91を使用して、nonetに変換します。 残りU42U9Xの再帰：LSHC T1、^ D9; T2 IDPB T1、P1から次のnonetを取得します。 nonet POPJ Pを書きます。
/* Write UCS-4 character to UTF-9 string (C version)
* Accepts: pointer to nonet string
* UCS-4 character to write
* Returns: updated pointer
*/
UINT9 *UCS4_to_UTF9 (UINT9 *utf9P,UINT31 ucs4)
{
if (ucs4 > 0x100) {
if (ucs4 > 0x10000) {
if (ucs4 > 0x1000000)
*utf9P++ = 0x100 | ((ucs4 >> 24) & 0xff);
*utf9P++ = 0x100 | ((ucs4 >> 16) & 0xff);
}
*utf9P++ = 0x100 | ((ucs4 >> 8) & 0xff);
}
*utf9P++ = ucs4 & 0xff;
return utf9P;
}
As the sample routines demonstrate, it is quite simple to implement UTF-9 and UTF-18 on a nonet-based architecture. More sophisticated routines can be found in ftp://panda.com/tops-20/utools.mac.txt or from lingling.panda.com via the file <UTF9>UTOOLS.MAC via ANONYMOUS [FTP].
サンプルルーチンが示すように、UTF-9およびUTF-18をnonetベースのアーキテクチャに実装するのは非常に簡単です。 より洗練されたルーチンは、ftp：//panda.com/tops-20/utools.mac.txtにあるか、lingling.panda.comからファイル<UTF9> UTOOLS.MACにあるANONYMOUS [FTP]にあります。
We are now in the process of implementing support for nonet-based text files and automated transformation between septet, octet, and nonet textual data.
現在、nonetベースのテキストファイルのサポートと、septet、octet、およびnonetテキストデータ間の自動変換の実装を進めています。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[IAB-CHARACTER] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[IAB-CHARACTER] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Crispin、M.、and P. Svanberg、 "The Report of the IAB Character Set Workshopが開催されました 1996年2月29日-1996年3月1日」、RFC 2130、1997年4月。
[ISO-10646] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS)", ISO/IEC Standard 10646, comprised of ISO/IEC 10646-1:2000, "Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO/IEC 10646-2:2001, "Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 2: Supplementary Planes" and ISO/IEC 10646-1:2000/Amd 1:2002, "Mathematical symbols and other characters".
[ISO-10646]国際標準化機構、「情報技術-ユニバーサルマルチオクテットコード化文字セット（UCS）」、ISO / IEC 10646-1：2000で構成されるISO / IEC標準10646、「情報技術-ユニバーサルマルチ- オクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本多言語面」、ISO / IEC 10646-2：2001、「情報技術-ユニバーサルマルチオクテットコード化文字セット（UCS）-パート2：補助平面」およびISO / IEC 10646-1：2000 / Amd 1：2002、「数学記号とその他の文字」。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard - Version 3.2", defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 and by the Unicode Standard Annex #28: Unicode 3.2, March 2002.
[UNICODE] Unicodeコンソーシアム、「Unicode Standard-Version 3.2」、Unicode Standard、Version 3.0（Reading、MA、Addison-Wesley、2000。ISBN0-201-61633-5）で定義され、Unicodeにより修正 標準付属書＃27：Unicode 3.1およびUnicode標準付属書＃28：Unicode 3.2、2002年3月。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII] American National Standards Institute、「コード化文字セット-情報交換用7ビットアメリカ標準コード」、ANSI X3.4、1986
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF-16] Hoffman、P。、およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997.
[UTF-7]ゴールドスミス、D。、およびM.デイビス、「UTF-7 Unicodeのメールセーフ変換フォーマット」、RFC 2152、1997年5月。
[UTF-8] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[UTF-8] Sollins、K。、「統一リソース名解決のアーキテクチャの原則」、RFC 2276、1998年1月。
As with UTF-8, UTF-9 can represent codepoints that are not in [UNICODE]. Applications should validate UTF-9 strings to ensure that all codepoints do not exceed the [UNICODE] maximum of U+10FFFF.
UTF-8と同様に、UTF-9は[UNICODE]にないコードポイントを表すことができます。 アプリケーションは、UTF-9文字列を検証して、すべてのコードポイントが[UNICODE]の最大値であるU + 10FFFFを超えないようにする必要があります。
The sample routines in this document are for example purposes, and make no attempt to validate their arguments, e.g., test for overflow ([UNICODE] values great than 0x10ffff) or codepoints used for surrogates. Besides resulting in invalid data, this can also create covert channels.
このドキュメントのサンプルルーチンは例であり、引数（たとえば、オーバーフロー（[UNICODE]値が0x10ffffより大きい）またはサロゲートに使用されるコードポイントのテストなど、引数の検証を試みません。 無効なデータになるだけでなく、秘密のチャネルを作成することもできます。
The IANA shall reserve the charset names "UTF-9" and "UTF-18" for future assignment.
IANAは、将来の割り当てのために文字セット名「UTF-9」および「UTF-18」を予約します。
Author's Address
著者の住所
Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island, WA 98110-2098
Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island、WA 98110-2098
Phone: (206) 842-2385 EMail: UTF9@Lingling.Panda.COM
電話：（206）842-2385 EMail：UTF9@Lingling.Panda.COM
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。