UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 2003年12月27日 / translation 27 December 2003 修正 2004年 1月22日 / correction 22 January 2004 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc3629 を訳者(marimo@wdic.org)が個人的な好奇心で適当に翻 訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。誤 訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要な 場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容について の指摘は、いつでも歓迎します。 以前訳したrfc2279がObsoletesされたため、rfc2279を元に翻訳しました。 rfc2279の翻訳に関してご指摘を頂いた高橋誠様に改めて深く感謝いたしま す。 Network Working Group F. Yergeau Request for Comments: 3629 Alis Technologies STD: 63 November 2003 Obsoletes: 2279 Category: Standards Track UTF-8, ISO 10646 を変換したフォーマット このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準運 用プロトコルを策定し、改善のための議論、提案を求めるものである。 規格化状態とプロトコルのステータスのために、この現在の版である「イ ンターネット公的プロトコル標準」(STD 1)も参照されたい。このメモの配 布は無制限である。 著作権について Copyright (C) The Internet Society (2003). All Rights Reserved. 摘要 ISO/IEC 10646-1は、世界の記述システムの殆どを含んでいるユニバーサル 文字セット(UCS)と呼ばれる大規模文字セットを定義する。しかし、UCSで提 案されたオリジナル符号は、多くの現行アプリケーションやプロトコルと互 換性がなく、これがUTF-8つまりこのメモの対象の開発をもたらした。UTF-8 は、完全なUS-ASCII範囲を保存しているため、US-ASCII値に依存しているファ イルシステム、パーザ、他のシステムに対し互換性を提供する特徴を有して いる。このメモはRFC2279を廃棄し、交換する。 目次 1. はじめに 2. 表記の慣習 3. UTF-8の定義 4. UTF-8バイトシーケンスの構文 5. 標準のバージョン 6. バイトオーダーマーク (BOM) 7. 例 8. MIME 登録 9. IANAへの配慮 10. セキュリティ対策 11. 謝辞 12. RFC 2279からの変更点 13. 参考標準一覧 14. 参考文献一覧 15. URIs 16. 知的所有権について 17. 奥付 18. 著作権全文 (訳注:本訳は都合上ページを振っていないので、上記のページ番号はす べて消した。読みづらい点はご容赦) 1. はじめに ISO/IEC 10646 [ISO.10646]が、世界の記述システムの殆どを含むユニバー サル文字セット(UCS)と呼ばれる大規模文字セットを定義する。同様の文字セ ットはUnicode標準 [UNICODE] により定義され、さらに実装者の大きな関心 の付加的な文字特性や他のアプリケーションの詳細を定義する。現在まで、 Unicodeの変化およびISO/IEC 10646への改正と追加分は、文字レパートリー とコードポイント割り当てが同期されるよう、相互に追跡した。関連規格化 委員会は、この非常に有益な同期を維持することを約束した。 ISO/IEC 10646とUnicodeは、それらの共通のレパートリーのいくつかの符 号化形態を定義する: UTF-8、UCS-2、UTF-16、UCS-4、そしてUTF-32。符号化 形態において、個々の文字は、1つ以上の符号化単位として表明される。 UTF-8を除く全ての標準のUCS符号化形態は、符号化単位より大きいオクテッ トを持っている。8または7ビット文字を仮定する多くの現在アプリケーショ ンとプロトコルにおいては使うのが難しい。 UTF-8つまりこのメモの対象は、1オクテット符号化単位を持っている。そ れはオクテットの全ビットを使うが、しかし完全なUS-ASCII [US-ASCII]範囲 を保存する品質を持っている: US-ASCII文字は、正常なUS-ASCII値を持つ1オ クテットにおいて符号化され、そして、その値を持つオクテットは必ず US-ASCII文字を表わし、他の文字にはならない。 UTF-8は、一定しない数のオクテットとしてUCS文字を符号化する。そして そのオクテットの数および各々の値は、ISO/IEC 10646の文字に割り当てられ た値によって変わる(文字数、別名コードポジション、コードポイント、また はユニコードスカラ値)。この変換フォーマットは以下の特徴を持っている (すべての値は16進で示した): o U+0000からU+007F (US-ASCIIレパートリー)までの文字は、00から7Fま でのオクテットと一致している(7ビットUS-ASCII値)。結果として、プ レーンASCII文字列は同じく正当なUTF-8文字列であるということであ る。 o US-ASCII値は、UTF-8符号化文字ストリームにおいて別の文字には使用 されない。これにより US-ASCII 値を解析し他の値は透過的に扱うファ イルシステムや、他のソフトウェア(例えば Cライブラリ中のprintf() 関数)の互換性が保たれる。 o UTF-8と他の符号化フォームの間の相互変換は容易である。 o マルチオクテット列の最初のオクテットは、後続するオクテットの数を 示す。 o オクテット値にC0、C1、F5からFFまでは決して出現しない。 o 文字の境界は、オクテット列のどこからでも容易に見つけられる。 o 文字番号によって命令されたかのように、UTF-8文字列のバイト値の辞 書順ソート順序は、同じである。もちろん、文字番号に基づくソート順 序は文化的には殆ど正当ではないので、これは限られた関心である。 o Boyer-Moore高速検索アルゴリズムはUTF-8データによって使われうる。 o UTF-8 文字列は、それ自体が単純なアルゴリズムででもかなり確実に認 識できる。すなわち、他の符号化における文字列で有効なUTF-8に見え る確率は低く、文字列が長くなるとその確率はさらに減少する。 UTF-8は、1992年9月に、Plan9オペレーティングシステムで使用可能なUCS 変換フォーマットを定義することを目的とし、ケン・トンプソンにより、ロ ブ・パイクによって指定された設計基準によって導かれた破壊的ではない方 法で考案された。トンプソンの設計は、名前FSS-UTF(FSS/UTFの変形)、UTF-2 を持つX/Openジョイント国際化グループXOJIG([FSS-UTF]を参照)、及び、最 終的に方法に沿ったUTF-8によって標準化を務められた。 2. 表記の慣習 この文書内のキーワード "MUST"(必須), "MUST NOT"(禁止), "REQUIRED" (必要), "SHALL"(すること), "SHALL NOT"(しない), "SHOULD"(すべき), "SHOULD NOT"(すべきでない), "RECOMMENDED"(推奨), "MAY"(推定), そして "OPTIONAL"(オプション)は、[RFC2119]で説明されるよう解釈される必要があ る。 UCS文字は、HHHHが、ISO/IEC 10646の文字数を表している4から6までの16 進法の文字列であるU+HHHH表記法により明示される。 3. UTF-8の定義 UTF-8はUnicode標準 [UNICODE] により定義される。また、説明と式は ISO/IEC 10646-1 [ISO.10646]の付録Dで見つかるだろう UTF-8において、U+0000..U+10FFFF範囲(UTF-16アクセス可能範囲)からの文 字は、1から4までオクテットの連鎖を使って符号化される。 1オクテット長の場合、その「シーケンス」の唯一のオクテットは、最上 位ビットは 0 がセットされており、残りの 7ビットは文字値を符号化する ために用いられる。 nオクテットのシーケンス(n>1)は、最初のオクテットの最上位nビットに は1をセットし、次に一つの0のビットをセットする。そのオクテットの残っ たビットは、コード化される文字の値のビットを含んでいる。 続くすべてのオクテットは、最上位ビットに1が設定されており、そして、 次のビットが0にセットされ、残る6ビットでキャラクタをエンコードする。 下のテーブルは、これらの幾つかのオクテットタイプのフォーマットを要 約する。文字xは、文字番号のビットを符号化するために利用可能なビット を示す。 文字番号範囲 | UTF-8 オクテット列 (16進数) | (2進数) --------------------+--------------------------------------------- 0000 0000-0000 007F | 0xxxxxxx 0000 0080-0000 07FF | 110xxxxx 10xxxxxx 0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx UTF-8への文字の符号化は、以下のとおりに続く: 1. 上記のテーブルの文字値から必要なオクテットおよび最初のカラム番 号を決定すること。テーブルの列が相互に排他的であること。すなわ ち、与えられた 文字を符号化するのにただ 一つだけ有効な方法があ ることに注意することが重要である。 2. テーブルの2番目のカラムに従ってオクテットの最上位ビットを準備す ること。 3. バイナリにおいて表現された文字数のビットからビットマークxを埋め てください。最初に文字番号の下位ビットをシーケンスの最終オクテッ トの下位ビットに入れ、そして、文字番号の次のより高位ビットをそ のオクテットなどの次のより高位の位置に入れ、最後のオクテットの xビットが埋められる時には次に進み、そして最後の手前のオクテット という順で埋めていきすべてのxビットを埋めるまで続ける。 UTF-8の定義は、U+D800からU+DFFFの符号化文字番号を禁止し、UTF-16では 符号化(サロゲートペア)での使用のために確保され、文字を直接表していな い。UTF-8においてUTF-16データから符号化する時には、まずUTF-16データを 解読することが、前述の説明のようなUTF-8において、その時符号化される文 字数を得るのに必要である。これは、CESU-8 [CESU-8]というインターネット 上での使用を想定していないUTF-8風符号化とは対照的である。CESU-8は、 UTF-8と同様に働く。しかし、文字番号(コードポイント)の代わりにUTF-16 コード値(16ビット量)を符号化する。これは0xFFFFを越える文字番号のため の異なる結果につながる; それらの文字のCESU-8符号化は、正当なUTF-8【で はない】(NOT)。 UTF-8文字の復号は、次のとおりに続く: 1. バイナリ数をの全ビットを0で初期化する。最高21ビットが必要となる かもしれない。 2. どのビットが上記のテーブルの連続するオクテットの数からの文字番 号および2番目のカラムを符号化するかを決定する(ビットはxをマーク した)。 3. UCS-4 文字のシーケンスからビットを分配する。まず、最初の連続の 最後のオクテットからの下の上位のビット、さらに、xビットが全く残 されなくなるまで、左に進む。バイナリの数は現在文字数と等しい。 解読アルゴリズム上記の実装は、無効シーケンスを解読することに対して 保護【しなければならない】(MUST)。例えば、純粋な実装は、無駄に長い UTF-8シーケンスC0 80を文字U+0000に、または、サロゲートペア ED A1 8C ED BE B4をU+233B4へと復号するかもしれない。解読不可能なシー ケンスはセキュリティ問題や他の問題を起こすかもしれない。下記セキュリ ティ対策(セクション10)を見よ。 4. UTF-8バイトシーケンスの構文 ABNFを使う実装者の利便のため、ここでABNF構文におけるUTF-8の定義を行 なう。 UTF-8文字列は、一連のUCS文字を表わす一連のオクテットである。もしそ れが以下の構文とマッチしているならば、オクテットシーケンスは有効な UTF-8であり、UTF-8を符号化するための規則から導かれ、[RFC2234]のABNFに おいて表現される。 UTF8-octets = *( UTF8-char ) UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-1 = %x00-7F UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail ) UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail ) UTF8-tail = %x80-BF 注意 -- UTF-8の威厳ある根本的な定義は[UNICODE]にある。この文法は、 Unicodeが示すことと同じことについて述べると考えられている。しかし、 権威は主張しない。実装者はは、このABNFよりむしろ権威あるソースに頼 るよう促すものである。 5. 標準のバージョン ISO/IEC 10646は、時々改正や追加などが発表され更新される; 同様に、 Unicode標準の新バージョンも追って発表される。個々の新バージョンは前の ものを廃棄し交換するが、しかし実装や、かなりの重要なデータはすぐには 更新されないだろう。 一般に、変更は、過去のデータについての特定の問題を引き起こさない新 しい文字を追加することである。1996年に、ISO/IEC 10646とUnicode 2.0の 1993年版の改正5により、朝鮮語のハングル領域は移動した。従って、ハング ル文字を含むどのような過去のデータでも新バージョンの下では無効である。 Unicode 2.0はUnicode 1.1と同じ違いを持っている。そのような非互換の変 更を許すための理由は、ハングルを含む主要な実装および重要なデータが全 くなかった、ということだった。その事件は「朝鮮語の混乱」と称され、そ して、関連委員会で、そのような共存できない変更が再び行なわれないよう、 誓約された(Unicode Consortium Policies [1]を見よ)。 MIME登録(セクション8)で論じられるように、新バージョン、及びあらゆる 共存できない変更は、MIME charsetラベルによって表現される。 6. バイトオーダーマーク (BOM) "ZERO WIDTH NO-BREAK SPACE" というUCS文字U+FEFFは、また「バイトオー ダーマーク」(略してBOM)として非公式に知られている。この文字は、本来は テクスト内の "ZERO WIDTH NO-BREAK SPACE" として使われうるが、BOMの名 は文字の2番目の可能な慣習を暗示する: UCS文字列の先頭のU+FEFF文字は、 "signature" である。 そのような連続したストリームの受信者は、その時、UCS符号化に関係し、 符号化がオクテットの並び順を認識するための方法としてマルチオクテット 符号化単位を持っている、そんなストリームがUCS文字から成り、かつまた認 識するためのヒントに、最初の文字を使うかもしれない。 ストリームの最初を除き、どのような位置に出現した文字U+FEFFも zero-width non-breaking spaceとして解釈【されねばならず】(MUST)、それ をシグネチャとして解釈【してはならない】(MUST NOT)。シグネチャとして 解釈される場合は、テクストを処理する前に、先頭のU+FEFF文字が取り除か れることをUnicode標準は示唆している。 そのような除去が場合(例えば二つの文字列を連結するとき、接続地点で結 果として生じた文字列が意図せず "ZERO WIDTH NO-BREAK SPACE" を含んでい るかもしれない)によっては必要であるけれども、ストリームの全ての文字の 存在に依存している違う層(文字のディジタル署名や計算など)で外部のプロ セスに影響するかもしれない。従って、正当な理由のないシグネチャと解釈 された最初のU+FEFFを除去することを回避し、適切である(表示用などの)と き、それを除去にする代わりにそれを無視し、そして本当に必要である時の み、それを除去するということが【勧められている】(RECOMMENDED)。 ストリームの先頭のU+FEFFは、zero-width non-breaking spaceとも解釈可 能で、常にシグネチャで【あるとは限らない】(MAY)。この不確実性を減少す るための試みにおいて、Unicode 3.2 は、シグネチャ機能を除いてU+FEFFと 同等の意味を持ち、使うことができる新しい文字、U+2060 "WORD JOINER" を 追加し、そして、文字結合する語義を表明する際にその専用を強く推薦して いる。結果として、この推薦に従うことにより、あらゆる最初のU+FEFFが意 図した "ZERO WIDTH NO-BREAK SPACE" ではなくシグネチャであるということ を確実にできるだろう。 その間、不確実性は不幸にも残り、そしてインターネットプロトコルに影 響を及ぼすかもしれない。プロトコル仕様は、この不確実性の潜在的な悪い 効果を減少、もしくは取り除くために、シグネチャとしてのU+FEFFの使用を 制限する【かもしれない】(MAY)。そのような制限の利点(不確実性の縮小)、 および欠点(シグネチャ機能の損失)の妥協点を見いだすために、幾つかのケー スを区別することが有益である: o プロトコルはが常にUTF-8であるなら、そのような場合シグネチャ機能 は完全に無駄であるので、そのプロトコルが命令するそれらの原文のプ ロトコル要素のためのシグネチャとしてU+FEFFの使用を禁止【すべき】 (SHOULD)である。 o プロトコルは、それらの原文のプロトコル要素、プロトコルの実装が常 に適切にメカニズムを使う立場にあることが予測されるとき、そのプロ トコルが文字符号識別メカニズムを供給するためのシグネチャとしての U+FEFFの使用を同じく【禁じるべき】(SHOULD)である。これは、プロト コル要素がそれらの作成時からそれらの適切に分類される伝送の時間ま で実装の制御下にきつく維持されるケースであろう。 o 禁止が不可能、あるいはプロトコルの実装がメカニズムを常に適切に使 う立場にないことが予測される時には、プロトコルは、文字符号化識別 メカニズムを提供しないそれら原文のプロトコル要素のためのシグネチャ としてU+FEFFの使用を禁じる【べきではない】(SHOULD NOT)。後者2ケー スでは、特にプロトコルの実装が、そのような要素を、ファイルシステ ム、ペイロード(FTPなど)のための符号化識別メカニズムを持たないプ ロトコル、または文字符号化の適切な識別を保証しない他のプロトコル から得る時のMIME要素(HTTPなど)など、より大きいプロトコル要素で起 こりそうだ。 プロトコルが一定のプロトコル要素のためのシグネチャとしてU+FEFFの使 用を禁じる場合は、そのプロトコル要素のどのような先頭のU+FEFFでも "ZERO WIDTH NO-BREAK SPACE" と解釈【されねばならない】(MUST)。プロト コルがあるプロトコル要素のためのシグネチャとしてU+FEFFの使用を【禁じ ない】(NOT)ときには、実装は、その要素においてシグネチャを扱い、そして 適切に反応する準備ができて【いるべき】(SHOULD)である: 必要な文字符号 化および適切なシグネチャの除去や無視を識別するため、シグネチャを用い る。 7. 例 "A." という文字列U+0041 U+2262 U+0391 U+002Eは、UTF-8において次の通り符号化される: --+--------+-----+-- 41 E2 89 A2 CE 91 2E --+--------+-----+-- 文字列 U+D55C U+AD6D U+C5B4 (朝鮮語 "hangugeo"、「朝鮮語」を意味す る)は、UTF-8において次の通り符号化される: --------+--------+-------- ED 95 9C EA B5 AD EC 96 B4 --------+--------+-------- 文字列 U+65E5 U+672C U+8A9E (日本語 "nihongo"、「日本語」を意味する) は、UTF-8において次の通り符号化される: --------+--------+-------- E6 97 A5 E6 9C AC E8 AA 9E --------+--------+-------- 文字 U+233B4 (「木の切り株」を意味する漢字)がUTF-8 BOMを伴う場合、 UTF-8において次の通り符号化される: --------+----------- EF BB BF F0 A3 8E B4 --------+----------- 5. MIME 登録 [RFC2978]によると、このメモはUTF-8のためのMIME charsetパラメータの 登録のための基礎として役立つ。charsetパラメータ値は "UTF-8" である。 この文字列は、少なくとも1993年版(朝鮮語領域)の改正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が明確に別の方法で決定しな い限り、前の説明と共に並べられる状態を維持するであろう。 9. IANAへの配慮 IANA文字コード表登記におけるUTF-8のためのエントリは、このメモを指し 示すために更新された。 10. セキュリティ対策 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を許してしまう。この最後の方法は、実際に2001年の間 の広範囲に及んだWebサーバ攻撃ウイルスにおいて使われた; 従って、セキュ リティ面で現実の驚異である。 別のセキュリティ問題は、UTF-8に符号化する際に起こる: UTF-8のISO/IEC 10646定義により、文字番号最大U+7FFFFFFFを符号化すると、最大で6バイト のシーケンスが作られる。従って、もし文字数の範囲がU+10FFFFに明示的に 制限されないか、または、バッファサイズ制限により5あるいは6バイトシー ケンスの可能性が考慮されないならば、バッファオーバフローのリスクがあ る。 セキュリティは、同じくUTF-8を含むいくつかの文字符号化の特性に潜んで いるかもしれない: 「同じもの」(利用者が話せるくらい遠く)は、いくらか の明白な文字列で表され得る。例えば、鋭アクセントを持つeは、従来からの U+00E9 E ACUTE文字、または正統的に等しいシーケンスU+0065 U+0301で表さ れているかもしれない(E + 連結用ACUTE)。例えUTF-8が単一バイト列を個々 の文字列に提供しても、文字列一致調査、索引、検索、分類、正規表現との 一致調査、および選択に関係する時には、いつでも「同じもの」のための複 数の文字列の存在が、セキュリティ問題を持っている。例として、証明書と アクセス制御リストエントリに出現する識別子の文字列一致調査である。こ の問題は、Unicode標準化フォームに基づく解決策に従順である。[UAX15]を 見よ。 11. 謝辞 以下が、このメモの立案と議論に参加した: James E. Agenbroad, Harald Alvestrand, Andries Brouwer, Mark Davis, Martin J. Duerst, Patrick Faltstrom, Ned Freed, David Goldsmith, Tony Hansen, Edwin F. Hart, Paul Hoffman, David Hopwood, Simon Josefsson, Kent Karlsson, Dan Kohn, Markus Kuhn, Michael Kung, Alain LaBonte, Ira McDonald, Alexey Melnikov, MURATA Makoto, John Gardiner Myers, Chris Newman, Dan Oscarsson, Roozbeh Pournader, Murray Sargent, Markus Scherer, Keld Simonsen, Arnold Winkler, Kenneth Whistler and Misha Wolf. 12. RFC 2279からの変更点 o 文字の範囲を0000-10FFFFに限定した (UTF-16アクセス可能範囲)。 o 文字参照としてISO/IEC 10646を保持するUnicodeをUTF-8の標準の定義 のソースにした o 用語を解決した。UTF-8は、文字番号の符号化フォームに関してそのと き述べた。UCS-2とUCS-4はほぼ消滅した。 o 標準のMUST NOTへの無効のシーケンスの復号に対する警告を覚え書きに まわした。 o プロトコルの助言をする、UTF-8 BOMについての新セクションを追加し た。 o 提案されたUNICODE-1-1-UTF-8 MIME charset登録を削除した。 o 有効なUTF-8オクテット列のためのABNF構文を追加した。 o セキュリティ対策セクションがUnicode標準化の衝撃の詳細で拡張され た。 13. 参考標準一覧 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 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". [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 4.0", defined by The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), April 2003, . 14. 参考文献一覧 [CESU-8] Phipps, T., "Unicode Technical Report #26: Compatibility Encoding Scheme for UTF-16: 8-Bit (CESU-8)", UTR 26, April 2002, . [FSS_UTF] X/Open Company Ltd., "X/Open Preliminary Specification -- File System Safe UCS Transformation Format (FSS-UTF)", May 1993, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000. [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: Unicode Normalization Forms", An integral part of The Unicode Standard, Version 4.0.0, April 2003, . [US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. 15. URIs [1] 16. 知的所有権について The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 17. 奥付 Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon, bureau 600 Montreal, QC H4M 2P2 Canada Phone: +1 514 747 2547 Fax: +1 514 747 2561 EMail: fyergeau@alis.com 18. 著作権全文 Copyright (C) The Internet Society (2003). 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 assignees. 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)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。 謝辞 RFC編集作業への出資は現在、インターネットソサエティによって提供され ている。