UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1998年 8月23日 / translation 23 August 1998 修正 2004年 1月21日 / correction 21 January 2004 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2279 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 翻訳内容に関してご指摘を頂いた高橋誠様に深く感謝いたします。 Network Working Group F. Yergeau Request for Comments: 2279 Alis Technologies Obsoletes: 2044 January 1998 Category: Standards Track UTF-8, ISO 10646 を変換したフォーマット このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準運 用プロトコルを策定し、改善のための議論、提案を求めるものである。 規格化状態とプロトコルのステータスのために、この現在の版である「イ ンターネット公的プロトコル標準」(STD 1)も参照されたい。このメモの配 布は無制限である。 著作権について Copyright (C) The Internet Society (1998). All Rights Reserved. 摘要 ISO/IEC 10646-1は、世界の記述システムの殆ど含んでいるユニバーサル 文字セット(UCS)と呼ばれるオクテット文字セットを定義する。しかし、マ ルチオクテット文字は多くの現在のアプリケーションやプロトコルと互換が なく、そしてこれは、いわゆる、数種の異なる特徴を持つそれぞれのUCS変 換フォーマット(UTF)の開発につながった。UTF-8、このメモの対象は、ファ イルシステム、パーザ、及び他のソフトウェアに互換性に提供して、完全な US-ASCII範囲を守れる特徴を持っている。そのうえ、他の値のために透過的 である。このメモは、適切な基準のバージョンの問題にアドレスしている事 項において RFC 2044 を更新し、そして交換する。 1. はじめに ISO/IEC 10646-1 [ISO-10646] が、世界の記述システムの殆どを含むユニ バーサル文字セット(UCS)と呼ばれるマルチオクテット文字セットを定義す る。2つのマルチオクテットエンコーディングが定義され、4オクテットでエ ンコードされたものは USC-4 と呼ばれ、そして2オクテットでエンコードさ れたものを USC-2 と呼び、最初の64K文字のUCS(基本多言語面:BMP)をアド レスできる。その外側は現在割り当てがない。 同様の文字セットはUnicode標準 [UNICODE] により定義され、さらに実装 者の大きな関心の付加的な文字特性や他のアプリケーションの詳細を定義す る。しかし、UCS-4エンコーディングを持たずに定義されることは顕著であ る。現在まで、Unicodeの変化およびISO/IEC 10646への改正と追加分は、文 字レパートリーとコードポイント割り当てが同期されるよう、相互に追跡し た。関連規格化委員会は、この非常に有益な同期を維持することを約束し た。 しかし、UCS-2 と UCS-4 エンコーディングは、8または7ビット文字を仮 定する多くの現在のアプリケーションとプロトコルにおいては使うのが難し い。16ビット文字を扱うことができる更に新しいシステムでも、UCS-4デー タは処理できない。この状況は、種々の特徴を持つそれぞれの、いわゆる UCS変換フォーマット(UTF)の開発につながった。 UTF-1 は ISO/IEC 10646から取り去られたので、歴史的な意味しかない。 UTF-7 は最上位ビットをゼロ(7ビットUS-ASCII値 [US-ASCII])にしたオ クテットだけを使って完全なBMPレパートリーを符号化する特徴を持ってお り、従って、メールセーフの符号化 ([RFC2152])であると思われる。 UTF-8つまりこのメモの対象は、オクテットのすべてのビットを使うが、 完全な US-ASCII の範囲を守れる特徴がある。 US-ASCII文字は、正常なUS-ASCII値を持つ1つのオクテットとして符号化 されて、そして、その値を持つオクテットは必ず US-ASCII 文字を表わし、 他の文字にはならない。 UTF-16は、UCS-4レパートリーのサブセットを予約した範囲のUCS-2値に変 換する方式である。UTF-16のためにUTF-8変換において、予約範囲からの UCS-2値をUTF-8が特別に扱われなければならない。 UTF-8は、一定しない数のオクテットとしてUCS-2またはUCS-4文字を符号 化する。そしてそこで、オクテットの数および各々の値は、ISO/IEC 10646 の文字に割り当てられた整数値によって変わる。この変換フォーマットは以 下の特徴を持っている(すべての値は16進で示した): - 0000 0000 から 0000 007F (US-ASCIIレパートリー)までの文字は、00 から7Fまでのオクテットと一致している(7ビットUS-ASCII値)。結果と して、プレーンASCII文字列は同じく正当なUTF-8文字列であるというこ とである。 - US-ASCII値は、UTF-8符号化文字ストリームにおいて別の文字には使用 されない。これにより US-ASCII 値を解析し他の値は透過的に扱うファ イルシステムや、他のソフトウェア(例えば Cライブラリ中のprintf() 関数)の互換性が保たれる。 - UTF-8と、UCS-4とUCS-2のどちらかの間との相互変換は容易である。 - マルチオクテット列の最初のオクテットは、後続するオクテットの数を 示す。 - オクテット値には FE と FF は決して出現しない。 - 文字の境界は、オクテット列のどこからでも容易に見つけられる。 - UCS-4 文字列の辞書編集上のソート順は保存される。もちろん、ソート 条件がどちらのケースにでも文化的には正当ではないので、これは限ら れた感心である。 - Boyer-Moore高速検索アルゴリズムはUTF-8データによって使われうる。 - UTF-8 文字列は、それ自体が単純なアルゴリズムででもかなり確実に認 識できる。すなわち、他の符号化における文字列で有効なUTF-8に見え る確率は低く、文字列が長くなるとその確率はさらに減少する。 UTF-8は、もとは、UNIXシステムと互換性のある ファイルシステムセーフ UCS変換フォーマット[FSS-UTF]を指定する目的を持つ X/Openジョイント国 際化グループXOJIGの計画であり、単一の符号化で多言語テクストをサポー トした。 元の筆者は、Gary Miller、Greger Leijonhufvud、およびJohn Entenmann であった。その後、Ken ThompsonとRob Pikeは、フォーマルなUTF-8のため に重要な仕事をした。 また、Unicode技術リポート#4やUnicode標準のバージョン2.0 [UNICODE] においても記述が見つかるかもしれない。UTF-8内のUTF-16データへの規定 を含む最終的な参照は、ISO/IEC 10646-1 [ISO-10646]のAnnex Rである。 2. UTF-8 定義 UTF-8は、文字は1から6オクテット長に符号化される。 1オクテット長の場合、その「シーケンス」の唯一のオクテットは、最上 位ビットは 0 がセットされており、残りの 7ビットは文字値を符号化する ために用いられる。 n オクテットのシーケンス(n>1)は、最初のオクテットの最上位 n ビッ トには 1 をセットし、次に一つの 0 のビットをセットする。そのオクテッ トの残っているビットは、コード化される文字の値のビットを含んでいる。 続くすべてのオクテットは、最上位ビットに 1 が設定されており、そし て、次のビットが 0 にセットされ、残る 6ビットでキャラクタをエンコー ドする。 下のテーブルは、これらの幾つかのオクテットタイプのフォーマットを要 約する。文字 x は、UCS-4 文字値のビットを符号化するために利用可能な ビットを示す。 UCS-4 範囲 (16進数) UTF-8 オクテット列 (2進数) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx UCS-4 から UTF-8 までのエンコーディングは、次のとおりに続く: 1) 上記のテーブルの文字値から必要なオクテットおよび最初のカラム番号 を決定すること。テーブルの列が相互に排他的であること。すなわち、 与えられたUCS-4文字を符号化するのにただ 一つだけ有効な方法がある ことに注意することが重要である。 2) テーブルの2番目のカラムに従ってオクテットの最上位ビットを準備す ること。 3) 全てのxビットが埋められるまで、キャラクタ値の最下位ビットからス タートし、最初にそれらをシーケンスの最後のオクテットに置き、そし て、最後の手前のオクテットという順で埋めていきすべてのxビットを 埋めるまで続ける。 UCS-2(または Unicode)から UTF-8 に符号化するためのアルゴリズム は、2つの評価された 0 オクテットにより個々の UCS-2 文字を単に拡 張することによって上記から(原則としては)得られうる。 しかしながら、UTF-16によって変更されたUCS-4文字であるD800~DFFF (Unicode用語におけるサロゲートペア)の間のUCS-2値のペアは、特別な 処置が必要になる。UTF-16変換を復号し、その時上記のように変換され るUCS-4文字を生成する。 UTF-8 から UCS-4 までのエンコーディングは、次のとおりに続く: 1) UCS-4文字の4オクテットの全てのビットを0で初期化する。 2) どのビットが上記のテーブルの連続するオクテットの数からの文字値お よび 2番目のカラムを符号化するかを決定する(ビットはxをマークし た)。 3) UCS-4文字のシーケンスからビットを分配する。まず、最初の連続の最 後のオクテットからの下の上位のビット、さらに、xビットが全く残さ れなくなるまで、左に進む。 もしUTF-8シーケンスが 3オクテットに過ぎないなら、解読はUCS-2に直 接進むことができる。 注意 -- 解読アルゴリズムの上記の実際の実行においては、無効の シーケンスを解読することに対して、保護するべきである。 例えば、考慮のない実装では、文字U+0000に対し無効のUTF-8シーケ ンスC0 80を(不正に)解読し、安全結果を持ち、かつ、または、他 の問題を起こすかもしれない。 下記セキュリティ対策セクションを見よ。 更に詳細なアルゴリズム、及び式は、[FSS_UTF]、[UNICODE]、または、 [ISO-10646]のAnnex Rで見つかるだろう。 3. 標準のバージョン ISO/IEC 10646は、時々改正や追加などが発表され更新される; 同様に、 Unicode標準にも種々なバージョンが存在する。1.0、1.1、そしてこの記述 対象である現在の2.0である。 それぞれの新しいバージョンは以前のものを廃棄し、交換する。しかし実 装や、かなりの重要なデータはすぐには更新されないだろう。 一般に、変更は、過去のデータについての特定の問題を引き起こさない新 しい文字を追加することである。しかし、ISO/IEC 10646への改正5により、 朝鮮語のハングル領域は移動し、拡張された。従って、ハングル文字を含む どのような過去のデータでも新バージョンの下では無効である。 Unicode 2.0はUnicode 1.1と同じ違いを持っている。そのような非互換の変更を許す ための理由は、ハングルを含む主要な実装および重要なデータが全くなかっ た、ということだった。真実そうな論述だが、それは立証不可能である。そ の事件は「朝鮮語の混乱」と称され、そして、関連委員会で、そのような共 存できない変更が再び行なわれないよう、誓約された。 新バージョン、および特にセクション5で論じられるように、あらゆる共 存できない変更でも、MIME文字符号化ラベルによって表現される。 4. 例 UCS-2 文字列 "A." (0041, 2262, 0391, 002E) は次のようにUTF-8に符号化されるだろう: 41 E2 89 A2 CE 91 2E 朝鮮語の単語「hangugo」(D55C、AD6D、C5B4)のためのハングル文を表 わしているUCS-2文字列は次のように符号化されるだろう: ED 95 9C EA B5 AD EC 96 B4 日本語の単語「nihongo」(65E5、672C、8A9E)のための漢文字を表わし ているUCS-2文字列は次のように符号化されるだろう: E6 97 A5 E6 9C AC E8 AA 9E 5. MIME 登録 このメモがMIME文字セットパラメーター(charset) [CHARSET-REG]の登録 のための基礎として役立つことを意味する。提案されたcharsetパラメータ 値は "UTF-8" である。 この文字列は、少なくとも修正5(朝鮮語領域)まで全ての修正を含む、 ISO/IEC 10646のレパートリーの文字からなるテクストを含むメディアタイ プを、上述された符号化方法を使う一連のオクテットに符号化されて、分類 する。UTF-8は、"text" トップレベルタイプ下のMIMEコンテンツタイプでの 使用が相応しい。属性にISO/IEC 10646を参照し、ラベル "UTF-8" がバージョ ン識別を含まないことは、注目に値する。これは、次の根拠に述べるように、 意図的なものである: MIME文字コード表ラベルは、何より多く一連のキャラクタにワイヤに受け 取られる一連のバイトを解釈するために必要充分な情報を与えるよう、設計 されている([RFC2045]、セクション2.2を見よ)。標準化された文字が矛盾し て変わらない限り、バージョン番号は、目的にかなわない。なぜなら、それ が知らない、最近割り当てられた文字を受け取るかもしれないが、このタグ からは何も得られないからだ。タグ自体は、いずれにせよ受け取られようと している新しい文字について何も教えてはくれない。 従って、それらの標準が両立してに発展する限り、バージョンを確認する ラベルを持つことの明白な利点は、明白であることそれのみである。しかし、 そのようなバージョン依存のラベルには欠点もある: 更に古いアプリケーショ ンが更に新しい未知のラベルを伴ったデータを受け取るとき、それはラベル を認識することができず、そして、全くデータを扱うことができないかもし れない。一方、一般的な既知のラベルは、データは大抵正しい処理 (新しい 文字は全く含まないだろうが)ができるだろう。 さて、「朝鮮語の混乱」(ISO/IEC 10646 改正5)は、上で示されたように、 原則としてはバージョンに依存しないMIME文字コード表ラベルの適切さと矛 盾する共存できない変更である。しかし、互換性の問題はUnicode 1.1(また は改正5の前のISO/IEC 10646と同等の)に従ってコード化された朝鮮語のハン グル文字を含むデータによってただ現われ得るが、まわりに悩むようなデー タは無い。これがまさしくこの共存できない変更が受け入れられると思われ た理由である。 実際上は、ラベルが改正5後の全ての説明を参照するために理解される限り、 そして共存できない変更が実際に発生しない限り、バージョン非依存のラベ ルは、保証される。もし共存できない変更がISO/IEC 10646の後の方のバー ジョンに存在するならば、ここで定義されたMIME charsetラベルが、IETFが 明確に別の方法で決定するまで、そして、IETFが明確に別の方法で決定しな い限り、前の説明と共に並べられる状態を維持するであろう。 ISO/IEC 10646(すなわち、修正5より前のコードポイント割り当てを用い て)の改正5を考慮せずにUTF-8にコード化されたハングル音節を含むテクス トデータを分類する排他的な目的のための文字コード表パラメータ値 "UNICODE-1-1-UTF-8" を登録することが同じく提案される。 一切ハングル音節を含まないUTF-8データに対しては、このラベルは【使 うべきではない】(SHOULD NOT)。そしてそれは、ISO/IEC 10646の改正5を考 慮せずに、あらゆる新しいハングルを含むデータも作成することに対し、 強く勧めることについて重要であると思われる。 6. セキュリティ対策 UTF-8 の実装者は、どのようにそれらが不正ななUTF-8文字列を扱うかとい うセキュリティ面を考慮する必要がある。いくつかの状況で、攻撃者が、 UTF-8構文により許されないオクテット列をそれに送り、不注意なUTF-8パー ザを利用することができることが想像可能である。 この攻撃の特に微妙なフォームは、UTF-8符号化されたその入力に対して 安全性調査を行なうパーザに対して実行され得る。しかしある不正なオクテッ ト列は文字と解釈される。例えば、パーザは、単一のオクテット列00として 符号化される時に、NUL文字を禁止できるが、不正な2オクテット連続C0 80 を誤って許し、それをNUL文字と解釈する。別の例は、オクテット列 2F 2E 2E 2F ("/../")を禁止するパーザであるにも関わらず、不正なオクテッ ト列2F 0C AE 2E 2Fを許してしまう。 謝辞 以下はこのメモの立案と議論に参加した: James E. Agenbroad Andries Brouwer Martin J. D|rst Ned Freed David Goldsmith Edwin F. Hart Kent Karlsson Markus Kuhn Michael Kung Alain LaBonte John Gardiner Myers Murray Sargent Keld Simonsen Arnold Winkler 参考文献一覧 [CHARSET-REG] Freed, N., and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998. [FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm. 22p. pbk. 172g. 4/95, X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preleminary Specification, Document Number P316. Also published in Unicode Technical Report #4. [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a technical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2. UTF-16 is described in Annex Q, published as Amendment 1. 17 other amendments are currently at various stages of standardization. [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045. N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046. K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048. N. Freed, N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049. All November 1996. [RFC2152] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe Transformation Format of Unicode", RFC 1642, Taligent inc., May 1997. (Obsoletes RFC1642) [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. 奥付 Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon Suite 600 Montreal QC H4M 2P2 Canada Phone: +1 (514) 747-2547 Fax: +1 (514) 747-2561 EMail: fyergeau@alis.com 著作権全文 Copyright (C) The Internet Society (1998). 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)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。