[22]
Unicode は制御文字やエスケープシーケンスに関係して上位層プロトコルという語を使っています。
... で構成されます。
[11] 8ビット符号がバイト [ 0, 255 ] と文字の写像であることは第一級の符号化文字集合と同じです。
[12] ところが第一級の8ビット符号の実装とは違ってフォント依存符号化は応用やプラットフォームが直接支援するものではないため、 他の第一級の8ビット符号で代用されます。ほとんどの場合はそれが windows-1252 です。ここでは windows-1252 の符号化文字は重要ではなく、 それがバイトと Unicode符号位置の写像であることだけが意味を持ちます。
[13] 実際にファイルとして保存される HTML や RTF などの文書形式のデータは、 windows-1252 に従ったバイト列で構成されており、必要に応じて文書形式によって定義される Unicode符号位置を表すエスケープ表現を含むことがあります。
[14] 応用の内部では、これらのデータはUnicode符号位置の列として保持されます (参照符号化モデル)。 ただし、この Unicode符号位置はあくまでバイトの表現であり、 本来の Unicode文字の意味で使われているものではありません。
[15]
応用はフォントを使って文字を表示します。フォント依存符号化の一般的な
TrueType フォントは、実際には8ビット符号ではなく、
Unicode符号位置からグリフへの写像の集合 (cmap) です。
[16] つまりフォント依存符号化は第一層として windows-1252 がバイトとバイトたるUnicode文字の対応関係を定め、 第二層として当該符号がバイトたるUnicode文字と文字との対応関係を定める2階層の構造であり、 しかも第一層の結果はただの文字列ではなく文書形式に依存する構文や escape を含んでいることがあります。
[19] 二階建ての8ビット符号と同様の要領で多バイト符号が使われることがあります。
[20] 8ビット符号の場合と違って第二層は EUC-CN や Big5 や EUC-KR などの一般的な多バイト符号のことが多いです。
[21] 欧米や東南アジアのような東アジア以外で20世紀末から21世紀初頭 (平成時代前半) 頃に使われた著述ソフトウェア (Webサイト提供サービス付属のものを含みます。) が生成した HTML文書でこの種のものがちらほら見られます。
[24]
フォント依存符号化では HTML (font) や HTML + CSS (font-family)
や RTF や各種ワープロの文書形式などが、
フォント名の指定を通して実質的な文字コードの切り替え機能を持った一種の
container format として使われます。
[25]
フォント依存符号化が多く使われた地域や言語の文字コードの変換の実装では、
こうした形式が文字コードの種別と組み合わさった入出力の不可分の性質として扱われることがあります。
本来 HTML はただのテキストファイルですが、
タグ等が文字コードの切り替え機能を持った複合的な構造として扱う必要があるのです。
[26] 特に重要になるのは、
のような状況を扱わなければならないことです。
[31] HTML + CSS のように外部ファイルにフォント情報が分離されていることもあるので、 注意が必要です。
... が考えられ、それぞれ実装手法や配慮するべき点が異なってきます。
[37]
最下層は windows-1251, UTF-8, Shift_JIS などと判定する必要があります。
HTTP charset="" や HTML <meta charset>
などで適切に指定されている場合は問題になりません。 RTF
のように文書形式から確定できる場合も問題になりません。
x-user-defined も参照。[38] 問題は適切な文字コードの指定がないときで、頻度解析等の手法によって決める必要が出てきますが、 文字の出現頻度を使った通常の推定手法で windows-1252 や Shift_JIS だと判定するのは困難な場合が多いです。
[40] 主要なフォント依存符号化の上層符号の出現頻度等には個別に対応してもいいのかもしれませんが、 すべてのフォント依存符号化に予め対応しておくのは困難です。
[41]
<font face> によって既知のフォント依存符号化のフォント名の指定がある場合が多いので、
これを prescan 同様の方法で検出し、その場合は windows-1252 と判定することでほとんどは対応可能です。
[42]
CSS で指定されている場合は難度が上がります。外部CSSでの指定だと、アーキテクチャー的に判定に利用不能なことも多いと予想されます。
幸い CSS でフォントが指定されているような比較的新しい文書だと
iso-8859-1,
windows-1252,
x-user-defined,
utf-8
のような
charset の指定が入っていることが多く、
頻度解析等の手法による推定は不要かとも思われますが、
十分な量の事例を収集した研究が必要です。
[43] windows-1252 の文字が文字実体参照や数値文字参照で記述された HTML文書がその実、フォント依存符号化の8ビット符号だったり、 多バイト符号だったりすることが、 アジアではよくあります。
[44] フォント名が明示されたフォント依存符号化ならフォントを頼りに判定すれば良いのですが、
だったりすることがあります。 >>45 は特に <font face> が一般化する前の古い時代の文書に見られます。
[47] こうしたものは文字参照を復号したバイト列に対して文字コードの判定の処理を行って本来の文字コード情報を補う必要があります。
[48]
UTF-8
でビルマ文字が使われている場合、
フォント依存符号化
(主に Zawgyi)
かどうかを判定する必要があります。
[49] HTML などフォント名が明示されていればそれを頼りに判定すれば良いのですが、 SNS や動画サイトなどでは専用フォントが指定されておらず、 投稿者や時代によって違うことがあります。
[50] また、 Zawgyi は外部CSSによるフォント指定が一般化した時代に入ってからも非常によく使われていたので、 HTML文書自体にはフォント情報が入っていないことも多いので注意が必要です。 動的な内容であることも考えられます (>>51)。
[51] フォント依存符号化の文字は、 静的な HTML文書に記述されているものだけとは限りません。 JavaScript の DOM 操作によって挿入される文字列のことがあります。
[52] このため一般の HTML文書の文字コードの判定と文字コードの変換の処理はテキストファイルとしての HTML ソースコードに対して行うのではなく、 Webブラウザーで表示されているある瞬間の DOM木に対して行う必要があります。
[53] ひとくちに外字といっても多種多様なものがあります。
[54] ところが外字にはフォントの指定がないことがほとんどで、 内字の補充という性格上1つの文書中にごくわずかにしか含まれないことが多く、 判定の難易度はかなり高いです。
[55]
外字は Web 上でひっそりながら相当数流通している
[56] 分野によってよく使われており、判定能力があると良さそうなもの: