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