kzkの日記： Konqueror[文字判別] - JIS編とでもしましょうか。 9
KDE Wikiでkhtmlについての文書の翻訳に関連してKonquerorの文字判別の部分のコードを覗いてみた。
俺の逐語訳が見たい方は : http://www.kde.gr.jp/pukiwiki/?khtml
これだったらkcc -cの方がいいのでは?と思って組みこんでみようと思うのだが、ソースコピペもどうかと思うし、自分が分かってもしないソースを提出するのもどうかと思うので、SJIS,EUC,JISの勉強でもしてみるか。
という流れ。
さてどうなることやら。
ちなみに今はjvimの判別ルーチンらしい。
お推めの文書とかあるだろうか。
----
使っている経験だが、圧倒的にeucとsjisのミスが多い。
まぁ似ているからというのが率直な原因なのだが。
この辺りを探ってみるか。
----
ちうかJISは判別しろよと。
LinuxJFを見ている時でもJISは全く判別しなかったぞ?何故じゃ?
例 : http://www.linux.or.jp/JF/JFdocs/From-PowerUp-To-Bash-Prompt-HOWTO.html
----
先生 : http://euc.jp/i18n/charcode.ja.html
「漢」と書いたJIS-Encodingのテキストを用意(jis.txt)
*いや決して「おとこ」ではなくて「かん」ですからね:-p
hexdump jis.txt
0000000 241b 3442 1b41 4228
JISにおいては次のような特別なルールがある。
漢字の開始
-ESC $ @ または ESC $ B
ASCIIの開始
-ESC ( B または ESC ( J
ESC = 0x1bと文字コード表を参照。
ESC $ @ = 1b 24 40
ESC $ B = 1b 24 42
ESC ( B = 1b 28 42
ESC ( J = 1b 28 4a
ほんとだ。あるじゃん。きちんとASCII開始記号で閉じてあるし。(改行前には必ずASCIIに戻る必要があるらしい)
しかしエンディアンがうざすぎる。
順番通りに見れる方法はないのだろうか。
7bit環境では次のようなものもあるらしい。
半角カタカナの開始
-SO (0x0E) または ESC ( I
ASCIIの開始
-SI (0x0F) または ESC ( B または ESC ( J
SOとSIに関してはkonquerorのソースでは判別していない。
これはまず駄目だな。
----
こうなってくると前のFrom-Powerupが判定できないのが絶体におかしい。
(下のような文字列を見て何か情報を得ている自分を見るたびに頭おかしいと思うのだが)
hexdump From-PowerUp-To-Bash-Prompt-HOWTO.html | less (一部)
0000000 213c 4f44 5443 5059 2045 5448 4c4d 5020
0000010 4255 494c 2043 2d22 2f2f 3357 2f43 442f
0000020 4454 4820 4d54 204c 2e33 2032 6946 616e
0000030 2f6c 452f 224e 0a3e 483c 4d54 3e4c 3c0a
0000040 4548 4441 0a3e 3c20 454d 4154 4e20 4d41
0000050 3d45 4722 4e45 5245 5441 524f 2022 4f43
0000060 544e 4e45 3d54 5322 4d47 2d4c 6f54 6c6f
0000070 2073 2e31 2e30 2239 0a3e 3c20 4954 4c54
0000080 3e45 7246 6d6f 5020 776f 7265 5520 2070
0000090 6f54 4220 7361 2068 7250 6d6f 7470 2f3c
00000a0 4954 4c54 3e45 200a 4c3c 4e49 204b 5248
00000b0 4645 223d 7246 6d6f 502d 776f 7265 7055
00000c0 542d 2d6f 6142 6873 502d 6f72 706d 2d74
00000d0 4f48 5457 2d4f 2e31 7468 6c6d 2022 4552
00000e0 3d4c 656e 7478 0a3e 0a0a 2f3c 4548 4441
00000f0 0a3e 423c 444f 3e59 3c0a 2041 5248 4645
0000100 223d 7246 6d6f 502d 776f 7265 7055 542d
0000110 2d6f 6142 6873 502d 6f72 706d 2d74 4f48
0000120 5457 2d4f 2e31 7468 6c6d 3e22 241b 3c42
0000130 2421 254e 215a 253c 1b38 4228 2f3c 3e41
0000140 1b0a 4224 3041 4e24 5a25 3c21 3825 281b
0000150 0a42 241b 4c42 3c5c 2421 1b58 4228 3c0a
0000160 5248 0a3e 483c 3e31 7246 6d6f 5020 776f
確実に 1b 24 42 が存在してるんですけど。(0000140のライン)
しかしこのテキストの問題点は漢字が最初の方には出て来ないということ。
ていうかそらそうだろうな。HTMLだし。
Konquerorがどの辺りの文字列を使用して文字を判別しているかという問題に辿りついた。
それはまだわかんね。
----
つーかね。
JISって種類ありすぎんのよ。わけわかめ。
でも素人目からするとこれで物足りない部分は全く無いと思われるのだが如何なるものか。
某Daicki氏に紹介された本 : http://www.amazon.co.jp/exec/obidos/ASIN/4320029046/
レッツ図書館だなこりゃ。
----
文字コードややこしすぎ。
師匠募集します(いるかんなもん
----
なんだかやたら盛況だな(w
コメントはじっくり眺めさせて頂きますm(_ _)m
hebohebo hantei program.
見ないで
師匠推薦 (スコア:1)
Re:師匠推薦 (スコア:1)
さて、問題となっている認識部分ですが、
もともとは私が書いたものですが、(ただし、文字コード判別部分はそのまま移植)
そんなにミスが多いですか?
使っているバージョンって、もしかしてCVS版で、
"View"->"Set Encoding"->"Automatic Detection"->"Semi-Automatic"
になってませんか。
"View"->"Set Encoding"->"Automatic Detection"->"Japanese"
にするとミスがほとんどなしになったりしませんか?
で、もし"Japanese"になっていてもミスする。
かつ、なんどReloadしてみても必ずミスするのならば、
コードに穴があるという事なので、チェック部の解析は益があるでしょう。
"Japanese"でミスるが、Reloadするとうまく行くことがあるという事ならば、
これは場合によっては仕方のない可能性があります。
(EUC, SJISの区別不可能なコード量だけで、判別させている場合)
(わかるまで保留するというコードにはしてなかったはず。忘れてるけど)
その場合は、EUCorSJISという内部コードをつくって、
文字コードの判別を後回しにするという仕組をつくってやればいいかも。
(JISをミスる可能性はまずないので、それはまた別の問題)
"Japanese"にするとOKならば、それは今みている場所とは別の問題。
ちなみに、Semi-Automaticはきちんと実装されてないはず。
ということで、FIXMEとなってるSemi-Automaticの認識部分をつくってやればOK。
本当に簡易的に済ますのなら、localeに合わせた自動認識ルーチンへ飛ばせてやればいいのかな。
(本来は汎用的なルーチンを書くべきでしょうが)
とりあえずは、こんなところで。
-- Che Che - Bye Bye
Re:師匠推薦 (スコア:1)
やはり、KHTMLの判定部分のコードを書いた方にお話いただこうかと。
私としては、「挙動的に、キャッシュを表示する時に判定がミスっているような」
という程度の理解しかないので。ということで、よろしくお願いします（ぉぃ
#文字コードの判定については、本当はQtに実装するのが正しい解なんでしょうが。
Re:師匠推薦 (スコア:1)
キャッシュの表示時にミスりやすいっていうのは妙な挙動ですねぇ。
キャッシュかどうかで処理は変化しませんし、
読み込み量が増えることが期待されるキャッシュでは判定材料は増える方向になりやすいんですが。
QAutoDetectCodecみたいなのがあればな、と考えたことはありますが、
単純に文字コード判定用ルーチンを用意するだけってわけには行かないんですよねぇ。
QTextStreamあたりの機能に持てばいいんでしょうが、
間違えたときはどうするか、
判定不能状態で文字コードを知る必要がでてきたらどうするか、
とか、考えていくと結構ややこしいというか。
なんといっても、汎用的な文字コード判別ルーチンは難しいですしね。
-- Che Che - Bye Bye
Re:師匠推薦 (スコア:1)
表現が正確でなかったです。一度見たページでミスが起こりやすく、
一つのパターンとしては、「戻る」で表示させた時に化けてるとか
そんな感じで、そこから類推しただけなので、実際は違うかもしれません。
#特定の条件下では、判定ルーチンが実行されてないのではないかと思ったので。
> QAutoDetectCodecみたいなのがあればな、と考えたことはありますが、
> 単純に文字コード判定用ルーチンを用意するだけってわけには行かないんですよねぇ。
QTextCodecあたりのstaticなメソッドとして持つのが妥当ではないか
とは思っているのですが、やはり簡単ではないでしょうね。最低限、
言語なり国なりは指定しないと。
Zaurus-ja関係者などから、「欲しいですね」という要望は聞いてるんですけど・・・。
Re:師匠推薦 (スコア:1)
で、これを読んでて思い出したんですが、
QTextCodec::heuristicContentMatch() [trolltech.com]やQTextCodec::codecForContent() [trolltech.com]なんかが、
まさにそのための関数でしたね。
日本語関連だけでもこの部分をきちんと動作するように実装してみるというのは手かも。
-- Che Che - Bye Bye
Re:師匠推薦 (スコア:1)
気になってはいたんですが、いろいろあって忘れちゃったんですよね・・・。
#何のせいで忙しかったのかも忘れてますし...
> QTextCodec::heuristicContentMatch()やQTextCodec::codecForContent()なんかが、
> まさにそのための関数でしたね。
そういえば、ありましたね。どういう挙動を想定しているのか、
どういう動作をするように実装すべきなのかよく分かっていないですが、
確かにこれを実装するというのは手ですね。
Re:師匠推薦 (スコア:1)
khtmlの日本語自動認識について [srad.jp]とQTextCodec::codecForContent()について [srad.jp]書いてみましたので、そちらを参照ください。
-- Che Che - Bye Bye
ちなみに (スコア:1)
1. jvimを使っていて、誤認識を経験した覚えがなかったから。
2. ライセンス的に問題なさそうだったから。
の2点です。
nkfを最初は使おうかと思いましたが、コードが分かりにくすぎたので断念。
私が改造する前は別の認識ルーチンを使ってありましたが、
(Kondara Linuxの何かのツール由来のコードだったとあやふやな記憶が)
そちらはASCIIだけの場合に、SJISかEUCか忘れましたが、
どちらかを返してしまうため、誤認識が生じていたという経緯があります。
kccは検討したかどうかすら、もう記憶になかったり…。
-- Che Che - Bye Bye