符号構造に基づく判別 [231]
文字コードの判定 の基礎的な技法の1つが符号構造 を利用するものです。
[58]
平成時代 中頃までの古典的な方法では、
文字符号化 によって符号 の構造が異なることを利用し、
ある文字コード 体系で出現する符号 かそうでないかという構造的知識を主に使っていました。
しかしこの方法単独では符号 構造が重複する領域で互いの区別が付きづらく、
あまり精度が上げられませんでした。
ただ、実装が容易ではあるので、幅広く用いられましたし、現在でも使われることは珍しくありません。
[59] 例えばシフトJIS と日本語EUC は第1バイトに使われるバイト 、
第2バイトに使われるバイト の範囲がそれぞれ違っていますので、
その範囲に収まるかによってどちらか判断できることが多いです。
しかし完全に重なる部分もあるため、そのような符号 ばかりだと正しく判定できません。
[60]
また、半角カタカナ を利用すると両者の重なる領域が著しく増えるため、
誤判定が多くなり、頻繁に半角カタカナ の文字化け を目にすることになります。
これは半角カタカナ が嫌われる大きな要因の1つにもなっていました。
[334]
多バイト符号 の判定では符号構造 を理解し区別することが基礎となります。
[336]
ただし各符号 の構造は共通の部分もありますから、完璧ではありません。
[339]
特に
EUC-JP ,
gb18030 (= EUC-CN ),
EUC-KR (= UHC )
はいずれも EUC を採用しているので、基本的な文字が収容される CS1
が同一の構造となっています。
[337]
また、 EUC-JP の2バイト文字の少なくない数が、 Shift_JIS
の1バイト文字 (半角カナ ) 2つ分に当たります。
[338]
こうした同一部分は判定に使えません。
同一部分を除いた残りの固有部分で、どの符号 かがわかります。
ところが基本的な文字が同一構造の部分にあると、
固有部分が文字列 に含まれているとは限らないので、
判定できないことになります。
[340]
狭義の構造だけで判断できなくても、
空き領域で判断できることがあります。
2バイト符号 には使われていない領域も多いですが、
各符号 で少しだけ空きの範囲が違います。
空きが含まれていれば、その符号 は候補から除外できます。
[341]
ただし、空き領域が外字 として利用されてきた歴史があることには注意が必要です。
空き領域が出現したからといってただちに除外すると、正解も除外されてしまうおそれがあります。
[335]
1バイトの7ビット符号 や8ビット符号 の判定では、
符号平面 のほとんどのビット組合せ に有効な文字 が割り当てられてしまっているため、
符号構造 とその利用からの判断の余地はそれほど大きくありません。
[342]
それでも一部の符号 には空き領域があるので、それが出現すれば、
その符号 は候補から除外できます。
[343]
1バイトの8ビット符号 の CR や多バイト符号 の1バイトの未使用のビット組合せ は、
基本的には使用されていません。極稀に外字 等で利用されることがあるものの、
Web 等で流通するデータに利用されることはまずないと考えられます。
これらは多バイト符号 の先頭バイトに使われる領域なので、
当該多バイト符号 以外を除外する条件として使えます。
[344]
0x7F も条件は近いのですが、ほとんどの符号 で使われておらず、
多バイト符号 の1バイト目にも2バイト目にもまず出現しないので、
どう扱ってもかわりありません。
[345]
CL のうち、空白 等
([ 0x09 , 0x0D ], 0x1A )
と
ISO/IEC 2022 で使う制御機能
(0x1B , 0x0E , 0x0F )
を除いた部分も、通常の文字列 に出現することはまずありません。
[347]
これらも、
ASCII
の系譜の文字コードの判定 にはほとんど関与しません。
[348]
ただし、
VISCII
等では図形文字 を割り当てていること、
OEMコードページ では図形文字 を呼び出すために使われたこと、
には注意が必要です。
[346]
文字コードの判定 の実装の中にはバイナリー という判定結果を返すことができるものもあります。
この領域が出現し、 VISCII , UTF-16 等でないなら、バイナリー と判断できます。
[349]
文字コードの判定 の実装がバイナリー をどう扱うかは悩ましい問題です。
用途と実装戦略次第のところではありますが、明らかに文字列 ではないバイト列 の処理を延々と続けても仕方がないと考えると、
バイナリー 、あるいは「結果無し/不明」という回答を用意して、
それが確定的になれば早々に処理を打ち切るという選択肢もあることでしょう。
[78]
対応している符号化 を順番に試してエラーにならなかったものを採用するというだけ の実装を
「文字コードの判定」だと称しているものがたまにあります。
このような方法は符号構造 がまったく違う符号 の区別になら使えますが、
多くの8ビット符号 の区別が不可能です。
[257]
このような原始的な手法では
Shift_JIS と EUC-JP の区別すら完全にはできないことが日本 では古くからよく知られています。
[79] 符号構造 が限定される場合なら、その限定される特徴で判定したほうが高速かつ確実なことが多いので、
この手法が役に立つことはほぼないといっていいでしょう。UTF-8 [129]
UTF-8 はかなり確実に判定できることが知られています。
頻度解析等の手法
[288]
UTF-8 の2バイト以上のバイト列 が含まれ、それ以外に非ASCII文字 が含まれないなら、
UTF-8 と判定してほぼ間違いありません。
[285]
ただし8ビット符号 の領域を使っている以上誤判定の可能性が皆無ではありません。
[287]
ced は4種類の2バイト列を UTF-8 ではなく windows-1252
に加重する例外条件を持っています。 >>286
[286]
compact_enc_det /compact_enc_det/compact_enc_det.cc at master · google/compact_enc_det · GitHub2025-11-24T08:13:14.000Z https://github.com/google/compact_enc_det/blob/master/compact_enc_det/compact_enc_det.cc#L83 BOM [1]
Web では歴史的事情 により BOM の存在がかなり重視されています。
encoding sniffing algorithm
[57]
BOM に対応した仕様や実装でも、どの文字符号化 の BOM を検知するかはかなりブレがあります。
現在の Web は UTF-16 と UTF-8 に限定しています。
過去の Web や Web 以外の実装はそれ以外にもいろいろなものに対応していたり、
いなかったりします。
[132]
BOM
による検知は常に適用できるものではなく、使わない場合もあります。
例えばファイル 全体ではなくプロトコル要素 として用いられる文字列 片では
BOM が認められていない場合が一般的であり、その場合たとえ BOM
のように見えたとしてもそれは本来の文字列 の先頭です。
文字コード の判定には使えません。
[133]
ZIPファイル のファイル名 の文字コードの判定 では
BOM
検査を行いません。
ISO/IEC 2022 指示シーケンス [355]
ISO/IEC 2022 の指示シーケンス は自己識別的に符号化文字集合 を特定する情報を含んでおり、
文字コードの判定 上極めて重要です。
[356]
ただし実務上いくつか注意が必要です。
[357] ESC が含まれていることだけで ISO/IEC 2022 と判定するのは危険です。
CSI のために使っているもの、
ISO/IEC 2022 と異なる非標準の用法、
破損データなどの場合も想定する必要があります。[358] ISO/IEC 2022 の中にも
ISO-2022-JP など完全に自己記述的な指示シーケンス を含む符号 と、
そうでない符号 があります。
前者なら指示シーケンス を決定的根拠とできますが、
後者は追加の情報がないと確定できません。[359]
具体的には次のような符号 に特に注意が必要です。[360]
IE が対応していた ISO-2022-JP とシフトJIS
の混合文字コードの混合 など
ISO-2022-JP [361]
ISO-2022-JP に8ビット符号 としてまたは SI /SO
により半角カナ を追加した独自仕様の符号 [362]
ISO-2022-JP やシフトJIS に ESC
を使った独自構文で絵文字 を追加した符号 [363]
汎用機 等で使う ESC を使った独自構文で漢字 と JIS X 0201
を区別する符号 [364]
大韓民国 でよく流通していたという指示シーケンス の無い ISO-2022-KR [365]
ANSIエスケープシーケンス を含んだソースコード やバッチファイル など[366] 私用 の終端バイト Fp
や一部端末 の非標準の終端バイト の指示シーケンス を使った符号
指示シーケンス , Fp
は、
それが何を表すのか判定が必要になる場合があります。[367] 公開データとして流通しているものは Mule 系の Fp
の場合が多いようですが、それ以外もあり、一部は衝突しているので要注意です。[368]
復号器 が完全な ISO/IEC 2022 の実装ではない場合は、
たとえ完全に自己記述的な符号 であったとしても、
どんな指示シーケンス が利用されているか検査が必要となります。[369]
例えば
ISO/IEC 2022 全体の復号器 がない環境で、
ISO-2022-JP-2
と
ISO-2022-JP-3
の復号器 があるなら、両者は共通部分とそれぞれの固有部分があるので、
どちらの復号器 が適切かの判断が必要となります。日本語文字コードの識別用符号列 [370]
日本語圏 ではシフトJIS と日本語EUC の区別のために特徴的な文字列を挿入する手法が開発されてきました
(>>135 )。
[371]
こうした手法は Shift_JIS と EUC-JP の区別にはそれだけで有益であったとしても、
それ以外の世界の文字コード が候補となるとき、必ずしも十分な根拠にならないこともあります。
[372]
しかしせっかく著者 が提供してくれているヒントを判定器が無視するのももったいないのであり、
BOM や指示シーケンス ほどの確実性は無いとしても、
それに準じた重要情報として利用することが期待されます。
gb18030 の特徴的な符号列 [275]
gb18030 の4バイト符号は、第1バイトと第3バイトに右 のバイト が使われ、
第2バイトと第3バイトは ASCII数字 のバイト が使われるというかなり独特の構造をしています。
主要な多バイト符号 でASCII数字 を第2バイトに使うのは gb18030
だけです。
各種の8ビット符号 でこうした並びが出現することもあるでしょうが、
特殊な用例に限られるのではないかと思われます。
そこでこうした並びを数えて、
gb18030
と判定する有力な根拠として使うことができます。
判定条件からの逸脱の扱い [350]
ある符号 で使わないバイト の出現でその符号 を候補から除外することは、
ときに正解の符号 まで過剰に除外してしまうおそれがあります。
[351]
空き領域 が出現した候補を除外すると、外字 が入ったデータを正しく判定できない場合があります
(>>341 )。その符号 における空き領域の利用実態を勘案して出現頻度の閾値を決めるなど、
曖昧な判断が望ましいことがあります。
[352]
符号構造 から逸脱した候補を除外すると、破損データを正しく判定できない場合があります。
古いデータには特に言えることですが、
生成や転送の過程の何らかの問題で多バイト文字の一部が破損したり、
関係ないデータが混入したり、
といった理由で通常の符号構造 に沿わないバイト が出現することが、
ままあります。一度の違反で即決せず、
バイト列 の全体の傾向から総合的に判断するべき場合があります。
[353]
判定条件を弱めれば弱めるほど不規則データへの耐性は高まりますが、
他の符号 と誤認する可能性も高めてしまうことになります。
あらゆる破損に対応することは原理的に不可能で、
どこかで線引きが必要です。
[354]
正常データのほとんどすべてを正しく判定できつつ、
異常データもできればなるべく作成者の想定に近いものと判定できることが好ましいと考えられますが、
具体的にどのような状態を良しとし、
どのようにそれを実現するか、は判定器の適用分野と実装戦略次第になります。
典型的バイト列による推測 [249]
符号 や応用 に依存した「ありがち」なバイト列 のパターンが出現することがあります。
[250]
どれくらい決定的な根拠にできるかはケースバイケースで、
他の符号 との区別や「ありがち」な度合いによって調整が必要となります。
8ビット符号の特徴的な符号列 [265]
かなり多くのWebページ が© を使った著作権表記 を持っています。
© の前は空白かタグ で、
© の後は空白かタグ か、年号 か著作権者 が来ます。
[266]
windows-1252 やいくつかの文字コード 体系で 0xA9 に ©
があります。 >>265 のようなバイト列 のパターンを発見できれば、
そうした文字コード 体系である可能性が相当高くなります。
[269]
0xA9 は Shift_JIS で半角カナ の ゥ に当たります。
幸い ゥ は直前にカタカナ が来ることがほとんどで、 >>265
のようなパターンで出現することはまずありません。
Shift_JIS でないことを示す徴証として使うのが良いと考えられます。
[318]
他の多バイト符号 では第1バイトに使われることがありますし、
Shift_JIS でも第2バイトには使われることがあります。
前後が空白 , という条件が重要になります。
多くの多バイト符号 だと第2バイトに < や > が来ることもないので、
タグ も空白 と同等に扱えます。
それ以外だと徴証としては少し弱くなります。
[317]
windows-1252 やいくつかの文字コード 体系で 0xAE に
® があります。
0x99
に
™
があります。これらは語末に出現します。
[319]
英数字 の後に半角カナ 0xAE
が1つだけ出現して空白 が来ることはほとんどないので、
Shift_JIS ではない可能性が高いと判断できます。
[320]
しかし 0xAE や 0x99 は多バイト符号 の第2バイトになることがあるので、
非ASCII文字 の後に 0xAE や 0x99
が来るケースでは注意が必要です。
[321]
ced は 「NESTLÉ®」 を UTF-8 と誤認される windows-1252
の実例として挙げています。この例のように Shift_JIS 等の他に
UTF-8 としても正当なバイト列になり得ることがあるので注意が必要です。
[267]
他に非ASCII文字 がなくても© や® だけが非ASCII文字 として含まれることが、
欧米 や中央アジア をはじめ、世界的によく見られます。
そうした場合にこれを Windows-1252 と判断することが重要になってきます。
[268] 言語 モデルによる判定は letter だけを使いがちで、
©
のような記号が除外されていて判定に使われず、文字化け してしまうことがあります。[270] chardetng などがこうしたものを
windows-1252 と判定する条件を組み込んでいます。
>>289
[290] ただし chardetng はそれでも
©
を
ISO-8859-2 と誤認しがちです。
ISO-8859-2 との区別についてはわざわざ注釈で言及があります >>289 [330]
>>329
は
「Copyright ©1997,」
の © 1文字 (0xA9 )
だけが非ASCII文字 です。
ced は正しく判定しますが、
chardetng は ISO-8859-2 と誤認します。
[329]
Open Society-Georgia Foundation (OSGF ) , 2025-11-30T03:20:04.000Z https://web.archive.org/web/19981202173516id_/http://www.osgf.ge/ [580]
chardetng はこの他にも序数標識 や ’
に関係するいくつかのパターンで特殊処理を持っています。
>>289
[289]
chardetng /src/lib.rs at main · hsivonen/chardetng · GitHub2025-11-24T08:19:16.000Z https://github.com/hsivonen/chardetng/blob/main/src/lib.rs#L58 [295]
chardetng /src/lib.rs at main · hsivonen/chardetng · GitHub2025-11-24T08:34:54.000Z https://github.com/hsivonen/chardetng/blob/main/src/lib.rs#L450 価格 [322]
windows-1252 などいくつかのコードページ の 0x80 は €
です。通貨記号 の後にASCII数字 が続くなら、
価格 の表記と考えられ、
その文字コード 体系であることのヒントとして使えます。
[323] 言語 モデルによる判定は letter だけを使いがちで、
通貨記号 や数字 が除外されていて判定に使われず、文字化け してしまうことがあります。[324]
0x80 は主要な多バイト符号 の第1バイトには使われないので、
空白の後などで重要なヒントとして使えます。
しかし第2バイトに使われることはあるので、注意が必要です。
[325]
windows-1252 の 0xA4 など他の通貨記号 は多バイト符号 の第1バイトや第2バイトや、
Shift_JIS の半角カナ に使われることがあるので、注意が必要です。
罫線素片 [326]
多くの OEMコードページ は罫線素片 等の CUI
描画のための部品文字 を多く持っています。
これらは通常の文章には出てこないことが多いですが、図表などで使われることもあります。
[327]
こうした文字が1つだけ孤立して出現することはまずないので、
負のヒントとして使うことができます。
[328]
ただし縦線はそこだけ見ると前後に別の文字が来る、孤立した文字に見えますから、
単に前後が罫線素片 でないというだけでは足りず、少し工夫が必要です。
前後の行との結合を検査すれば確実ですが、
そこまでせずとも、
他に横線 (罫線素片 の連続) があるなら同様に罫線素片 とみなしてよく、
他に横線がどこにもないなら負のヒントとみなすのがいいかもしれません。
[251]
ファイル名 に出現することもまずないので、
OEMコードページ が使われることが多い
ZIPファイル のファイル名 の文字コードの判定 では1個の出現だけでも強力な負のヒントになります。
仮名 [510]
日本語 の文章 には仮名 が頻出します。
[511]
どの文字コード 体系でも仮名 は連続して特定の範囲に配置されていますから、
仮名 が使われた文章は特徴的なバイト列になります。
[512]
Shift_JIS と EUC-JP との区別や、各国の EUC
との区別に非常に便利な特徴です。
日本 では古くから使われてきました。
近年でも chardetng が利用しています >>252
ハングル [513]
大韓民国語 の日常的な文章 は大部分がハングル で表記されます。
漢字 は例外的です。
[514]
EUC-KR と gb18030 や EUC-JP は基本構造が共通しているので、
一見すると区別がつかなそうですが、いくつか特徴があります。
[515] ハングル は分かち書き され、
中文 や日本語 はされないので、語長 で明瞭に区別できます。[516] 日本語 では仮名 が有意に検出できます (>>510 )。[517] EUC-KR の KS X 1001
ではハングル と漢字 のブロックが分かれています。
ハングル の領域ばかりの出現でも区別できると
chardetng は述べています。 >>252 EUC-JP の特徴的な符号列 [271]
EUC-JP の CS3 は JIS X 0212 ですが、
先頭付近のいくつかの区 にダイアクリティカルマーク 付きアルファベット 等が配置されています。
こうした文字 の使われ方を想像すると、
欧州 の言語 の単語 を表す通常のアルファベット の列の中に孤立して1つだけ混じることが多そうです。
2つ以上続くこともあるでしょうが、1つだけのことが多そうです。
[272]
例えば ASCII文字 に囲まれた 0x8F (SS3 ) と GR
のバイト2つで構成される3バイトの列は、 >>271 の文字である可能性が高そうです。
各種の8ビット符号 でもこのようなバイト列が出現することは考えられますが、
この特徴的な並びが意味のある言語 の語を構成することは余り多くはなさそうです。
そこでこうした並びを数えて、
EUC-JP
と判定する有力な根拠として使うことができます。
[273]
実際のところ EUC-JP でこれらの文字 を使った (しかし一般の日本語文字 はあまり使わない)
文章はそこまで多くないと思われます。
文字コードの判定 のためのライブラリーのテストデータに含まれていることもあるのですが、
テスト用に変換して人工的に作った例文と思われます。
[274]
よってあまり優先度は高くありませんが、簡単に対応できるならしておいても良いかなという感じでしょうか。
UTF-16 や UTF-32 [373]
HTML をはじめとする機械可読 のデータ形式 のほとんどは
ASCII文字 を構文記述に使っています。
Unicode
では
ASCII文字 が [ U+0000 , U+007F ]
に配置されているので、
UTF-16 や UTF-32
では 0x00 が規則的かつ大量に出現することになります。
[374]
ASCII文字 が使われていることが期待される
UTF-16 / UTF-32 のバイト列 は、
BOM がなくても
0x00
の数を数えることで高確度で判定できます。
[375]
ASCII文字 が少ない場合でも、近いブロックに配置された文字 が並びがちという特徴を使えば、
UTF-16 か UTF-32 か ASCII 系かはそれなりの確度で判定できると思われます。
[376] しかしあまり需要が無いので、研究も実装もそれほどなされていないようです。改行 [636]
Mac OS符号化 であることの徴証の1つとして「改行 が CR であること」が使える可能性がありますが、この性質を実用している判定器は見当たりません。実世界データでの検証の報告もなく、実効性は不明です。
[645]
文字コードの判定 と近接する問題に「改行コード の判別」があります。
[637]
テキストファイル 系の現代的なデータ形式 のほとんどは改行コード として CR , LF , CRLF のいずれもを認識するか、そうでないとしても空白文字 として扱うので、改行 の判別が必要になることはそれほど多くありません。
[638]
改行コード の判定を主に必要とするのはテキストエディター の類で、どの形式であるかを認識し、新たな改行 や保存時に使う改行 を判定結果に設定することになります。
[639]
あまり必要性の高くない単純な処理なので、
詳しく議論されている例を見かけません。具体的な実装方法としては、
[640] 最初に発見したものを採用する[641] 全体を走査して最頻のものを採用する...
のどちらかが一般的でしょうか。
[642]
なお、行 が長大または改行 が存在しないファイルを読み込んだときに異常動作しない対策は必須となります。
(テキストエディター はファイル の全体を読み込むことが多いのでこの処理に特化した問題とはならないかも知れませんが。)
[643]
ASCII の系譜のほぼすべての文字コード で CR と LF が存在し、同じビット組合せ で表されます。それらの判定の処理では文字コード の違いを意識する必要はありません。多バイト符号 でも支障ありません。
[644]
UTF-16 や UTF-32 のような符号 では CR や LF も2バイト以上になるので、バイト レベルで判定するなら注意が必要になります。
統計的手法による推測 [258]
統計的手法は、バイト やバイト の連続の出現状況と、
それらが表すであろう文字 や文字列 の出現頻度の統計データとを突き合わせることで符号 を推定します。
[259]
有名な換字暗号 の解読法に、英語 の文章で e
が頻用されることを利用して暗号文を解読するものがありますが、
基本的な原理はこれと同じです。
[260]
文字コードの判定 問題は、
既知の有限少数個の符号 のいずれかに回答候補が絞り込まれていますから、
任意の換字暗号 解読問題より簡単です。
[261]
しかし符号化 されているのが英文 とは限らず、
世界中のどの自然言語 かわからないし、
混合されているかもしれないし、
自然言語 の文章とも限らないという難しさがあります。
[262]
ファイル名 のように利用できる材料が少ないこともあれば、
ネットワーク から取得中のデータのように利用できる材料が徐々に増えていくこともある
(= 途中で傾向が変化するかもしれないし、全体像が見えない段階で判断を迫られることもある)、
という難しさもあります。
[478] 統計的手法には原理的な限界があります。
まず、
「対応していない言語は判定できない」という根本的問題があります。
言語の頻度モデルは既知の自然言語 に基づいて構築されているため、モデルに含まれていない言語、または収集されていない方言 やスラング を入力された場合、
推定器は誤った言語モデルを適用するか、雑音として扱ってしまいます。
未知語彙の多いテキスト、記述体系が非標準的な言語は、とくに誤判定が起きやすい領域です。
[477] また、既知の自然言語 であっても、通常の文章から逸脱した「奇抜」
な表現は統計的特徴を乱し、精度を大きく低下させます。文学的効果を狙って異常な語彙分布にしたり、
極端に省略・連結した文体を採用したり、比喩的または視覚的な表記
(特殊記号の多用や AA 、ギャル文字 などの利用) を行うと、
言語モデルの前提である頻度の安定性が破壊されます。
「ハングル表記の日本語」「ヘブライ文字で書かれた英語」のような、
文字と言語の一般的な組合せと乖離しているデータも、統計的手法の想定外です。
[479]
自然言語 的でないデータの扱いはさらに困難で、例えば「文字コード表」「文字一覧表」「索引」
のような資料は、特定の語や文字が異常に均等に、あるいは偏って出現するため、
語の使用頻度に基づく判定はほぼ機能しません。
[646]
統計的に不安定な短い入力では、長い入力と同じ判定結果が得られるとは限らないという点も重要です。これは、判定器の挙動を調整する際に「最小の再現データを用意し、その入力に対して望ましい出力が得られるように修正する」という一般的な開発手法が必ずしも通用しないことを意味しています。短い入力は統計量そのものが揺らぎやすく、小さなバイトの偏りが大きく結果を左右してしまうため、点的なテストケースを追加しても、それが広い入力空間における挙動の改善につながるとは限りません。むしろ、短い断片を対象とした局所的な調整が、長い入力に対して逆効果となることもあり得ます。こうした特性が判定器の開発の難しさの最大の要因のひとつです。
言語モデル [263]
多くの判定器は自然言語 の文章の文字 や文字 の連続 (n-gram )
の出現頻度に基づき言語モデルを用意し、推定に使います。
[264]
具体的にどのような言語モデルを作り、どのように保持し、
どのように処理に使うかは、それぞれの判定器で違います。
[475]
同じ自然言語 や同じ文字コード の言語モデルと言っていても、
その実態は実装ごとにまったく違うので、
基本的には他の実装には流用できません。
[476]
例外的に、 UnivCharDet の系譜の各種判定器は共通祖先のオープンソースソフトウェア からの派生なので、
他のソフトウェアのソースコード上のデータや言語モデル生成ツールを流用できることがあります。
その場合でも、言語モデルの使い方に手が入っている実装も多いですし、
判定器内の各構成部分のバランスの違いもありますから、
無調整で流用できるとは限らないことには注意が必要です。
言語対応と言語判定 [480]
設計によるところも大きいですが、
言語モデルは必ずしも1つの自然言語 ごとに1つとする必要はなく、
文字 の利用度が似た傾向にある複数の自然言語 をまとめたモデルを用意することで足りる場合もあります。
[481]
欧州など複数の自然言語 で同じ文字コード 体系を共有している領域では、
細かく自然言語 を区別するよりもまとめた方が精度も処理速度も良くなることもあります。
借用語 や固有名詞 や引用文で混在しがちな言語 群は、
細かく分ける方が結果が悪くなるかもしれません。
[482]
言語モデルの種類が多いほど、必要な処理が増えるということですから、処理速度は悪化します。
しかし言語モデルを統合しすぎても、言語の特徴が均されて見えづらくなりますから、
判別精度は悪化します。
実データの傾向を見ながら適度なバランスで分割・統合された言語モデルを用意し、
それらを使って結果を導出する計算のパラメーターを調整していく地道な作業が必要となります。
[483]
判定器のなかには、文字コード判定 と併せて言語判定 の機能を備えるものも存在します。
確かに自然言語 を特定して文字 の頻度から符号 を判定するという判定器の仕組みは、
自然言語 の判定器という側面も持っています。
[484]
しかし、この二つの機能を統合することが優れた実装戦略であるかについては慎重な検討が必要です。
文字コード判定 と自然言語判定では、要求される言語モデルの精度や粒度が異なるためです。
文字コード の種類よりも自然言語 の種類の方がはるかに多く、
細分化された言語モデルが必要になります。また、UTF-8
のように符号構造 を利用すれば言語モデルなしで判定可能な符号 であっても、
統合してしまうと結局は各自然言語 ごとのデータを用意する必要が生じ、
不要な複雑さを抱え込むことになります。
[485]
とりわけ欧州 の諸言語のように、使用する文字種も符号構造 もよく似ている場合、
文字コード × 自然言語 の組合せごとに類似したモデルが多数必要となります。
最低でも十数個規模の言語モデルを管理することになります。このような環境では、
計算結果の小さな差異で優劣が入れ替わるので、調整が綱渡りのように不安定なものとなります。
[486]
さらに重要なのは、誤判定のコストの違いです。
自然言語 の誤判定は大きな影響がないことが多いですが、
文字コード の誤判定はデータの読解不能 (文字化け )
という致命的な結果を招きます。
綱渡りの調整で判断を迫られた場合には文字コードの判定 を優先せざるを得ませんが、
自然言語 の判定精度の足を引っ張るとしたら本末転倒です。
[487]
新たな自然言語 への対応を増やす際にも、対応済みの自然言語 の判定への悪影響はもちろん、
対応済みの文字コードの判定 への悪影響を回避する必要があり、
自然言語 の追加の開発コストとリスクが大きくなってしまいます。
言語モデルの開発 [488]
言語モデルの開発は容易ではありません。
対象となる言語 の文章を大量に収集し、分析しますが、
世界中の各言語の文章群 (コーパス ) の入手からして困難です。
[497]
平成時代 初期に開発された
UnivCharDet
も苦労したと思われ、
言語モデルの都合で西欧 と中欧 への対応に制限があるなど機能性に影響が出ています。
UnivCharDet
の系譜のソフトウェアの多くはその言語モデルをそのまま引き継いでいます。
[498]
ced
は
Google のデータベースを利用しているようです。
Google が世界中から集めた Webページ の分析結果を自由ソフトウェア として利用できるのは素晴らしいことですが、
Google 社外の我々はそれをただ使うことしかできず、
研究することも改良することも、
他に流用することもほとんど不可能という限界も抱えています。
[499]
ced に限らず他の判定器の言語モデルも、
基本的には「そこにある」という以上のことはどうにもできない不透明なデータです。
微調整くらいはできるかもしれませんが、
完全に再生成するには同一の元データを用意し、
同じ方法で計算、加工しなければなりません。
完全に再生成できなければ改良もできません。
ところがすべての元データを用意するのは原作者すら不可能な場合が多いです。
[500]
これは近年 LLM 等の AI 技術で問題となっている構図とよく似ています。
OSAID [489]
UnivCharDet の系譜のソフトウェアの一部や
chardetng >>252 Wikipedia
の記事を使っています。
Wikipedia
には様々な分野の記事が集まっており、
適度に固有名詞 や外来語 も混ざっていると考えられますから、
目的に適った文書群といえます。
[490]
ただし Wikipedia が万能ともいえません。
まず、 Wikipedia に存在しないか、十分な記事がない自然言語 では適しません。
[491] 幸い、 Unicode 以前に独自の文字コード 規格を開発し流通させてきた自然言語 の多くは
Wikipedia が存在しているようです。しかしフォント依存符号化 を使ってきた少数言語などはカバーされていないことがあります。[492]
また、ファイル名の文字コード の判定のような一般の文章とは異なる語彙の偏りを持つ可能性がある対象に適用する場合の
Wikipedia 由来のデータの有効性は明らかではありません。
[493]
音楽 ファイルのメタデータ や subtitle も一般の文章とは異なる偏りを持つ可能性があります。
ただ Wikipedia にも楽曲やアーティストの記事はありますから、
カバーされていないともいえません。
有効なのかどうか明確ではないという状況です。
[494]
Web では文字コードの判定 (推定) が必要なのは初期の Webページ が中心です。
既に二十年前後が経過しており、
自然言語 の表記や語彙 にも多かれ少なかれ変化が生じていると考えられます。
正書法改革 が行われた言語 もあります。
現在の Wikipedia から作成した言語モデル が当時の Webページ に機能するかどうかは、
慎重にならざるを得ません。
[496]
これについては、
UnivCharDet の系譜や
chardetng
を使った古い Webページ の判定に顕著な劣化が見られないことから、
実用上の問題にはならなそうです。
[558]
Wikipedia は中文 (簡体字 / 繁体字 ),
セルビア語 (キリル文字 / ラテン文字 )
で同じ記事データを別表現に自動変換しています。
元データは中途半端な混在の可能性が、
変換済みデータは不自然な表記の可能性があり、
取り扱いには注意が必要となります。
[509]
Wikipedia は整った説明調の文章が多く、
会話文や俗語に乏しいことには特に注意が必要かもしれません。
[495]
Unicode とそれ以外の文字コード とでは異なる符号化モデルを採用していることがあります。
特にアジア では、地域で使われてきた文字コード やフォント と Unicode
とが「文字」の概念のレベルで違っているケースが散見されます。
Wikipedia など Unicode のデータはそのままでは適用可能な言語モデル にならないかもしれません。
Unicode から当該文字コード へ変換することもできるでしょうが、
変換器の出力は当時の一般的な入力方法での利用実態と乖離していることも懸念されます。
[501]
Unicode 以前の文字コード の文書では、
当該文字コード にない文字 を代用表記 にしていたり、
文字参照 で表したりしていることもあります。
こうした文書では通常の文章と違った文字の利用頻度となることがあります。
[502]
どこの国でも初期の Webページ では英語 が使われがちです。
英語 と地元の固有名詞 の組合せは、
地元の言語とも純粋な英語 とも違った文字の利用頻度となることがあります。
[503]
こうした事情を抱えた古い Webページ は、
Wikipedia 由来の言語モデルをそのまま単純に使った判定では必ずしも正解を得られないようです。
[504]
注意が必要な具体的事例:
[505] ルーマニア語 の文字 の選択 ルーマニア語文字問題 [506] 越南語の文字コード の符号化モデルの違い
(VNI , TCVN3 , windows-1258 ) >>613 [508] 半角カナ の符号化モデルの違い (濁点 、半濁点 ) >>613 [507] インド系文字の文字コード の符号化モデルの違い[589] CJK互換漢字 に対応付けられている漢字 およびそれに関係するCJK統合漢字 に対応付けられている漢字 の扱い記号の扱い [608]
言語モデルにおいて狭義の文字 (letter ) 以外の数字 , 句読点 , その他の記号 等をどう扱うのが良いのか、は難問です。一般の n-gram 等でもそれらは除去したり、 SP に置換したりすることが多いです。 記号 等は任意の単語の前後に現れたり、同じ位置でも時と場合によって違う記号を使い分けたり、自然言語 とは異なる用法の列を形成したりするので、自然言語 の単語 における letter の出現パターンとは違うことが多く、混ぜたモデルが有効に機能するとは限らないのです。
[609]
記号 を混ぜた言語モデルは利用コーパス の性質の影響も強く受けてしまうと考えられます。 Wikipedia 由来のモデルだと、整った説明文に出てくる句読点 は頻出するでしょうが、装飾的な記号の使われ方はあまりしないと予想されます。俗語 や文学 的文章、専門性の強い技術的文章などの記号 の使われ方に適応できるかどうかが未知数です。
[610]
記号 等がまったく判定に寄与できないわけではなく、言語モデル以外の方法で、あるいは letter 用とは別の言語モデルで加味することはあり得ます。例えば「、」や「。」に相当するバイトが定期的に頻出するなら日本語文字コードの可能性が高いとして加算する (ただし皆無だとしても減点要素にはしない) という採点は可能でしょう。欧文 で語頭 や語末 にあるバイト は引用符かもしれない、などといった性質もうまく盛り込める形のモデルも有用そうです。
[611]
UnivCharDet の系譜の判定器の言語モデルは基本的には letter の出現頻度等で構成されています。系譜の実装の一部は記号類の出現の度合いを判定に加味することがあります。
[612]
chardetng は記号等をいくつかの種別に分けて letter とは違った方法で判定に加味しています。
結合文字の扱い [613]
結合文字 を扱う必要がある場合、
[614] 言語モデルにおいて結合文字 はどう扱うべきなのか[615] 合成済み文字 を使う文字コード と基底文字 と結合文字 の組み合わせを使う文字コード があるとき、一方のデータによる言語モデルを他方の判定にも適用できるのかといった疑問が生じます。これが主に問題となるのは越南語の文字コード の各種です (>>561 )。また、技術的には結合文字 ではありませんが、半角カナ の濁点 ・半濁点 にも同じことがいえます (>>571 )。
[616]
合成済み文字 かどうかによって基底文字 の出現頻度は変化しますし、基底文字 + 結合文字 や結合文字 + 次の文字 の bigram が変化します。この違いがどう影響するのかです。
[617]
1つ目の疑問 (>>614 ) については、基本的には letter と同じ扱いで良いと思われます。
[618]
少し意外に思われますが、 越南語の文字コード とそれ以外の欧州などの文字コード の区別に結合文字 の扱いはあまり寄与しません。 UnivCharDet の系譜の判定器で Wikipedia から生成した言語モデル、すなわち合成済み文字 方式の文字が含まれる可能性が高いモデルを使ったものがありますが、越南語 かどうかを概ね正しく判定します。また、 chardetng は独自の方法で決めた2種類の表現でデータを作っていますが、どちらでも大差はないという報告になっています >>252
[619]
このような結果になるのは、それ以外の文字や並びによる越南語 かどうかの区別が大きな要素であって、非ASCII文字 部分で越南語の文字コード のどれを使っているかによる差が小さいということです。越南語の文字コード 相互の差が付きにくいという問題は合成済み文字 か基底文字 と結合文字 の組み合わせかを区別して適切な言語モデルを使えば少し改善できますが、それだけでは不十分です。越南語 の語の構造を意識して採点すると更に改善できます (>>561 )。あるいは trigram などでも改善できるかもしれません。
[620]
この越南語 の結果が他の言語の同様の符号化モデルの違いにも当てはまるのかどうかは定かではありません。越南語 は規則的な単語の構造で結合文字 の出現の仕方も特異なので、むしろ例外的なのかもしれません。
[621]
基底文字 と結合文字 の組み合わせが一般的なものと異なる場合は、積極的に減点した方が良いかもしれません。越南語 の場合はそれを語全体の構造を意識した採点により実現できますが、他の言語では前後2字の連続によって減点することになるでしょうか。
ASCII文字の扱い [305]
EBCDIC などを除くと、ほとんどの文字コード 体系は ASCII文字 を共通に持っています。
そのため
ASCII文字 は文字コードの判定 に大きくは寄与しません。
[306]
また多くのマーク付け言語 やプログラミング言語 は英語 の語彙 を大量に含んでいます。
[307]
HTML文書 の場合要素名 、属性名 、 JavaScript コード、
CSSスタイルシート などの形で多くの英語 の ASCII文字 表記を含みます。
更にいえば、初期の Webサイト はどの地域でも英語 が多いです。
本文が英語 でないとしても、話題がインターネット や計算機 の技術系のページでは英語 や英語 由来の
ASCII文字 の語が極めて頻出します。
[315]
判定に使う文字の出現頻度の情報は、想定される自然言語 の文章から計算されています。
英語 の濃度が極度に大きいと、本来の自然言語 の出現頻度から離れていき、
判定が狂う要因となってしまいます。
[308]
こうした事情があるので入力の ASCII文字 をどう取り扱うかは設計上無視できない問題となります。
[309]
ASCII文字 を無視すれば、こうした「ノイズ」も一気に除去することができ、
非ASCII文字 の文字コードの判定 に注力し、関係ない部分の処理の負担を軽減できます。
[310]
一方で欧州言語などASCII文字 が言語 の表記の主体となる場合、
非ASCII文字 の割合が少ないので、
すべてのASCII文字 を捨ててしまうと言語判定 の重要な情報まで捨ててしまうことになります。
[311]
中間解として、 非ASCII文字 の周囲の ASCII文字 を判定に活用するのが現実的です。
ASCII文字 と非ASCII文字 にまたがる n-gram の出現頻度は、
とりわけ欧州言語の判定に重要です。
[312]
UnivCharDet は非ASCII文字 を含む単語を8ビット符号 の判定に利用しています。
[313]
chardetng はそれより攻めていて ASCII文字 同士の連接 は判定に使わないようです。
[314] ただしこうした戦略の違いがどれだけ判定性能や動作速度や消費メモリー量に影響を及ぼすのか、
定量的な比較はあまり行われていないようで不明瞭です。
[316]
欧州語で、しかもファイル名 のような短い文字列が入力のとき、
ASCII文字 だけの部分でも言語判定 のヒントに使えれば、
数少ない非ASCII文字 やその前後だけでは情報が不足する言語判定 の補強材料になります。
しかし両者が関係ない単語の場合もあって、そのときは誤判定のリスクが増大します。
エスケープとの混合 [188]
エスケープ (HTML の文字参照 など) とそうでない通常の文字 が混合されている場合、
純粋な文字列 とは違った文字 分布になってしまう場合があります。
[189]
単純に ASCII文字 だから、マーク付け言語 の構文要素だから、
といった理由でエスケープ を除去すると、通常の文字 の前後関係が言語 の一般的なパターンと外れてしまい、
判定に失敗することがあります。
[196]
エスケープ とそうでない文字 が混在するのは、特に理由が無いこともありますが、
敢えて混在させていることもあります。文字化け しやすいとか、
その文字コード に存在しないとかです。得てしてそれらは文字コードの判定 の際どい条件に関わってくる要素になりがちです。
欧州ラテン文字系文字コードの区別 [200]
Windows-1252 (含 ISO-8859-1 ) と ISO-8859-2 と Windows-1250
は区別の難易度が高いことが知られています。
[201]
そもそもラテン文字 系言語 は文章の多くが ASCII文字 で、
言語 次第で少々の非ASCII文字 が混ざるという構造です。
非ASCII文字 主体の他文字 の言語 よりも判別が難しいです。
[202]
Windows-1252 と Windows-1250 は似た構造ですが、
収録される文字 の種類は一部で著しく異なっています。
文章に少々混じる非ASCII文字 のうちの更に一部の頻出文字が共通で、
残りが全く異なるので、バイト の並びとして見たとき、
どちらかにわかに判断しがたいことが多いです。
[203]
Windows-1250 と ISO-8859-2 はだいたい同じで少し違います。
どちらも中欧 でよく使われていた文字コード で、
同じような言語 で同じように使われていて、
わずかな違いがどちらなのか判定するのが難しいです。
[211]
Mozilla の UnivCharDet は ISO-8859-2 に対応しているものの、
ISO-8859-1 が誤判定されてしまうとして無効化されています。
UnivCharDet の派生の中にはこれを改善して有効化しているものもありますが、
それらも完璧に判定できるわけではありません。
[212]
ced は .hu ドメイン のみ trigram を有効にするなど、
特別な処理で判定を強化しています。それでも Chrome
はたまに判定を誤ります。
ロケール等による文字コード判定の補助
[213]
chardetng も TLD による傾斜など特別な処理で判定を強化しています。
それでも Firefox はしばしば判定を誤ります。
ロケール等による文字コード判定の補助
[214]
完璧な判定は困難ですから、どの手法を採るにせよ、最終的に文字コード指定メニュー など利用者 が選択を覆せる手段が必須です。
[281] >>280 はハンガリー語 で書かれた HTML です。
各種の判定器は ISO-8859-2 , windows-1250 , windows-1252
と判断が分かれています。
Firefox は windows-1252 と考えます。
Chrome は windows-1252 と考えますが、
ced にバイト列を与えると windows-1250 と回答します。
2025-11-24T06:15:55.100Z
[282] 実際には3符号化の共通文字が非ASCII文字 でも多いのですが、
ハンガリー語 であることとハンガリー語 の文字 の使い方から
ISO-8859-2 / windows-1250 と考えるのが妥当です。
>>280 の範囲では ISO-8859-2 と windows-1250 は同等です。
[283] Firefox と Chrome は文字コード指定メニュー がないので、
文字化け したまま修復できません。一種の不具合といえます。[280]
Bemutatkozik a WILD WEST GYÕR , 2025-11-24T06:08:55.000Z https://www.members.tripod.com/wildwestgyor/bemut.htm [539]
ラテン文字 は言語 が多いので、
言語モデルは個々の言語 ではなくいくつかまとめた言語 群ごとに用意するのが無難です
(>>485 )。
[540]
西欧 (windows-1252 / iso-8859-1 / macintosh / ibm850 の類)
のうち、言語
fo, is
は利用文字が他と大きく違います。
chardetng は西欧 をこれらとそれ以外とで二分しています
>>252
[541]
残りの西欧 (旧植民地 等を含む。) は、
スカンジナビア ・ドイツ とそれ以外とでやや利用文字に異なりがあるので、
二分するのが一案と思われます。
[542]
したがって西欧 系の言語モデルは次の3種類にまとめられます。
[543] 西欧 : af, es, fr, it, pt[544] 含、初期 Web ページで windows-1252 + 文字参照 がよく使われた :
et, mt, ro, rs, sq, tk[545] 南北欧 : da, de, fi, no, sv[546] 北北欧 : fo, is[547]
トルコ語 は西欧 の文字コード とよく似たものが使われますが、
微妙に違いがあり区別しづらいこと、大文字と小文字 の扱いが違うこと (>>520 ) に注意が必要です。
[548]
中欧 、バルト はそれぞれの文字コード 群に対応する言語群でモデルをまとめてしまって構わなそうです。
ISO-8859-3 は専らエスペラント語 で使われたので、
これは独立させた方が良さそうです。
[549] トルコ語 : az, tr[550] 中欧 : cs, hr, hu, pl, ro (ただし >>505 ),
sk, sl, tk[551] バルト : et, lv, lt[554] エスペラント : eo[552] et は >>551 と >>554 に重出しますが、この是非については検討の余地があります。
[555] 他に ibm865 や ISO-8859-15 , ISO-8859-16
などを扱うなら、対象言語に特化した言語群のモデルを用意したほうが良いかもしれませんが、
>>543 との関係を検討しなければなりません。
[556] なお各言語 と国家 と文字コード の利用実態についてはロケール等による文字コード判定の補助 も参照。
[553] 越南語 は言語 も文字コード も性質が大きく異なるので、別途の扱いが必要です。
東側諸国の言語モデル [525]
旧ソ連 を中心とする東側諸国 は20世紀 末に正書法 改革やロシア語 からの脱却を進めたところが多く、
その影響が問題となります。
[526]
初期の Webページ の文字コード を扱うという目的で Internet Archive に残る各国の古い
Webサイト を調査すると、地域によって差も大きいものの、
[527] ロシア語 (windows-1251 , KOI8-R )[528] 英語 [529] 現地言語のラテン文字 表記 (windows-1250 , windows-1252 , windows-1251 ,
KOI8-R のいずれかと、それらで足りなければ文字参照 )が大部分で、国単位の例外で
[530] アルメニア文字 [532] ジョージア文字 [531] ブルガリア語 のキリル文字 表記 (windows-1251 )[533] セルビア語 等のキリル文字 表記 (windows-1251 )[534] マケドニア語 のキリル文字 表記 (windows-1251 )[535] 蒙古語 のキリル文字 表記 (MNS 4330 )があります。ラテン文字 に移行した国の旧キリル文字 表記やロシア連邦 の少数言語のキリル文字 表記は見つけるのが困難です。
ロケール等による文字コード判定の補助
[536]
従って言語モデルの開発において旧正書法 のデータを入手する必要性は大きくなさそうです。
[538]
現地言語のラテン文字 表記について、何度か正書法 の改定が行われている場合もありますが、
少なくても文字コードの判定 に関係しては、特に目立った違いのようなものは検出できません。
[537]
UnivCharDet はキリル文字 に関してロシア語 の言語モデルを用意していました。
UnivCharDet の系譜の判定器の中にはこれだけでは不足としてブルガリア語 の言語モデルを追加したものがあります。
Webページ の判定ではこの2つのモデルがあれば他のキリル文字 言語も含めて実用的な精度が得られるようです。
[523]
chardetng はアゼルバイジャン語 について
For Azerbaijani, I replaced ə with ä to synthetize the windows-1254-compatible 1991 orthography. なる調整をしたと説明しています。 >>252
[524]
アゼルバイジャン における windows-1254 の利用は皆無ではないにせよ一般的とは言い難く、
ここで説明されているような表記法の利用実態があるのか、
それが判定精度に寄与するのか、といった点に不安が多いです。
実際に
Internet Archive
で確認できる古い
.az
の
Webサイト は英語 かロシア語 か、
そうでなければ
windows-1251 と文字参照 の組合せであり、
>>523 のような事例は未発見です。
ラテン文字の文字コード , ロケール等による文字コード判定の補助
[522]
chardetng は蒙古語 でも調整したと説明しています。
>>252 Encoding Standard や Firefox が
MNS 4330 の存在を認めていないために必要になる処置です。
大文字と小文字 [294]
出現頻度による手法の多くは大文字と小文字 を同一視して文字 や n-gram
の頻度を見ています。ほとんどはこの手法でうまく判定できます。
[520]
トルコ語 では他の言語と I / i の大文字と小文字 の扱いが違うので、
注意が必要です。
[521]
日本語 の平仮名 と片仮名 は使われ方がアルファベット の大文字と小文字 とは違うので、
同じような取り扱いにするかどうかは悩みどころです。
[292]
chardetng は大文字と小文字 の使い分けが自然なものを加点し不自然なものを減点しています。
>>291
[293]
ギリシャ文字 ですべて大文字 にした語は、キリル文字 をすべて小文字 にした
KOI-8 やヘブライ文字 と混同しやすいとされ、
ced や chardetng が特殊処理を入れています。
>>291 , >>284
[291]
chardetng/src/lib.rs at main · hsivonen/chardetng · GitHub , 2025-11-24T08:24:04.000Z https://github.com/hsivonen/chardetng/blob/main/src/lib.rs#L154 [284] compact_enc_det /compact_enc_det/compact_enc_det.cc at master · google/compact_enc_det · GitHub2025-11-24T07:39:23.000Z https://github.com/google/compact_enc_det/blob/master/compact_enc_det/compact_enc_det.cc#L1770 // Greek all-caps is confusable with KOI8x all-lower and Hebrew.
[299]
Countermeasures for various misdetections. · hsivonen/chardetng @0973b4b · GitHub , 2025-11-24T08:50:10.000Z https://github.com/hsivonen/chardetng/commit/0973b4b67da81b9be2f643d0da70536d616aec06 ASCII 文字と非 ASCII 文字の隣接 [300]
chardetng はラテン文字 とそれ以外 (ASCII文字 とそれ以外)
の隣接で非ラテン文字 系符号 を減点しています。
>>299 , >>252
[518]
日本 でよく見る、ラテン文字 の並びの途中にぽつんと漢字 が1字混ざるタイプの文字化け の抑制になりそうです。
[519]
この種の規則を組み込むには慎重な評価が必須です。
多バイト符号 の第2バイトが ASCII英数字 になることはよくありますし、
日本語 などで漢字 とラテン文字 が隣接することは割とよくあります。
語長 [297]
chardetng は語長 が23超 ならタイ文字 以外を減点しています。
>>296
[298] chardetng は EUC-KR のハングル の語長 が5超 なら減点
(EUC_KR_LONG_WORD_PENALTY) しています。 >>296
[301]
他の実装にはあまり見られないので有効性は不明瞭です。
[302]
johab は他の符号と誤認の排除にハングル の語長 の平均 (大雑把に 3
字くらい) との乖離の検知が有効なようです。
[296]
chardetng /src/lib.rs at main · hsivonen/chardetng · GitHub2025-11-24T08:46:35.000Z https://github.com/hsivonen/chardetng/blob/main/src/lib.rs#L755 書字方向 [303]
ISO-8859-8 など視覚順 と論理順 の区別が必要となる場合があります。
[304]
ヘブライ文字 は語末形 と語中形 が異なるものが5字10種あります。
ISO/IEC 8859-8 や Windows-1255 はそれらに別のビット組合せ を充てています。
UnivCharDet はヘブライ文字 列の先頭や末尾の字形 の個数や前後から見た bigram
の評価によってどちらか判定しています。
[253]
chardetng はヘブライ文字 ではなくそれと併用される ASCII 句読点 の使われ方で判定しているようです。
>>252
[557]
どちらの手法も長短ありそうです。句読点 法は、
題名やファイル名 や短文などで機能しない虞があります。
[252]
chardetng : A More Compact Character Encoding Detector for the Legacy WebHenri Sivonen , 2020-06-08T16:23:51.000Z , 2025-12-03T05:01:28.298Z https://hsivonen.fi/chardetng/ 越南語 [561]
ベトナム語 はラテン文字 ですが、発音区別符 を多用します。
Unicode 以前は数個の異なる文字コード が使われていました。
越南語の文字コード
[562]
いずれも ASCII の拡張ですが、
欧米 のラテン文字の文字コード とは言語の構造も文字コード の構造も違います。
ところがASCII英数字 に非ASCII文字 が少々混じるという基本構図は同じなので、
単純な bigram の出現頻度だと区別が付き辛いこともあります。
[563]
越南語 は音節 ごとに分かち書き され、
借用語 や略語 などを除くと、
3, 4つ前後の子音 字と母音 字が非常に規則的に並びます。
非ASCII文字 も母音 字等に規則的に出現します。
[564]
この性質を使うと越南語 主体の文章とそれ以外は高確度で区別できます。
[565]
ただし英語 に少々越南語 が混じる文章を扱うと難しく、
非ASCII文字 が少なめの欧文 との区別が付きにくいことには変わりありません。
[566]
越南語の文字コード の各種の中には、すべての文字 が合成済み文字 であるもの
(現在の Unicode の一般的な利用法はこちら。)
と、
結合文字 を使うものがあります。大文字と小文字 がすべて揃っていないものもあります。
[567]
結合文字 の有無などで文字 の単位が異なり、
出現頻度や隣接の仕方が違いますから、
言語モデルはそれぞれの文字コード の利用実態に合わせて開発する必要があります。
[568]
chardetng は Unicode と符号化モデルが異なる
windows-1258
用のデータを Wikipedia の Unicode 用データから生成するためあれこれ操作しているようです。
>>252 Web において windows-1258 が大規模に利用された形跡がなく、
当該操作で製作されたデータの有用性は不明瞭です。
windows-1258
[569]
Internet Archive に残る初期の Web で実際に越南語の文字コード を利用した
HTML文書 での実験によると、越南語 版 Wikipedia の Unicode
記事から作った言語モデルで
viscii , x-viet-vps , x-viet-tcvn3 , x-viet-vni
(とその他欧米の文字コード ) の区別は不可能ではないものの、
不安を感じる精度であります。 viscii , x-viet-vps は合成済み文字 なのでこのままでよく、
x-viet-tcvn3 , x-viet-vni は当時の当該文字コード の文書群を集めて製作した言語モデルに切り替えることで、
一応実用に耐える精度は実現できるようです。
[570]
ただ、越南語 が少ない場合 (>>565 ) などに改良の余地はあります。
どこまでを言語モデルの改良により、どこからを他の手法の組み合わせによるべきかも探求の余地があることでしょう。
半角カナ [571]
半角カナ は、日本語情報処理 における歴史的功績は大きく、幾度も流行のように使われてきた一方で、文字化け の元凶として嫌われてきました。
半角カナ
半角カナ が嫌われる技術的原因の多くが文字コードの判定 に関係します。すなわち、
[572]
EUC-JP を Shift_JIS と誤読すると半角カナ が頻出します。つまり文字化け すると半角カナ が現れます。[573]
Shift_JIS の半角カナ は EUC-JP の2バイト文字とバイト列 として区別がつかないことが多いです。つまり半角カナ を使うと文字化け しがちです。[574]
ISO-2022-JP の正式仕様に半角カナ はありません。そのため半角カナ が使えなかったり、非標準の方法で出力されたりします。つまり半角カナ を使うとエラーか規格違反になり、文字化け しがちです。[575]
Latin1 の記号を Shift_JIS と誤読すると半角カナ になります。つまり文字化け すると半角カナ が現れます。[576]
半角カナ は使うべきでないと言われ続け、文字コードの判定 の技術開発・実装でも半角カナ の判定はあまり重視されてきませんでした。厄介な存在にも関わらず、文字コードの判定 でどう扱うのがいいのか、ノウハウはさほど蓄積されてきていません。それでいながら半角カナ が使われ続け、文字化け の元凶でもあり続けるという悪循環がありました。
[577]
UnivCharDet の系譜の判定器は入力に日本語 の言語 指定がなければ半角カナ だけの文字列を理解できず、欧米等の8ビット符号 と誤認することがあります。 UnivCharDet は半角カナ を判定に使わないので、2バイト文字がなければ他の符号 に負けます。
[578]
chardetng は半角カナ と欧米等の8ビット符号 の区別のための得点調整を入れており、半角カナ だけの文字列のテストを用意していますから、この問題を認識し対策していることがわかります。実際に UnivCharDet の系譜の判定器よりこの種の判定は高精度です。
[579]
Shift_JIS の半角カナ のバイト は Latin1 の記号等のバイト と重なっています。 Web では © などの Latin1 文字が頻出します (>>265 )。 Latin1 側で特徴的なパターンに加点するだけでなく、 Shift_JIS 側で不自然なパターンに減点する対策が有効です。 Latin1 の記号が配置されている 0xAx の領域には Shift_JIS で句読点 や小書き仮名 が配置されています。これらのいくつかは、他の半角カナ の後に来る可能性が高いなど、使われ方に傾向があります。そこからの逸脱は、 AA などで出現し得ることには配慮しつつも、減点要素にできます。
[581]
半角カナ が含まれていても、平仮名 や漢字 も一般的な日本語 の表記方法で含んでいる短くない文章なら、文字コードの判定 に失敗することは多くありません。問題となるのは半角カナ のみで構成される語句です。
[582]
いくつかある入力欄の1つだったり、多数あるファイルのファイル名 だったりで他に同じ文字コード で記述されているはずのバイト列 があるなら、なるべくそれらをひとまとめにして文字コードの判定 の処理を適用することで誤判定の可能性を下げられます。
[583]
それでもファイル名 の短い文字列などで半角カナ のみで構成されるバイト列 を判定するべき場面はあります。8ビット符号 と同じように半角カナ の言語モデルを使って出現頻度で検査するのが良いのでしょうが、考えるべきことがいくつかあります。
[584] 言語モデルはどう作るのがいいでしょうか。[585] 半角カナ がどう使われるか考えてみると、大別して、 (1) 通常の日本語表記のうち片仮名部分 (2) 人名 の振り仮名 など発音表記 (3) 箇条書き などの記号 (4) 通常の日本語の文や語句だが片仮名表記、 (5) AA 等の構成要素、 (6) 俗語 あたりが考えられそうです。 半角カナ このうち (3) (5) は言語モデル法で扱うのは無理です。 (1) は Wikipedia などから片仮名 部分を抜き出せば作れそうです。 (2) (4) が (1) と同じ言語モデルで対応可能なのかどうかは自明ではありません。 (2) (4) (6) は仮名漢字変換 の辞書 などを活用することも考えられますが、意味のある出現頻度データが得られるのか不安があります。[586] (1) - (6) の用途の言語モデルは、合わせて1つ作るのが良いのでしょうか、それともいくつか作るのが良いのでしょうか。合わせることはできるのでしょうか。[587] 半角カナ には濁点 ・半濁点 付き仮名 がありません。濁点・半濁点を親文字から分離して頻度や隣接を数える必要があります。[588] 半角カナ の言語モデルと Shift_JIS の判定はどう組み合わせるのが良いのでしょう。半角カナ のみと Shift_JIS 全体とを別の符号 であるかのように扱うのが良いのか、 Shift_JIS の判定の一部として半角カナ も組み込むのが良いのか、どちらの設計も長短ありそうです。インド系文字 [622]
インド系文字の文字コード は数多ありますが、それらの区別の技法の研究や実装の事例はそれほど多くないようです。多くの文字コード がフォント依存符号化 であり、 HTML やワープロ の文書形式 におけるフォント 指定の方法でフォント名 が明示されているので、それを読み取ることで処理は足り、バイト列からの推定などの高度な手法の出番は多くありません。
[623]
しかし平文 やフォント 指定なしでの利用の実績がある文字コード 体系もあり、それらはバイト列からの推定が必要になります。
[624]
インド系文字の文字コード のほとんどは Unicode とは異なる符号化モデルを採用しています。主要な文字コード は Unicode との変換器がありますから、 Unicode のコーパスから変換したデータを作ることは一応可能ですが、変換器の生成データが従来文字コード の実用当時の使われ方と同じかどうかは不安があります。変換器は生成しないけれども実用されたバイトの並びが存在するかもしれませんし、バイトの並び方に実用とは異なる偏りが生じる可能性もあります。
[628]
したがって、インド系文字の文字コード の言語モデルを作る際には、 Unicode のコーパスを使うのではなく、当該文字コード が実用されているデータを収集するの必要があります。
十分な分量を集めることが難しい可能性もありますが、 TSCII や TAB のような主要な文字コード 体系については世界の他の文字コード も含めて互いに区別するのに十分な精度が出せるモデルを生成できることが確認されています。
[625]
チベット文字の文字コード については、チベット文字 で頻出する文字 のバイト の出現頻度を使った研究があり、中華人民共和国 の多バイト符号 系の文字コード 体系も含めて検討されています。 チベット文字の文字コード
[626]
チベット文字の文字コード の変換器で、入力に含まれる ASCII文字 の並びが英語 なのか、チベット文字 の翻字 なのかを語の構造や割合によって推測して決定するものがあります。 チベット文字の文字コード
[627]
ビルマ文字の文字コード の判定器は入力に含まれるUnicode文字 の並びのパターンを検査してフォント依存符号化
(主に Zawgyi )
を判定するものが多いです。
入力が UTF-8 文字列 となるのが独特な点です。
ビルマ文字の文字コード
[629]
Zawgyi もフォント依存符号化 として使われることが多いのでフォント名 で判定できそうなものですが、判定器の実装の多さを見るにそれ以外の需要もかなりある (あった) ようです。 SNS の本文や動画サイト の説明文などにも平成時代 末頃までは Zawgyi が散見され、フォント名 情報がないので判定が必要になります。
[630]
他にない珍しい取り組みとして、フォント データを調べて文字コード を識別する研究の事例があります。 クメール文字の文字コード バイト列 の文字コードの判定 とは違って符号構造 くらいしか使える要素がなく、出現頻度による判定は適用できません。もしかするとグリフ データの類似度を利用するような手法への発展の可能性もあるかもしれません。
[631]
Unicode 以外がほとんど使われなくなった現在では実需要もほとんどないとは思われますが、過去のデータやフォントの調査と分析でこうした手法が役に立つ場面もあるかもしれません。インド系文字の文字コード の全体像は未だ解明されておらず、有名なフォント とその符号体系は知られているものの、有名なもの以外のフォント や各符号 の類縁関係など今後の調査研究が期待される領域は多く、人間の作業を補助する機械的手段は有効と思われます。