UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 2006年 4月 6日 translation April 6, 2006 翻訳 2006年 4月 7日 translation April 7, 2006 修正 2009年10月27日 translation October 27, 2009 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc4042 を訳者(marimo@wdic.org)が個人的な好奇心で適当に翻 訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。誤 訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要な 場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容について の指摘は、いつでも歓迎します。 Network Working Group M. Crispin Request for Comments: 4042 Panda Programming Category: Informational 1 April 2005 UTF-9 と UTF-18 Unicodeの効率的変換フォーマット このメモの位置づけ このメモは情報をインターネットコミュニティに提供する。このメモは、 いかなる種類のインターネット標準も規定しない。このメモの配布は無制限 である。 著作権 Copyright (C) The Internet Society (2005). 要約 ISO-10646は、世界の記述システムの殆どを含むユニバーサル文字集合(UCS) と呼ばれる巨大文字集合を定義する。コードポイントの等しい集合はUnicodeに より定義され、それは付随する文字特性や他の実装細部を更に定義する。関連 規格化委員会の方針により、Unicodeへの変更およびISO/IEC 646への改正と追 加分は、全文字とコードポイント割り当てが同期するよう、互いに追跡する。 Unicode(UTF-7、UTF-8、UTF-16)用の現行の表現方法は、8ビットオクテッ トでは自然に記憶できるものの、9ビットノネットを利用するプラットフォー ムでは、記憶、計算共に効率的ではない。 この文書は、ノネットを利用するフォーマットにより、効率的に記憶、計算 できるUnicodeの変換フォーマットを説明する。 1. はじめに いくつかのインターネットサイトは、伝統的な8ビットバイトまたはオクテッ トに基づかないプラットフォームを利用する。その一つのプラットフォームに PDP-10があり、それは36ビット語長に基づいている。これらのプラットフォー ムでは、4ビットが各語で未使用となるため、オクテットでデータを表わすこと は無駄となる。9ビットノネットは、より賢明な表現である。 これらのプラットフォームはIETF標準に対応するが、これらの多くは、未だ に[US-ASCII]に相当する7ビット長に基づくテクスト表現を利用する(それは 様々なISO 10646各国バリエーションのために使われた)。 IABは、国際的な、そして多国語の相互運用性を最大限に行なうために、そ の規定符号化された文字集合である([IAB-CHARACTER])を[ISO-10646]に推薦し た。 [UNICODE]の他の変換フォーマットは存在し、恐らくノネット指向のマシンに おいても用いられるが(最も多いのは[UTF-8])、それらは重大な不利益を被る: [UTF-8] 基本多言語面(BMP)のコードポイントを表わすために1から3オクテッ ト、BMP外の[UNICODE]のコードポイントを表わすためには4オクテッ ト、そして非[UNICODE]のコードポイントを表わすためには6オクテッ トが必要である。ノネットに格納される場合、1 [UNICODE] 文字あた り4ビットもの無駄を結果として生じる。 [UTF-16] BMPのコードポイントを表わすために1語長を、BMP外の[UNICODE]の コードポイントを表わすためには2語長を必要とする。ノネット対と して格納される場合、1 [UNICODE] 文字あたり4ビットもの無駄を結 果として生じる。この変換フォーマットは、BMP外のコードポイント を表わすためには複雑な代理を必要とし、また非[UNICODE]コードポ イントは一切表現できない。 [UTF-7] BMPのコードポイントを表わすためには1から5までのセプテット、そ してBMP外のコードポイントを表わすためには8セプテット程度が必要 となる。ノネットに格納される場合、これは1文字あたり16ビットも の無駄を結果として生じる。この変換フォーマットは、非常に複雑で かつ計算機的に贅沢なシフトと「修正BASE64」処理を必要とし、さら に非[UNICODE]コードポイントは一切表現できない。 比較すると、UTF-9はBMPのコードポイントを表わすために1から2までのノネ ットを用い、BMP外の[UNICODE]のコードポイントを表わすためには3ノネット、 そして非[UNICODE]のコードポイントを表わすためには3または4ノネットを使 う。無駄になるビットは一切なく、そしてこの文書の例が示すように、計算処 理は最小である。 [UTF-8]の扱いにおける大部分の複雑さに関しては、[UTF-8]とUTF-9の間の 変化は直接的である。SMTPなどのプロトコルへの将来の拡張が、「有線上」 フォーマットとしての[UTF-8]ではなく、ノネットプラットフォーム間のこれ らのプロトコルにおいてUTF-9の使用が可能になることが望まれている。 同様に、[UNICODE]コードポイントとUTF-18の間の変換も非常に簡単である。 (UCS-2風の)UTF-18は入手可能な[UNICODE]コードポイントのサブセットを表わ しているが、それは[UNICODE]において現在割り当てられる外字以外のコード ポイントを取り巻くだけである。 1.1. 本文書で使われる慣習 この文書のキーワード "MUST"(必須)、"MUST NOT"(禁止)、"REQUIRED" (必要)、"SHALL"(すること)、"SHALL NOT"(しない)、"SHOULD"(すべき)、 "SHOULD NOT"(すべきでない)、"RECOMMENDED"(推奨)、"MAY"(推定)、そし て "OPTIONAL"(オプション)は、BCP 14、RFC 2119 [KEYWORDS]に説明される よう、解釈される必要がある。 2. 概要 UTF-9はノネットの下位8ビットで[UNICODE]コードポイントを符号化し、連 続を最上位ビットで表わす。サロゲートは使用されない。 範囲U+0000-U+00FF([US-ASCII]とLatin 1)の[UNICODE]コードポイントは、 単一のノネットで表現される; 範囲U+0100-U+FFFF(BMPの残り)のコードポイン トは、2つのノネットで表現される; そして、範囲U+1000-U+10FFFF([UNICODE] の残り)のコードポイントは、3つのノネットで表現される。 [ISO-10646](すなわち、範囲0x110000~0x7fffffffのコードポイント)の 非[UNICODE]コードポイントは、UTF-9において自明な拡張により表現されう る。しかし、これらのコードポイントはISOによる[ISO-10646]から削除された ため、これについては議論はしない。 UTF-18は、18ビット固定長で、基本多言語面(BMP、面0)、補助多言語面 (SMP、面1)、補助漢字面(SIP、面2)、および補助特殊用途面(SSP、面14)の [UNICODE]コードポイントを符号化する。それは、現在未使用の面3~13、お よび外字領域である面15、16を符号化しない。 通常、UTF-9及びUTF-18は、9ビット記憶装置や転送の文脈においてのみ用い られるべきである。幾つかのプロトコル、例えば[FTP]はノネット転送に対応 するが、現在のIETFプロトコルスイートは、この面が非常に欠けている。 3. UTF-9 定義 UTF-9ストリームは、9ビットノネットを用い、[ISO-10646]コードポイント を表わす。ノネットの下位8ビットはオクテットであり、最上位ビットは連続 を示す。 UTF-9はサロゲートを使用しない; その結果、UTF-16はUCS-4相当に変換され されなければならず、U+D800-U+DBFFは決してUTF-9に送られない。[UNICODE] コードポイント値のオクテットは、最上位が0でないオクテットで始まり、連 続するUTF-9ノネットに複写される。最下位オクテット以外の全てに、関連す るノネットの継続ビットをセットする。 例: 文字 名称 UTF-9 (8進数) --------- ---- ---------------- 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 541 33 U+10330 GOTHIC LETTER AHSA 401 403 60 U+E0041 TAG LATIN CAPITAL LETTER A 416 400 101 U+10FFFD <16面 外字領域の最後> 420 777 375 0x345ecf1b ([UNICODE]外のUCS-4値) 464 536 717 33 4. UTF-18 定義 UTF-18ストリームは18ビット値を表現すべく、1対の9ビットノネットを用 いて[ISO-10646]のコードポイントを表現している。 UTF-18はサロゲートを使用しない; その結果、UTF-16値はUCS-4相当に変換 されなければならず、U+D800-U+DBFFは決してUTF-18に送られない。 範囲U+0000~U+2FFFFの[UNICODE]コードポイント値はUTF-18値と同じであ り、コピーされる。範囲U+E0000~U+EFFFFの[UNICODE]コードポイント値は、 値0x30000~0x3ffffとしてコピーされる; すなわち、これらの価値は0x70000 によりシフトされる。その他のコードポイント値はUTF-18においては表現で きない。 例: 文字 名称 UTF-18 (8進数) --------- ---- ---------------- 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 060433 U+10330 GOTHIC LETTER AHSA 201460 U+E0041 TAG LATIN CAPITAL LETTER A 600101 5. サンプル ルーチン 5.1. [UNICODE]コードポイントのUTF-9への変換 以下のルーチンは、UCS-4からUTF-9への変換を示す。単純化のため、これら のルーチンはどのような妥当性チェックもしない。アプリケーションにおいて 用いるルーチンでは、無効のUTF-9連鎖、すなわち、ノネットが8進法で400 (0x100)から始まる場合、オーバフローを結果として生じる([UNICODE]の 0x10ffffを超える)連鎖、あるいはUTF-16のサロゲートで用いられるコードポ イントの場合は、拒絶【すべき】(SHOULD)である。 ; UTF-9文字列からUCS-4値を返す(PDP-10アセンブリ言語版) ; 入力: P1/UTF-9文字列への9ビットバイトポインタ ; 出力 +1: 常時, T1/UCS-4値, P1/更新されたバイトポインタ ; T2は破壊される UT92U4: TDZA T1,T1 ; 0で開始 U92U41: XOR T1,T2 ; UCS-4値にオクテットを挿入 LSH T1,^D8 ; UCS-4値にシフトする ILDB T2,P1 ; 次のノネットを得る TRZE T2,400 ; オクテットを抜粋、何か継続するか? JRST U92U41 ; はい、続ける XOR T1,T2 ; 最終オクテットの挿入 POPJ P, /* UTF-9文字列からUCS-4値を返す(C言語版) * 入力: UTF-9文字列へのポインタへのポインタ * 出力: UCS-4文字、ノネットポインタの更新 */ 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; } 5.2. UTF-9からUCS-4への変換 以下のルーチンは、UTF-9からUCS-4への変換を示す。単純化のため、これら のルーチンはどのような妥当性チェックもしない。アプリケーションにおいて 用いるルーチンでは、無効のUCS-4コードポイント、すなわち、UTF-16のサロ ゲートで用いられるコードポイントの場合、値が[UNICODE]の0x10ffffを超え た場合は、拒絶【すべき】(SHOULD)である。 ; UCS-4文字をUTF-9文字列で書き出す(PDP-10アセンブリ言語版) ; 入力: P1/UTF-9文字列への9ビットバイトポインタ ; T1/出力するUCS-4文字 ; 出力 +1: 常時、P1/バイトポインタの更新 ; T1、T2は破壊される。(T1、T2)はアキュームレータペアでなければならない U42UT9: SETO T2, ; このビットは後で用いる ASHC T1,-^D8 ; 下位オクテットは、最上位0のノネットになる U32U91: JUMPE T1,U42U9X ; 継続オクテットがなければ終了 LSHC T1,-^D8 ; T2に次のオクテットをシフトする ROT T2,-1 ; 最上位を1にして、ノネットに変換する PUSHJ P,U42U91 ; 残りを繰り返す U42U9X: LSHC T1,^D9 ; T2から次のノネットを戻す IDPB T1,P1 ; ノネットを書き出す POPJ P, /* UCS-4文字をUTF-9文字列で書き出す(C言語版) * 入力: ノネット文字列へのポインタ * 出力するUCS-4文字 * 出力: 更新されたポインタ */ 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; } 6. 実装経験 サンプルルーチンがデモされており、ノネットベースのアーキテクチャで のUTF-9とUTF-18の実装は非常に簡単である。より洗練されたルーチンは、 ftp://panda.com/tops-20/utools.mac.txt または、ANONYMOUS [FTP]を経た ファイルUTOOLS.MACを経たlingling.panda.comに発見されるかもしれ ない。 我々は現在、セプテット、オクテット、及びノネットの原文データ間で、 ノネットベースのテクストファイル、そして自動変換のサポートを実行中で ある。 7. 参考文献 7.1. 基準の参照 [FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. [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. [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". [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 7.2. 有益な参照 [US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000. [UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997. [UTF-8] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. 8. セキュリティ対策 UTF-8、UTF-9として、[UNICODE]にないコードポイントを表わしているかも しれない。アプリケーションは、全てのコードポイントがU+10FFFFの [UNICODE]最大値を越えないことを保証するよう、UTF-9文字列を有効にするべ きである。例えばこの文書のサンプルルーチンは目的であり、それらの議論を 有効にする試みを行なわない。例えば、オーバフロー([UNICODE]が見積もる 0x10ffffより大きい)についてや、コードポイントにサロゲートが用いられて いないかを試験をすべきである。さらに、無効データを結果として生じ、これ は隠れているチャンネルも作成できる。 9. IANA対策 IANAは、将来の割り当てのために「UTF-9」および「UTF-18」というcharset 名を確保すべきである。 奥付 Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island, WA 98110-2098 Phone: (206) 842-2385 EMail: UTF9@Lingling.Panda.COM 著作権全文 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. 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. 知的所有権 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. 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. 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. 謝辞 RFC編集者の役割のために出資することは、現在インターネットソサエティ によって提供されている。