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 10646 に対する修正と追加はお互いに追随しており、文字のリポジ トリとコードポイント割り当ては同期が取られている。 しかし、記憶域として 8ビットのオクテットではなく 9ビットの 「ノネット」を自然な単位としたプラットフォーム上においては、 現在の Unicode(UTF-7, UTF-8, UTF-16)の表現形式では、記憶域と 計算量が効率的ではない。 この文書では、「ノネット」アーキティクチャ上で記憶域と計算量 を効率よく利用できるようにするための Unicode の変換形式を記述する。 1. はじめに インターネット上のサイトには、伝統的な 8ビットのバイトもしく はオクテットではないものを基本としたプラットフォームを利用し ているサイトがいくつかある。そのようなプラットフォームの一例 として PDP-10 があり、これは 36 ビットのワードを基本としてい る。このようなプラットフォームにおいてデータをオクテットで表 現しようとすると、一ワードあたり 4 ビットが未使用となってしま い、非常に無駄である。9ビット単位のノネットの方が、より気の利 いた表現である。 このようなプラットフォームにおいては、IETF 標準をサポートして いるにも関わらず、未だに 7ビット単位の「セプテット」を基本と したテキスト表現を利用しているプラットフォームが多い。これで は [US-ASCII] しか適切に扱えない(ISO 10646 の各国向け変形版は 使用されてきたが)。 Crispin Informational [Page 1] RFC 4042 UTF-9 and UTF-18 1 April 2005 国際化および多言語化に関する相互運用性を最大化するために、IAB は [ISO-10646] をデフォルトの文字セットとすることを推奨してい る([IAB-CHARACTER])。 [UNICODE] の変換形式は他にも存在し(最も有名なものとしては [UTF-8])、ノネット指向のマシンにおいても利用可能と考えられる が、これらには重大な欠点がある。 [UTF-8] 基本多言語面(BMP: Basic Multilingual Plane)上のコードポ イントを表現するには 1 〜 3 オクテット、BMP 範囲外の [UNICODE] コードポイントを表現するには 4 オクテット、 [UNICODE]外のコードポイントを表現するには 6 オクテット を必要とする。ノネットとして格納しようとすると、結果と して [UNICODE]文字一文字あたり 4ビットも無駄になってしまう。 [UTF-16] BMP上のコードポイントを表現するには16ビット単位の 1 ヘ クサディシット、BMP 範囲外の [UNICODE] コードポイントを 表現するには 2 ヘクサディシットを必要とする。ノネットの 組で格納しようとすると、結果として[UNICODE]文字一文字あ たり4 ビットも無駄になってしまう。またこの変換形式では、 BMP 範囲外のコードポイントを表現するには複雑なサロゲー トが必要であり、[UNICODE] 外のコードポイントは全く表現 することができない。 [UTF-7] BMP上のコードポイントを表現するには 1 〜 5 セプテット、 BMP外のコードポイントを表現するには 8 セプテットも必要 とする。ノネットで格納すると、結果として一文字当たり 16 ビットも無駄になってしまう。この変換形式は非常に複雑で、 計算量上高価なシフト演算や「修正 BASE64」演算を必要とす る。また [UNICODE] 外のコードポイントは全く表現すること ができない。 これに比べて、UTF-9 は BMP 上のコードポイントを表現するには 1〜 2 ノネット、BMP 外の [UNICODE] コードポイントを表現するには 3 ノネット、[UNICODE]外のコードポイントを表現するには 3〜4 ノネッ トを使用するのみである。無駄なビットが生じることはなく、また 本文書の実例に示すように計算処理も小さく抑えることができる。 [UTF-8] と UTF-9 の間の変換はごく単純であり、複雑な処理のほと んどは [UTF-8] を取り扱う部分である。将来的には SMTP などのプ ロトコルにおいても、ノネットプラットフォーム間の通信では [UTF-8] を介することなく、「電線上の」形式として UTF-9 が利用 することができるように拡張されることが望まれる。 Crispin Informational [Page 2] RFC 4042 UTF-9 and UTF-18 1 April 2005 同様に、[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] コードポイ ントをエンコードし、最上位ビットは継続に指示に使用される。サ ロゲートは使用されない。 [UNICODE] コードポイントの U+0000 - U+00FF の範囲([US-ASCII] とラテン1) は、1ノネットで表現される。U+0100 - U+FFFF の範囲 のコードポイント(BMPの残りの部分)は 2 ノネットで表現される。 U+1000 - U+10FFFF の範囲のコードポイント([UNICODE]の残り)は 3 ノネットで表現される。 [ISO-10646] の[UNICODE]外のコードポイント(すなわち、0x110000 - 0x7fffffffの範囲のコードポイント)についても、単純な拡張で UTF-9 で表現することは可能であるが、これらのコードポイントは ISO によって [ISO-10646] から削除されているので、これ以上は議 論しない。 UTF-18 は、[UNICODE] コードポイントの基本多言語面(BMP: Basic Multilingual Plane、0面)、補助多言語面(SMP:Supplementary Multilingual Plane、1面)、補助漢字面(SIP:Supplementary Ideographic Plane 、2面)、補助特殊用途面(SSP:Supplementary Special-purpose Plane、14面)を一つの 18ビット値でエンコードす る。現在使用されていない 3面から13面および私用領域の15面、16 面はエンコードしない。 通常は、UTF-9 と UTF-18 は 9 ビットの格納域と転送が必要な文脈 においてのみ使用したほうが良い。[FTP]などノネットの転送をサポー トしているプロトコルもいくつかあるが、現状の IETF プロトコル 群はこの点において全く不完全である。IETF は、IETFプロトコルの ノネットサポートを向上させるべく、今すぐ行動を起こすべきである。 3. UTF-9 定義 UTF-9 ストリームは [ISO-10646] コードポイントを 9ビットのノネッ ト単位で表現する。ノネットの下位 8 ビットはオクテットであり、 最上位ビットは継続を意味する。 Crispin Informational [Page 3] RFC 4042 UTF-9 and UTF-18 1 April 2005 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ストリームは、 [ISO-10646] コードポイントを、 9 ビット のノネットペアの 18 ビットの値として使用して表現する。 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 だけずらした値としてコピーする[*訳注: 0xb0000の誤り?]。その他のコードポイントの値は 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 Crispin Informational [Page 4] RFC 4042 UTF-9 and UTF-18 1 April 2005 5. 処理プログラム例 5.1. [UNICODE] コードポイントから UTF-9 への変換 以下に示す処理ルーチンは UCS-4 から UTF-9 への変換を示してい る。説明を単純にするために、ここではエラーチェック処理は一切 行っていない。実際のアプリケーションで使用する処理においては、 不正な UTF-9 シーケンス、すなわち、最初のノネット値が 8進数で 400 (0x100) の場合、結果がオーバーフローしてしまう([UNICODE] の 0x10ffff を超えてしまう)シーケンス、あるいは UTF-16 サロゲー トで使われるコードポイントの場合を除外するべきである(SHOULD)。 [*訳注: 説明文とコード例が 5.1 と 5.2 で逆になっていると思わ れるが、本翻訳文においては原文通りの順序で記述する。] ; 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)。 Crispin Informational [Page 5] RFC 4042 UTF-9 and UTF-18 1 April 2005 ; 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 または lingling.panda.com の UTF9 ファイル UTOOLS.MACから、匿名 [FTP] によって入手できる。 Crispin Informational [Page 6] RFC 4042 UTF-9 and UTF-18 1 April 2005 我々は現在、ノネットベースのテキストファイルのサポートと、セ プテット、オクテット、ノネット間のテキストデータの自動変換の 実装を行っているところである。 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. Crispin Informational [Page 7] RFC 4042 UTF-9 and UTF-18 1 April 2005 [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] の範囲に含まれないコードポイントも 表現できてしまうこと。アプリケーションは、全てのコードポイン トが [UNICODE] の最大値である U+10FFFF を超えないことを保証す るために、UTF-9 文字列の正当性チェックを行うべきである。 この文書に含まれる処理コード例はあくまで例を目的としたもので あり、これらの値の正当性チェック、つまり、オーバーフロー ([UNICODE] 値が 0x10ffff より大きいこと)のチェックも、サロゲー トで使用されるコードポイントであるかのチェックも行っていない。 この結果として、不正なデータが得られるというだけでなく、不正 な侵入経路を作り出してしまう可能性がある。 9. IANA に関する考慮 The IANA shall reserve the charset names "UTF-9" and "UTF-18" for future assignment. IANA は将来の割り当てのために "UTF-9" と "UTF-18" の文字セッ ト名を予約するべきである。 著者の連絡先 Mark R. Crispin Panda Programming 6158 NE Lariat Loop Bainbridge Island, WA 98110-2098 Phone: (206) 842-2385 EMail: UTF9@Lingling.Panda.COM Crispin Informational [Page 8] RFC 4042 UTF-9 and UTF-18 1 April 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. 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編集業務のための資金は現在インターネット協会から提供されて いる。 Crispin Informational [Page 9]