UTF8はUTF16を算術演算して一定のコード範囲に収めるようにした文字コードである、らしい。
実際のところ、以下の5つパターンに収束する。
(1)c2~df+80~bf 2バイト
(2)e0~ef+80~bf+80~bf 3バイト
(3)f0~f7+80~bf +80~bf +80~bf 4バイト
(4)f8~fb+80~bf +80~bf +80~bf +80~bf 5バイト
(5)fc~fd+80~bf +80~bf +80~bf +80~bf +80~bf 6バイト
UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00~0x7eなので、重複部がないからである。
SHIFT-JISは
第1バイトは
(あ)0x80~0x9f
(い)0xe0~0xef (JISのどの水準までサポートするかで変化することがある)
第2バイトは
(A)0x40~0x7e
(B)0x80~0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。
また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
0xa0(0xa1)~0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない。
そういう状況でのUTF8とSHIFT-JISの識別の仕方。
前から順に読んでいって、上記(3)~(5)のパターン、すなわち0xf0~0xfdが出てきたらUTF8で即確定できる。
逆に、(あ)が出てきたらSHIFT-JIS。UTF8では(あ)のコードはいきなり出てこないから。
0xa0~0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
(1)と(2)
である。この部分の完全な判別はできない。
しかし、確率論的には推測できる。
(2)のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。
残りは(1)。
0xc2~0xdfは半角カタカナと重複するからここだけでは判別できない。
2バイト目が0x80~0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。
ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。
X−BASIC for iOSではコード範囲を限定しているので、全自動。
0 件のコメント:
コメントを投稿