[3] Web の文字コードに関する参照処理モデルとは、 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 も、基本的にはこの方針の延長線上にあります。
[20] 参照処理モデルに従う仕様は IANA charset によって文字コードの指定が行えるのが普通でしたが、 実際には IANA charset として登録されていないものも使われていました。 いずれにせよ、参照処理モデルとしては文字コードの種類は限定されていませんでした。
[21] ただし概念上 Unicode として扱うという性質から、 Unicode
で表現できない文字は扱うことができません。 (Unicode で表現できない文字を含む文字コードを扱うことはできますが、
Unicode で表現できない文字は U+FFFD
などに対応付けられているものとみなすことになります。)
[23] 参照処理モデルの確立以前は文字参照の意味は曖昧でした。 たとえ仕様上何らかの意味が定められていたとしても、 それは便宜上たまたまそう記述されたといってよく、 実態を反映したものではありませんでした。 しかし参照処理モデルにより、文字参照は Unicode における符号位置を表していることが明確になりました。
[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 より前に既に広く用いられていました。)
[26] 現在の JavaScript/DOM は内部コードを UTF-16 としていますが、 初期の JavaScript はその Webブラウザーの内部コード、 すなわちそのシステムの内部コードで動作していました。
[13] 参照処理モデルが仕様化 >>2 された当時 (90年代末) は実データの Unicode への統一はまだ現実的ではありませんでした。 仕様上は Unicode が中心となっていましたが (他に世界中の文字を扱うための現実的な選択肢はありませんでした)、 それに限定するには時期尚早すぎました。
[7] 90年代末には Windows が NT 系に移行してゆき、 UCS-2/UTF-16 を内部コードにして W 系 Win32 API を使う実装が (Webブラウザーに限らず) 増えていきました。他のシステムでも同様に Unicode の普及が進み、 自然と参照処理モデルに沿った実装に収束していきました。
[18] W3C の I18N Core WG は後に charmod において改めて参照処理モデルを文書化しています >>1。
[14] 参照処理モデルから10年以上が経過して、 Webの文字コードはようやく Unicode に収束しつつあります。2011年の Encoding Standard は新しいプロトコルや言語に UTF-8 の利用を義務付けています。