[3] Web の文字コード に関する参照処理モデル Reference Processing Model Unicode を用いて規定を定め、実際に使われている文字コード はその Unicode
の文字列を符号化 したものとみなす、というものです。
[4] 実装は必ずしもこのモデルに従う必要はありませんが、従っているかのように振る舞うことが求められています。
[5] このモデルは HTML 2.x (RFC 2070 ) で導入され、 HTML4 、CSS2 、ECMAScript 、DOM1 、
XML などその後の Web 関連技術に広がっていきました。
[10] 例えば HTML4 の SGML 文書文字集合 は ISO/IEC 10646 (≒ Unicode ) でした。
HTML文書 は UTF-8 でも UTF-16 でも Shift_JIS でも ISO-8859-1 でも構いませんが、
いずれにせよ Unicode に変換してから解釈される、とされていました。
[16] 現在の Web の文字コード に関する仕様である Encoding Standard
も、基本的にはこの方針の延長線上にあります。
参照処理モデルに従う仕様 [19] 明示的または暗示的に参照処理モデル に従っていた仕様には、次のものがありました。HTML 2.x HTML4 XML CSS2 JavaScript JSON
文字コードの種類 [20] 参照処理モデル に従う仕様は IANA charset によって文字コード の指定が行えるのが普通でしたが、
実際には IANA charset として登録されていないものも使われていました。
いずれにせよ、参照処理モデル としては文字コード の種類は限定されていませんでした。
[21] ただし概念上 Unicode として扱うという性質から、 Unicode
で表現できない文字 は扱うことができません。 (Unicode で表現できない文字 を含む文字コード を扱うことはできますが、
Unicode で表現できない文字 は U+FFFD
[22] より後の時代の仕様は文字コード を Unicode のみに限定していることがあります。
更に時代が下ると UTF-8 のみとするのが一般的になります。文字参照 [23] 参照処理モデル の確立以前は文字参照 の意味は曖昧でした。
たとえ仕様上何らかの意味が定められていたとしても、
それは便宜上たまたまそう記述されたといってよく、
実態を反映したものではありませんでした。
しかし参照処理モデル により、文字参照 は Unicode
における符号位置 を表していることが明確になりました。
[24] 90年代中頃には、実体参照 すら意味は曖昧で、Latin1 のつもりで使われた実体参照 がシフトJIS で同じバイト で表される半角カナ の意味で使われたり、表示されたりすることまでありました。
[25] HTML の文字参照 が Unicode の文字 を表すとされたのに対し、
URL のパーセント符号化 はバイト を表すとされ、
意味が分岐しました。文字コードの意味の変化 [8] 参照処理モデル は、既存の文字コード の意味を変化させました。従来の文字コード は、
含まれる文字 の集合も定義も、その符号化方式 も独自に定義していました。参照処理モデル はその独自の集合と定義を無視し、
どの文字コード もUnicode という単一の符号化文字集合 の符号化方式 の違いに過ぎないものと読み替えていきました。
[9] 例えば JIS X 0208:1997 は 0x89 0xA8 (に相当する JIS の区点位置 ) に
鴎 と鷗 とを包摂 していますから、 Shift_JIS の本来の定義からすると
0x89 0xA8 は鴎 でも鷗 でもある (文字コード では区別されない)
と解釈できます。
ところが
Unicode
の鴎 と鷗 はまったくべつのUnicode符号点 に割り当てられた異なる文字 です。
文字集合 Unicode および文字符号化方式 Shift_JIS の定義を組み合わせると
0x89 0xA8
に相当する Unicode文字 は鴎 です。
従って参照処理モデル に従う解釈では
0x89 0xA8 は鴎 でしかありません。
[28]
この意味で、
「JIS X 0208:1997 の規定するシフト符号化表現 」と
「参照処理モデル における
Shift_JIS 」 は別の文字コード とも解釈できます。
歴史 [6] 参照処理モデル の確立以前は、仕様は Latin-1 (ISO-8859-1 )
ベースに定義されていることが多く、
一方で実装はその動作するシステムの文字コード で実装されていて、
いくつかの文字コード の変換にも対応文字コード指定メニュー している、といった感じでした。
[17] 文書 はそれぞれの著者 の環境で表示確認されるため、
それぞれのシステムの文字コード が使われることとなり、
同一言語圏で複数の文字コード が使われている場合や、
他の言語圏の文書 を閲覧しようとした場合には文字化け が多発していました。
[11] 例えば日本語版 の Windows 95 で動作する Netscape Navigator 1 は、
シフトJIS (CP932 ) で実装されていました。EUC-JP や ISO-2022-JP
の表示にも対応していましたが、 ISO-8859-1 には対応しておらず、シフトJIS
として解釈されて半角カナ に文字化け しました。
[12] 当時の正式な仕様であった HTML 2.0 や HTML 3.2 は ISO-8859-1
を SGML 文書文字集合 としていましたが、
欧米ではそう実装されているだけ公式が勝手に言っているだけ であって、
実態とは異なっていました。 (日本語 その他欧米以外の文字コード は HTML 2.0
より前に既に広く用いられていました。)
[27] HTML 2.0 や HTML 3.2 では日本語文字を使えないという解釈が00年代初期に流行したことがありますが、
「HTML は SGML応用 である」という虚構と同様に、その時代の制約のもとでの標準化の限界と捉えるべきでしょう。[26] 現在の JavaScript /DOM は内部コード を UTF-16 としていますが、
初期の JavaScript はその Webブラウザー の内部コード 、
すなわちそのシステムの内部コード で動作していました。
[2] RFC 2070 - Internationalization of the Hypertext Markup Language
( (2014-02-02 16:11:39 +09:00 版))
http://tools.ietf.org/html/rfc2070#section-2.1 [13] 参照処理モデル が仕様化 >>2 90年代 末)
は実データの Unicode への統一はまだ現実的ではありませんでした。
仕様上は Unicode
が中心となっていましたが
(他に世界中の文字 を扱うための現実的な選択肢はありませんでした) 、
それに限定するには時期尚早すぎました。
[7] 90年代末には Windows が NT 系に移行してゆき、 UCS-2 /UTF-16
を内部コードにして W 系 Win32 API を使う実装が (Webブラウザー に限らず)
増えていきました。他のシステムでも同様に Unicode の普及が進み、
自然と参照処理モデル に沿った実装に収束していきました。
[1] Character Model for the World Wide Web 1.0: Fundamentals
( (2005-02-15 14:24:00 +09:00 版))
http://www.w3.org/TR/charmod/#def-ref-proc-model [18] W3C の I18N Core WG は後に charmod において改めて参照処理モデル を文書化しています
>>1
[14] 参照処理モデル から10年以上が経過して、 Webの文字コード はようやく Unicode
に収束しつつあります。2011年の Encoding Standard は新しいプロトコル や言語 に
UTF-8 の利用を義務付けています。
[15] この間、 IETF や W3C のポリシーは参照処理モデル → UTF-8 ・UTF-16
などに対応しないといけない (他もあってよい) → UTF-8 ・UTF-16 などに限定するべきと徐々に限定されていきました。
00年代後半になって UTF-32 が利用実態がないとして HTML で使用禁止になり、
UTF-16 もASCII互換 でないため Encoding Standard でレガシー符号化 に分類されています。