UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 2000年 3月27日 translation March 27, 2000 修正 2000年 9月23日 correction September 23, 2000 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2781 を訳者(marimo@wdic.org)が個人的な好奇心で適当に翻 訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。誤 訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要な 場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容について の指摘は、いつでも歓迎します。 著作権全文 (Full Copyright Statement) --- 本文書末尾の原文より Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 訳: この文書およびその翻訳は、コピーされ、他に供給され、そして派生語を 論評、違った形で説明、またはその実装の促進が準備され、コピーされ、 出版されて、もし上記の版権情報およびこのパラグラフが、すべてのその ようなコピーおよび派生した作品に含まれるなら、どのような種類の制限 なしで全体や部分を配布できる。しかし、この文書自身は、発展途上のイ ンターネット標準やインターネット標準プロセスにおいて定義された著作 権のための手続のために必要な場合や、英語以外の言語への翻訳の要求が ある場合を除いて、インターネットソサエティまたは他のインターネット 組織の版権情報や参照を削除するなど、いかなる点でも修正できない。 上記で与えられる制限された権限は永久で、インターネットソサエティま たはその後継者、委託人によって撤回されることはない。 ここに含まれるこの文書及び情報は、ありのまま "AS IS" インターネット ソサエティに関して提供され、そして、インターネット特別技術調査委員会 (IETF)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。 Network Working Group P. Hoffman Request for Comments: 2781 Internet Mail Consortium Category: Informational F. Yergeau Alis Technologies February 2000 UTF-16 ISO 10646 の符号化(エンコード)方法 このメモの位置づけ このメモは情報をインターネットコミュニティに提供する。それは、イン ターネット標準を指定しない。このメモの配布は無制限である。 著作権に関する注意 Copyright (C) The Internet Society (2000). All Rights Reserved. 1. 序論 このドキュメントは Unicode/ISO-10646 の UTF-16符号化について説明し、 インターネット上の伝送のためのオクテットストリームとして UTF-16 を流す ことの問題に取り組み、[CHARSET-REG] において示されたMIMEキャラクタセッ トの命名について論じ、そして 3つのMIMEキャラクタセットパラメータ値のた めにレジストレーションを含む: UTF-16BE (ビッグエンディアン)、UTF-16LE (リトルエンディアン)、そして UTF-16。 1.1 背景と動機 Unicode 標準 [UNICODE] と ISO/IEC 10646 [ISO-10646] は世界の書き込み システム[WORKSHOP] の殆どを含む、符号化された文字セット (CCS) <以後 Unicode と呼ぶ> を同時に定義する。UTF-16、この仕様のオブジェクトは、 Unicode 文字データを符号化している標準の方法のうちの1つである;それは、 ちょうど2つのオクテットにおけるすべての現在定義された文字(プレーン0, BMP)を符号化し、そして、ちょうど4つのオクテットにおいて定義される(次 の16のプレーン)ように、すべての他の文字を符号化することができる特徴を 持っている。 Unicode 標準は、さらに実装者に対し、付加的な文字特性や興味深いアプリ ケーションの詳細を定義する。現在まで、文字のレパートリーやコードポイン トの割り当てが同期に留まるように、Unicode の変更、及び ISO/IEC 10646 の修正は、相互を追跡した。適切な標準化委員会は、UTF-16 にアクセス可能 な 17プレーン以外のキャラクタを割り当てないのと同様に、この非常に有益 な同期を維持することを約束した。 キャラクタセット、及び、言語 [CHARPOLICY] に関する IETF 方針は、 IETF プロトコルスキーム [UTF-8] で符号化する UTF-8 キャラクタを使うこ とが【できなければならない】と述べている。既にいくつかの製品とネット ワーク標準が UTF-16 を指定し、インターネットのためにそれを重要な符号化 としている。この文書は、[CHARPOLICY] 文書への最新情報や UTF-16 符号化 の記述のみではない。 1.2 用語 この文書の "しなければならない", "してはならない", "必要である", "することとする", "しない", "するべきである", "するべきではない", "推奨される", "することができる", および "オプションである" というキー ワードは、RFC 2119 [MUSTSHOULD] において説明されるよう解釈すること。 (訳注:この訳文では該当キーワードは【】で囲んで訳出している) この文書全体で、キャラクタ値は16進法において示される。例えば "0x013C" は、値が CCS の文字で、整数値316(10進)に割り当てらた文字である。 2. UTF-16 の定義 UTF-16 は、Unicode 標準バージョン 3.0 [UNICODE] において示される。最 終的な参照は ISO/IEC 10646-1 [ISO-10646] の 付録Q である。このセクショ ンの残りは要約で、定義は簡単な用語である。 ISO 10646 では、個々の文字は番号を割り当てられ、それを Unicode では Unicode スカラ値と呼んでいる。この数は文字のUCS-4値として同じで、この 文書は簡潔のために "文字値" と称する。UTF-16 符号化の時に、文字は文字 値に依存する1または2つの符号なしの16ビット整数を使って表わされる。バイ トストリームとしての伝送のためのこれらの整数列についてはセクション3に おいて論じられる。 どのように文字がUTF-16で符号化されるかを示した規則は下記のとおり: ・0x10000 未満の値を持つ文字は、値を文字のそれに等しい状態にして1つ の 16ビット整数として表現される。 ・0x10000 ~ 0x10FFFF の範囲内の値を持つ文字は、0xD800~0xDBFF (いわ ゆる高位ハーフゾーン、または高位サロゲートエリア) の間の値を持つ16 ビット整数に続き、0xDC00~0xDFFF (いわゆる下位ハーフゾーン、または 下位サロゲートエリア) の間の値を持つ16ビット整数で表される。 ・0x10FFFF を超える値を持つ文字は、UTF-16 では符号化することができな い。 注意事項: 0xD800~0xDFFF の間の値は、明確に UTF-16 で使用のために予約 され、そしてこれらの値は割り当てられた文字を持っていない。 2.1 UTF-16 の符号化 ISO 10646 文字値から UTF-16 までの1つの文字の符号化は、次のとおりに 続く。U は 0x10FFFF を超えない文字番号である。 1) U < 0x10000 なら、Uを16ビット無符号整数として符号化し、終了する。 2) U' = U - 0x10000 と置く。U が 0x10FFFF 以下なので、U' は 0xFFFFF 以下となるはずだ。すなわち、U'は20ビットで表現可能である。 3) 2つの16ビット無符号整数 W1 および W2 に、それぞれ 0xD800 と 0xDC00 を初期設定する。これらの整数はそれぞれ自由に計20ビットの文字値を符 号化することができる10ビットを持っている。 4) U' の 20ビットのうち、上位10ビットをW1の下位10ビットに割り当て、U' の下位10ビットを W2の下位10ビットへ割り当て、終了する。 図で示すと、ステップ2から4までが以下のように見える: U' = yyyyyyyyyyxxxxxxxxxx W1 = 110110yyyyyyyyyy W2 = 110111xxxxxxxxxx 2.2 UTF-16 の復号 UTF-16 から ISO 10646 文字値までの 1 つの文字の復号は、次のとおりに 続く。 W1 はテクストを表す整数列における次の16ビット整数とする。W2 は W1 の 後に続く (最終的な) の次の整数だとする。 1) W1 < 0xD800 または W1 > 0xDFFF なら、文字値 U は W1 の値とし、終了 する。 2) W1 が 0xD800~0xDBFF かどうかを決定する。もしそうでなければ、その シーケンスは間違っており、そして正当な文字は W1 を用いて得ることが できない。終了する。 3) W2 (すなわちそのシーケンスが W1 で終わる) が無い、もしくは W2 が 0xDC00~0xDFFF で無いなら、そのシーケンスは間違っている。終了する。 4) W1 の下位10ビットを上位10ビット、W2 の下位10ビットを下位10ビットと して、20ビット無符号整数 U' を組み立てること。 5) 文字値 U を得るために U' に 0x10000 を加えること。終了する。 ステップ2と3がエラーを示すことに注意すること。エラーリカバリについて はこの文書により規定されない。ステップ2と3のエラーで終わる時には、情報 を失わせるのでは無く、呼びだした側がエラーを診断することを手助けするた めに、W1の値で U を設定することが賢明かもしれない。また、もし適切なエ ラー報告および/または回復が提供されるならば、エラーの検出において、文 字列解読アルゴリズムが、上への説明を解読している単一の文字と対比される ように終わる必要がないことに注意せよ。 3. UTF-16 テクストの分類 この付録Aは、3種類のMIMEキャラクタセットのためのレジストレーション仕 様を含んでいる: "UTF-16BE"、"UTF-16LE"、そして "UTF-16"。MIMEキャラク タセットは、CCS (符号化された文字集合) と CES (文字符号化方法) のコン ビを表している。ここでは、CCS は Unicode/ISO 10646 であり、CESは合計3 種類のケースで、個々の文字のオクテット列、および文字列で使われる外部の 決定を除いて同じである。 このセクションは、テクスト列にあてはまる3つの分類のうちのどれである かを説明する。セクション4は、どのようにテクスト列で分類を解釈するかを 説明する。 3.1 ビッグエンディアンとリトルエンディアンの定義 歴史的に、コンピュータハードウェアは、16ビット整数などの2オクテット エンティティを、2つの方法のうちの1つの方法を用いての処理した。いわゆる "ビッグエンディアン" ハードウェアは、最初、上位のオクテットによって2オ クテットエンティティを処理し、それはメモリの下位のアドレスにある; 従っ て、外でディスクまたはネットワークインタフェース(シリアル)に書かれる 時には、上位オクテットはデータストリームの1番目と思われている。一方で は、"リトルエンディアン" ハードウェアは、最初、下位のオーダーオクテッ トによって2オクテットエンティティを処理する。双方の種類のハードウェア は今日共通である。 例えば、10進数で258を表す符号なしの16ビット整数は0x0102である。その 数のビッグエンディアン列は、オクテット0x01 に続いてオクテット0x02であ る。その数のリトルエンディアン列は、オクテット0x02 に続いてオクテット 0x01 である。 以下のCコード断片は、ハードウェアのネイティヴなバイトオーダーとは無 関係に、ビッグエンディアンオーダーにおいて16ビット量をファイルに書くた めの方法を示す。 void write_be(unsigned short u, FILE f) /* short は16ビットと仮定 */ { putc(u >> 8, f); /* 上位バイトの出力 */ putc(u & 0xFF, f); /* そして下位バイト */ } その用語は標準トラック文書において正規に定義される必要があるが、ビッ グエンディアンを示すために多くの RFC では "ネットワークバイトオーダー" (network byte order) が用いられている。 ISO 10646 はビッグエンディアン([ISO-10646] のセクション6.3)を好むが、 リトルエンディアンオーダーはまた、インターネットで時々使われる。 3.2 バイトオーダーマーク (BOM) Unicode 標準と ISO 10646 は、"ZERO WIDTH NON-BREAKING SPACE" (0xFEFF) 文字を定義し、それはまた "バイトオーダーマーク" としてインフォーマルに 知られている(略語は "BOM")。後者の名前により、本物のテクスト内の "ZERO WIDTH NON-BREAKING SPACE" としてのその正常な使用だけでなく、文字 の2番目の可能な慣習がほのめかされる。この、Unicode の セクション2.4 と ISO 10646 付録F(情報提供)により示唆された用法は、0xFEFF文字 が Unicode 文字列における "署名" として計画された; そのような連続したストリームの 受信者は、シリアルのオーダーを確認するために、その時ストリームがUnicode 文字から成っているというヒントと方法として初期の文字を両方で用いること ができる。そのような署名によって計画された UTF-16 列では、最初の2オク テットが、0xFE に続いて 0xFF であるなら、オーダーはビッグエンディアン である; もしそれらが、0xFF に続いて 0xFE であるなら、オーダーはリトル エンディアンである。0xFFFE は、正確にバイトオーダーマークとして 0xFEFF の有用性を保存するためものもで、Unicode 文字ではないことに注意せよ。 文字列の最初を除いたどのような位置に出現する文字 0xFEFF も zero-width non-breaking space の意味であると解釈【されなければならず】、それをバ イトオーダーマークと解釈【してはならない】点は重要である。そのステート メントの珍奇なカラクリは、いつも真実とは限らない: 文字列のの最初の文字 0xFEFFは zero-width non-breaking space と解釈【すべき】で、常にバイト オーダーマークなわけではない。例えば、もしプロセスが UTF-16 文字列を多 くのパートに分割するなら、パートは 0xFEFF から始まるかもしれない。なぜ なら、そのパート列の最初に zero-width non-breaking space があったからで ある。 Unicode 標準は、本物の意図した "ZERO WIDTH NON-BREAKING SPACE" では ない、最初の位置におけるそのような文字が符号化 (符号化署名) の人工品で あるかもしれない理論的基礎、さらに、文字が最初の 0xFEFF よりテクストを 処理する前に除去されるかもしれないことを示唆する、異なるレイヤ(文字の ディジタル署名や計算など)において、文字列ののすべての文字の存在を信頼 しているそのような除去が外部のプロセスに影響するかもしれないことに注意 すること。 特に、UTF-16 プレーンテクストで、最初の 0xFEFF が署名ではないことも ありうるということ。連結した2つの文字を署名として除去することが必要な 場合、他の場合はその結果に生じる文字列接続ポイントで、意図していない "ZERO WIDTH NON-BREAKING SPACE" を含むかもしれない。 また、いくつかの仕様書が、UTF-16 として定義付けて分類されたオブジェ クトの初期の 0xFEFF 文字を委任し、この署名がオブジェクトの一部ではない と明示する。 3.3 UTF-16テクストのための定義を選ぶ アプリケーションとそれを分類するどのようなものでも、UTF-16 文字エ ンコーディングを使い、そして、テクストを明白に分類し、そして、テクス トの文字列オーダーを知り、テクストを "UTF-16BE" か "UTF-16LE" のいず れかテクストのエンディアンネスに基づいて適切であるものに分類【するべ き】である。これはテクストを処理するアプリケーションを許すが、決定的 な列に知るために、テクストの中で見ることができない。 "UTF-16BE" キャラクタセットのテクストは、ビッグエンディアンにおい て単一の16ビットUTF-16値を作るオクテット列で【なければならない】。 UTF-16BEテクストに分類したシステムは、テクスト中へBOMを挿入【しては ならない】。 "UTF-16LE" キャラクタセットのテクストは、リトルエンディアンにおい て単一の16ビットUTF-16値を作るオクテット列で【なければならない】。 UTF-16LEテクストに分類したシステムは、テクスト中へBOMを挿入【しては ならない】。 UTF-16文字符号化を用い、明示的なcharsetラベルをテクストに置き、そ してテクストの文字のエンディアンを知らない、どのような分類アプリケー ションでも、"UTF-16" としてテクストを分類【しなければならならず】、 またさらにテクストの開始が 0xFEFF かどうかを【確かめるべき】である。 "UTF-16BE" または "UTF-16LE" を使うことの "要求" (SHOULD) 規則への 例外は、UTF-16テクストのBOMを委任する文書フォーマットによって起こり、 従って "UTF-16" タグだけの使用を必要とする。 4. 解釈テクスト定義 プログラムが、テクストが "UTF-16BE"、"UTF-16LE"、もしくは "UTF-16" として分類されるのを見る時、それは前のセクションで与えられた分類規則 において基づくいくつかの仮定をすることができる。これらの仮定は、その 時プログラムがテクストを処理することを可能にする。 4.1 UTF-16BE として定義された、解釈テクスト "UTF-16BE" と分類されるテクストは、常にビッグエンディアンであると 解釈できる。頭のBOMの検出は、UTF-16BE としてラベルを付けて分類された テクストの不連鎖に影響しない。Unicode キャラクタ 0xFFFE がないので、 0xFE に続いて 0xFF が発見されれば、エラーである。 4.2 UTF-16LE として定義された、解釈テクスト "UTF-16LE" と分類されるテクストは、常にリトルエンディアンであると 解釈できる。頭のBOMの検出は、UTF-16LE としてラベルを付けて分類された テクストの不連鎖に影響しない。Unicode キャラクタ 0xFFFE がないので、 0xFF に続いて 0xFE が発見されれば、エラーである。 4.3 UTF-16 として定義された、解釈テクスト "UTF-16" キャラクタセットと分類されるテクストは、ビッグエンディア ンまたはリトルエンディアンオーダーにおいて連鎖される。もしテクストの 最初の2つのオクテットが、0xFE に続いて 0xFF なら、その時、テクストは ビッグエンディアンであると解釈できるだろう。もしテクストの最初の2つ のオクテットが、0xFF に続いて 0xFE なら、その時、テクストはリトルエ ンディアンであると解釈できるだろう。もし、テクストの最初の2つのオク テットが、0xFE 0xFF でも 0xFF 0xFE でもないなら、その時、テクストは ビッグエンディアンであると解釈【されるべきだ】。 "UTF-16" キャラクタセットラベルによってテクストを処理する全てのア プリケーションは、テクストの最初の2オクテットを少なくとも読み、そし てテクストのエンディアンを決定するために、それらのオクテットを処理す ることが【出来ねばならない】。"UTF-16" キャラクタセットラベルによっ てテクストを処理するアプリケーションは、それらがビッグエンディアン BOM、リトルエンディアンBOM、またはBOMではないかどうかを認識するため に、最初の2つのオクテットをチェックせずにエンディアンを【仮定しては ならない】。"UTF-16" キャラクタセットラベルによってテクストを処理す る全てのアプリケーションは、ビッグエンディアンとリトルエンディアンテ クストの両方を解釈することが出来なければならない。 5. 例 例として、エジプトの神 Ra をキャラクタ値 0x12345 で表す象形文字の キャラクタがあると考えよう (現在この文字は Unicode に存在しない) 。 ここの例は、全て句に評価せよ: *=Ra "*" が Ra 象形文字 (0x12345) を表している場所。 BOM 無しで UTF-16BE として定義付けされたテクスト: D8 08 DF 45 00 3D 00 52 00 61 BOM 無しで UTF-16LE として定義付けされたテクスト: 08 D8 45 DF 3D 00 52 00 61 00 BOM によりビッグエンディアンだと定義づけされた UTF-16 テクスト: FE FF D8 08 DF 45 00 3D 00 52 00 61 BOM によりリトルエンディアンだと定義づけされた UTF-16 テクスト: FF FE 08 D8 45 DF 3D 00 52 00 61 00 6. 標準のバージョン ISO/IEC 10646は、時々公開される改正によりアップデートされる; 同様に、Unicode 標準には幾つかのバージョンが存在する: 1.0、1.1、 2.0、2.1、およびこの記述現在の 3.0。各新バージョンは、実装以外の前の ものに取って代わるが、データは即座にはアップデートされない。 一般に、変更は古いデータについての特定の問題を提出しない新しい文字 を追加することに相当している。しかし、ISO/IEC 10646 改正5のため、韓 国語ハングル領域は移動して拡張された。それによって新しい仕様の下で無 効のハングル文字を含むあらゆる古いデータを作りあげた。Unicode 2.0 は Unicode 1.1 から同じ違いを持っている。そのような互換性がない変化を許 すための公式な理由は、ハングルを含む重要な実装、及びデータが存在しな かったことであった。真実そうではあるが、その声名は立証できない。この 出来事は「韓国の混乱」と呼ばれ、委員会は、そのような互換性がない変化 を再び起こさない事を誓約した。 Appendix A で論じられるように、新しいバージョン、及び特にあらゆる 共存できない変更でも、MIME文字符号化ラベルについて結果を得られる。 7. IANA 配慮 IANA は、それらの付録に発見された登録テンプレートを使って、RFC 2278 に応じた付録A.1、A.2、およびA.3に発見されたキャラクタセットを登録する ことになっている。 8. セキュリティ考慮 UTF-16 は、この文書のセクション6と付録Aに説明されるように、頻繁に 追加されている ISO 10646 キャラクタセットに基づく。プロセッサは、未 知の文字を含むことによって攻撃者が受信者を傷つられないような方法で、 プロセッサが作成された時点での未定義の文字を処理することができなけれ ばならない。 ディスプレイ端末またはキーボードを再プログラムできる制御文字をチェ ックする時に、どのようなタイプのテクスト(UTF-16として符号化されたテ クストを含む)でも処理するプロセッサが用心深いだろう。同様にテクスト エンティティ(埋め込まれたプログラミングコードをさがす等)を解釈する プロセッサは、受信者に警報を出さずにコードを実行したりしないよう、慎 重でなければならない。 UTF-16 におけるテクストは、外部の処理を引き起こすであろうオブジェ クト置換文字 (0xFFFC) のような特別なキャラクタを、処理プログラムの解 釈、及び実行されるであろう外部のデータストリームの可用性に応じて含む かもしれない。この外部の処理は、メッセージの送信側が受領システムを攻 撃することを可能にする副作用を持つことができる。 UTF-16の実装者は、どのようにそれらが違法なUTF-16連鎖を処理するかの セキュリティ面を考慮する必要がある(すなわち、異常値もしくはペアにな らないサロゲートペアを包含するシーケンス)。それをある変則的方式で動 作させる、いくつかの状況で、攻撃者が、UTF-16構文により許されないオク テット連鎖をそれに送ることで、不注意な UTF-16 パーサを利用することが できる恐れがある。 9. References [CHARPOLICY] Alvestrand, H., "キャラクタセットと言語のIETF方針", BCP 18, RFC 2277, January 1998. [CHARSET-REG] Freed, N. and J. Postel, "IANA キャラクタ登録手続", BCP 19, RFC 2278, January 1998. [HTTP-1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "ハイパーテクスト転送プロトコル -- HTTP/1.1", RFC 2616, June 1999. [ISO-10646] ISO/IEC 10646-1:1993. 国際標準 --情報技術 -- Universal Multiple-Octet Coded Character Set (UCS) -- パート1: アーキテクチャおよび基本多言語面。 22回の改正と2回の技術的な誤植がこれまで公表された。 UTF-16は改正1として出版された付録Qにおいて説明される。 多くの他の改正は、現在規格化の様々な段階にある。 恐らく2000年に公表されるように、第二版が準備中である; この新版では、UTF-16はたぶん付録Cにおいて説明される。 [MUSTSHOULD] Bradner, S., "RFC用の標示要件レベルのキーワード", BCP 14, RFC 2119, March 1997. [UNICODE] The Unicode Consortium, "The Unicode Standard -- バージョン3.0", ISBN 0-201-61633-5. 詳細は、 . [UTF-8] Yergeau, F., "UTF-8, ISO 10646 の変換フォーマット", RFC 2279, January 1998. [WORKSHOP] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin., M. and P. Svanberg, "IAB文字セットワークショップのリポート", RFC 2130, April 1997. 10. 謝辞 Deborah Goldsmith はこの仕様のため多くの初期の表現を書いた。Martin Duerst は多くの重要な変更を提案した。他の重要な貢献者は次のとおり: Mati Allouche Walt Daniels Mark Davis Ned Freed Asmus Freytag Lloyd Honomichl Dan Kegel Murata Makoto Larry Masinter Markus Scherer Keld Simonsen Ken Whistler この仕様書のうちのいくらかが、[UTF-8] からコピーされて、その文書に は多くの人々が取り組んだ。この文書に間接的に寄与しただろう多くの人々 のために、どうかその文書の謝辞セクションを見ていただきたい。 A. キャラクタセット レジストレーション このメモが3つのMIMEキャラクタセット [CHARSET-REG] の登録のための基 礎として役立つことが期待されている。提案されたキャラクタセットは、 "UTF-16BE"、"UTF-16LE"、そして "UTF-16" である。これらの文字列は、少 なくとも修正5(韓国語のブロック)まで全ての修正を含む ISO/IEC 10646 の レパートリーからキャラクタから成るテクストを含む対象に分類する(上で 概説されたエンコーディング、及び、連鎖スキームを使う一連のオクテット にコード化される)。 "UTF-16BE"、"UTF-16LE"、そして "UTF-16" が "text" トップレベルタイ プの下のメディアタイプでの使用に適当【ではない】ことに注意すること。 なぜなら、それらはラインエンディングをMIME "text" メディアタイプのた めに必要な方法で符号化しないからである。これに対する例外はMIME風のメ カニズムを使うHTTPだが、text トップレベルタイプの制限から免除されて いる(HTTP 1.1 [HTTP-1.1] のセクション19.4.2を見よ)。 総称的に ISO/IEC 10646 を参照して、ここで示されたラベルがバージョ ン識別を含まないことは顕著である。これは意図的で、その原理は次の通り である: まさにワイヤにおいて、一連の文字が何より多く受け取られた一連のバイ トを解釈するための必要な情報を与えるために、MIME キャラクタセットが 設計される。標準化されたキャラクタが矛盾して変わらない限り、バージョ ン番号は目的にかなわない ([MIME] における RFC 2045、セクション2.2 を 見よ)。なぜなら、それが新しく割り当てた文字をタグから学んで何も得な いので、それがまわりに知らず受け取られうるためである。タグそのもの は、いずれにせよ受け取られようとしている新しいキャラクタについて何も 教えない。 従って、それらの標準が両立して発展する限り、バージョンを確認するラ ベルを持つことの明白な利点は、明白にそれのみである。しかし、欠点がそ のようなバージョン依存のラベルにある: 更に古いアプリケーションが更に 新しい未知のラベルを伴ったデータを受け取るとき、それは、ラベルを認識 することが出来ず、そして完全にはデータを扱うことが出来無いかもしれな い。一方、一般的な既知のラベルは、データの大抵正しい処理(新しいキャ ラクタを全く含まないのも無理はない)を誘発したであろう。 "韓国の混乱" (ISO/IEC 10646 修正 5) は、上述のとおり原則としてバー ジョンの独立した MIME キャラクタコード表の適切さと矛盾する共存できな い変更である。しかし、互換性問題は Unicode 1.1 (または、修正5の前の ISO/IEC 10646) に従ってコード化された韓国のジャングルキャラクタを含 むデータによってのみ現われ得る。だが、悩むようなそのようなデータは間 違いなく存在せず、まさしくそのような理由で、互換性がない変化は容認で きると考えられた。 実際上(その時)、そのラベルが修正5後の全ての説明を参照するために理 解される限り、そして、共存できない変更が実際に発生しない限り、バー ジョン‐非依存のラベルは、保証される。もし互換性がない変化がISO/IEC 10646の後継バージョンに存在するなら、ここで定義されたMIMEキャラクタ コード表は、IETF が明確に別の方法で決定するかしないまでは、前のバー ジョンと提携させられる状態を維持するだろう。 A.1 UTF-16BE のためのレジストレーション To: ietf-charsets@iana.org Subject: Registration of new charset Charset name(s): UTF-16BE Published specification(s): This specification Suitable for use in MIME content types under the "text" top-level type: No Person & email address to contact for further information: Paul Hoffman Francois Yergeau A.2 UTF-16LE のためのレジストレーション To: ietf-charsets@iana.org Subject: Registration of new charset Charset name(s): UTF-16LE Published specification(s): This specification Suitable for use in MIME content types under the "text" top-level type: No Person & email address to contact for further information: Paul Hoffman Francois Yergeau A.3 UTF-16 のためのレジストレーション To: ietf-charsets@iana.org Subject: Registration of new charset Charset name(s): UTF-16 Published specification(s): This specification Suitable for use in MIME content types under the "text" top-level type: No Person & email address to contact for further information: Paul Hoffman Francois Yergeau 奥付 Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA EMail: phoffman@imc.org Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon, Suite 600 Montreal QC H4M 2P2 Canada EMail: fyergeau@alis.com 謝辞 RFCエディタ機能のために出資することは現在インターネットソサエティに よって提供される。