[要約] RFC 4042は、UTF-9とUTF-18というUnicodeの効率的な変換形式について説明しています。このRFCの目的は、より効率的なUnicodeのエンコーディングを提供することです。
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
UnicodeのUTF-9およびUTF-18効率的な変換形式
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).
Copyright（c）The Internet Society（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は、世界の執筆システムのほとんどを網羅するユニバーサルキャラクターセット（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ビットノンエットを8ビットOCTETの代わりに自然なストレージユニットとして利用するプラットフォームでは、ストレージと計算効率ではありません。
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つは、36ビットワードに基づいたPDP-10です。これらのプラットフォームでは、各単語で4ビットが使用されていないままになっているため、オクテットのデータを表すことは無駄です。9ビットのノンエットは、はるかに賢明な表現です。
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]の他の変換形式は存在し、おそらく非ET指向のマシンで使用できると考えられますが（最も顕著なのは[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]は、基本的な多言語平面（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のコードポイントを表すヘキサデセトと、BMPの外側の[Unicode]コードポイントを表す2つのヘキサデセットを必要とします。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に保管すると、16文字あたり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つの非ゼットを使用してBMPのコードポイントを表し、3つの非ゼットを使用してBMPの外側の[Unicode]コードポイント、3つまたは4つの非Nonetを表して非[Unicode] CodePointsを表します。無駄なビットはありません。このドキュメントの例が示すように、計算処理は最小限です。
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などのプロトコルへの将来の拡張により、[UTF-8]を「On the Wire」形式として使用せずに、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] CodePointsと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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
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は、[Unicode]コードポイントを、高次ビットを使用して継続を示すために、[Unicode]コードポイントを8ビットでエンコードします。サロゲートは使用されません。
[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.
[unicode] range u 0000 -u 00ff（[us -ascii]およびラテン1）の範囲のコードポイントは、単一の非netで表されます。範囲U 0100 -u ffff（BMPの残り）の範囲のコードポイントは、2つの非ゼットで表されます。範囲U 1000 -u 10ffff（[unicode]の残り）の範囲のコードポイントは、3つの非ゼットで表されます。
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ビット値。現在使用されていない13では、平面3をエンコードしません。プライベートスペースである平面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]）は、非地域の輸送をサポートしていますが、現在の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ビットの非ゼットを使用した[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] CodePoint値のオクテットは、最も重要な非ゼロオクテットから始まる、連続した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ストリームは、9ビットの非ゼットのペアを使用して18ビット値を形成する[ISO-10646]コードポイントを表します。
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]範囲のrange u 0000 -u 2ffffのコードポイント値は、同じ値としてUTF -18値にコピーされます。[unicode]範囲のコードポイント値u e0000 -u effffは値0x30000-0x3ffffとしてコピーされます。つまり、これらの値は0x70000でシフトされます。他のCodePoint値は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シーケンスを拒否する必要があります。つまり、400オクタル（0x100）の値を持つ最初の非net、またはオーバーフロー（[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
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;octetを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コードポイントを拒否する必要があります。つまり、[unicode]の場合は0x10ffffを超える値を持つUTF-16のサロゲートまたはコードポイントに使用されるコードポイントです。
; 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
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：seto t2、;これらの1ビットのいくつかは、後でAshc T1、 - ^d8を必要とします。低オクテットは、高0ビットU32U91：Jumpe T1、U42U9xで非etになります。octets lshc t1がもうない場合、 - ^d8;次のオクテットをt2腐ったt2にシフトします。-1;ハイ1ビットプッシュ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].
サンプルルーチンが示すように、NonetベースのアーキテクチャにUTF-9とUTF-18を実装するのは非常に簡単です。より洗練されたルーチンは、ftp：//panda.com/tops-20/utools.mac.txtから、またはanonymous [ftp]を介してファイル<utf9> utools.macを介してlingling.panda.comから見つけることができます。
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。、およびP. Svanberg、」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]国際標準化機関、「情報技術 - ユニバーサル多octetコード化された文字セット（UCS）」、ISO/IEC標準10646、ISO/IEC 10646-1：2000で構成されています。Octet Coded Character Set（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 Consortium、「Unicode Standard-Version 3.2」、Unicode Standard（Reading、Ma、Addison-Wesley、2000。ISBN0-201-61633-5）、Unicodeによって修正されたISBN 0-201-61633-5）Standard Annex＃27：Unicode 3.1およびUnicode Standard Annex＃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] Goldsmith、D。およびM. Davis、「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文字列を検証して、すべてのコードポイントがU 10FFFFの[Unicode]の最大値を超えないようにする必要があります。
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プログラミング6158 NE Lariat Loop Bainbridge Island、WA 98110-2098
Phone: (206) 842-2385 EMail: UTF9@Lingling.Panda.COM
電話：（206）842-2385メール：utf9@lingling.panda.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。