When I use Konqueror(khtml), I noticed that khtml doesn't regard the UTF8
encoding at all.
So, in browsing the web, so-called "Mojibake" is often occurred.
"Mojibake" is caused by failing the character encoding, and makes the
documents completely unreadable.
Please look at this url
(http://www.debian.or.jp/~kubota/mojibake/web-browsers-200307.html), and
probably you, who use alphabet only may be surprised :-P
Encoding detection code of KHTML is in kdelibs/khtml/misc/decoder.cpp, and the
routine(judge_jcode) comes from "JVim", the Japanese localized version of
vim.
Then, I search this routine's effectiveness and I found the surprising fact.
This routine hardly detect UTF-8 encoding correctly.
Here is the list.
This routine is used in "Gauche", the scheme interpreter.
As soon as I found this routine, I wrote a patch for KHTML(attached to this
mail).
This code is BSD license and I contacted the author of this routine and he
said ok to use in KHML unless copyright is in the source file.
BSDライセンス (スコア:1)
問題なしです。逆は問題がありますが。
#もちろん、コピーライトは残す必要があります。
Webを調べれば、いろいろと事例があるんじゃないかな。
あっ、微妙な間違いがあるかもしれないので、
一応いろいろ調べてみてください。特にGPLのFAQとか。
Re:BSDライセンス (スコア:0)
一応調べてみました。
Daickiさんのおっしゃられてる通り、修正BSDライセンスならOKなようです。
作者様にも連絡を取りましたし、後は本家に投げるだけって感じです。
Re:BSDライセンス (スコア:1)
それが上手く表示できるってことを見せたほうが良いかも。
Re:BSDライセンス (スコア:1)
実はkde-develに登録した方のアドレスの送信用stmp鯖がいつのまにか廃止(汗)になってたようで投げれません(笑)
投げたつもりが届いてない。アリエネェ
新しいアドレスでsubscribeしたのですが、メールも届かないし。
明日にすることにします。
とりあえず文面はこんな感じです。
Hi, I'm a Japanese KDE user.
When I use Konqueror(khtml), I noticed that khtml doesn't regard the UTF8
encoding at all.
So, in browsing the web, so-called "Mojibake" is often occurred.
"Mojibake" is caused by failing the character encoding, and makes the
documents completely unreadable.
Please look at this url
(http://www.debian.or.jp/~kubota/mojibake/web-browsers-200307.html), and
probably you, who use alphabet only may be surprised :-P
Encoding detection code of KHTML is in kdelibs/khtml/misc/decoder.cpp, and the
routine(judge_jcode) comes from "JVim", the Japanese localized version of
vim.
Then, I search this routine's effectiveness and I found the surprising fact.
This routine hardly detect UTF-8 encoding correctly.
Here is the list.
[Jvim:judge_jcode]
UTF-8: succeed 16.23% (29927/184344) fail EUCJP: 13.45% SJIS: 70.31%
SJIS: succeed 99.78% (183937/184344) fail EUCJP: 0.09% UTF-8: 0.13%
EUCJP: succeed 100.00% (184343/184344) fail UNKNOWN: 0.00%
ISO2022JP: succeed 100.00% (184344/184344)
bench time: 27.651628
And I search some other Japanese encoding detection routine and found the best
one.
[Gauche:Guess.guess]
UTF-8: succeed 96.11% (177166/184344) fail EUCJP: 3.89%
SJIS: succeed 99.58% (183569/184344) fail EUCJP: 0.17% UTF-8: 0.25%
EUCJP: succeed 100.00% (184344/184344)
ISO2022JP: succeed 100.00% (184341/184344) fail EUCJP: 0.00%
bench time: 28.26122
This routine is used in "Gauche", the scheme interpreter.
As soon as I found this routine, I wrote a patch for KHTML(attached to this
mail).
This code is BSD license and I contacted the author of this routine and he
said ok to use in KHML unless copyright is in the source file.
Is it OK to commit this?
cheers.
Kazuki Ohta : mover@hct.zaq.ne.jp
Re:BSDライセンス (スコア:1)
まあ、内容で大体推測できたので大丈夫です。
> とりあえず文面はこんな感じです。
こんだけスラスラ英語が書けるのはうらやましい限り（苦笑
なので、文面自体には特に言うことは無いです。
強いて言うと、もしかすると、表がよく理解できなくて、
突っ込みが入る可能性があるかもしれないですねえ。
なので、その可能性は頭の隅に置いておいたほうが良いかも。
しかし、この時期にこんなことしていて大丈夫かな？（汗
Re:BSDライセンス (スコア:1)
一応今日も図書館こもって9時間程して来たんですが。。。。
息抜きも必要です(ぉ
Re:BSDライセンス (スコア:1)
DFA_NEXTとかがマクロなのが趣味じゃないですが、それはともかくとして、
* マルチバイト文字の区切りが中途半端なバイト列が渡された場合(最後がマルチバイト文字の1バイト目とか、2バイト目以降から始まっているバイト列とか)の動作については確認しておいてもいいと思います。
* 他の言語用の判定ルーチンは Decoder::automaticDetectionForXXXX() などとなっているので、それにあわせて Decoder::automaticDetectionForJapanese() を作って、同じようにしたほうが見栄えがいい?
(ただし、他の言語用の関数のように、判定できない場合に"ISO-8859-1"などを返すのはやめたほうがよい)
(このパッチ [kde.gr.jp]がある程度参考になるかも)
報告用の文章ですが、regardでなくても、detectでいいかな。Mojibake云々もなくてもわかってもらえそう。
それから、jvimのルーチンのUTF-8の判定率の話はいりません。現状のkhtmlのコードにはUTF-8関連のルーチンは一切入っていませんので、逆に混乱する可能性があります。UTF-8を認識しないから、こっちのほうがいいでいいでしょう。
それから、なぜ、日本語のときのみにUTF-8の判定を行うのかを説明しておいたほうがいいかもしれません。UTF-8なら全言語でやったほうがいいのではと思うでしょうから。
-- Che Che - Bye Bye
Re:BSDライセンス (スコア:1)
>* 他の言語用の判定ルーチンは Decoder::automaticDetectionForXXXX() などとなっているので、
> それにあわせて Decoder::automaticDetectionForJapanese() を作って、同じようにしたほうが見栄えがいい?
> (ただし、他の言語用の関数のように、判定できない場合に"ISO-8859-1"などを返すのはやめたほうがよい)
これに対して改善したパッチを作りましたので覗いてみて下さい。
HEADに対するパッチです。
DIFF : http://mover.cool.ne.jp/others/trivialpatches/add_ja-utf8detection_to_khtml-ver2.diff
> * マルチバイト文字の区切りが中途半端なバイト列が渡された場合(最後がマルチバイト文字の1バイト目とか、2バイト目以降から始まっているバイト列とか)の動作については確認しておいてもいいと思います。
んとQBufferとかを用意しておいて次にdecodeが呼ばれる時にdataに繋げるという感じでよろしいでしょうか？
最後がマルチバイト文字の1バイト目とか、2バイト目以降から始まっているバイト列とかをどうやって判断するのかが分からなかったり。すいません、ちっとお時間を下さい。
報告の方ですが、既に[kde-core-devel]に投げてしまったのでアドバイスだけ受け取らせて頂きます(@_@;
まぁ予想通り無反応な訳ですが。
Re:BSDライセンス (スコア:0)
特に問題はないと思います。
現在のkhtmlのルーチンでも境界の対処はしてませんのでおそらく大きな問題はないと思いますが、そういった場合の認識がどのようになるかの確認をしておけば多少安心になるかと。
Re:BSDライセンス (スコア:1)
一応指摘されたものは全部直してみました。
が、やはりこれ以上はという感じですね。
文字列が全て来てからdecodeを呼ぶようにするとか、他の場所をいぢるしかなさそうですね。
この場所で処理する問題ではなさそうな気がします。
#お蔭様で当初よりかなり良いパッチに仕上ってしまいました
#こうなるとなんとしてもコミットしたい所です
#勝手にコミットしちゃっても良いものなんでしょうかね？(汗
DIFF : http://mover.cool.ne.jp/others/trivialpatches/add_ja-utf8detection_to_khtml-ver3.diff
Re:BSDライセンス (スコア:0)
私が言っていたのはESCが文字列の最後の場合(i >= buflen-1)です。
その場合に、前回の最終文字列がESCということを記憶して、次回の呼出時の先頭バイトでJISのシーケンスかのチェックを行なうということです。
このパッチだとJIS_escape == trueな場合はKanjiCode::JISを返していますので、次回の呼
Re:BSDライセンス (スコア:1)
ちょっと意味を汲み取れてませんでした、すません(@_@;
DIFF : http://mover.cool.ne.jp/others/trivialpatches/add_ja-utf8detection_to_khtml-ver4.diff
で、コミットの方ですが、#kde-develで直接聞いてきた所によると、original codeの作者にOKを貰ったということをcvsのlogにのせれば良いらしいです。
Branchにはバイナリ互換が無いとコミットできないみたいなのですが、HEADならOKな模様です。
ここの部分をお書きになったのってAsakiさんですよね？
Re:BSDライセンス (スコア:0)
last_JIS_escapeの処理ですが、 C == 0x1b の場合も last_JIS_escape == true の場合も全く同じ処理をしているため、last_JIS_escape == true の場合に、一文字飛ばして判定してしまいます。
(c == 0x1b || last_JIS_escape)で判断した直後、last_JIS_escapeならi--してやるのが良いでしょう。(他の手法もありますので、うまく動くようならどの形でも構いません)
他はとくに問題ないと思います。(とかいいつつ、一度も実行しての
Re:BSDライセンス (スコア:1)
> #こうなるとなんとしてもコミットしたい所です
> #勝手にコミットしちゃっても良いものなんでしょうかね？(汗
ちと質問なんだけど、もしかしてcvsのcommit権限持ってるの？
Re:BSDライセンス (スコア:1)
えぇ。一応。
Re:BSDライセンス (スコア:1)
､ﾛ､ﾈﾃ擎ﾕﾎﾏﾌｵ､､､ﾇ､ｹ｡｣ﾈｿｾﾊ｡｣
450 | /* special treatment of jis escape sequence */
451 | if (c == 0x1b || last_JIS_escape) {
452 | if (i < buflen-1) {
453 | if (last_JIS_escape)
454 | c = (unsigned char)buf[i];
455 | else
456 | c = (unsigned char)buf[++i];
457 | last_JIS_escape = false;
458 |
459 | if (c == '$' || c == '(') {
460 | return JapaneseCode::JIS;
461 | }
462 | } else {
463 | last_JIS_escape = true;
464 | }
､ｳ､ ､ﾇ､隍惕ｷ､ｱ､ ､ﾐｺﾇｽｪOKｲｼ､ｵ､､｡｣
､｢｡｢ｸ #kde-devel､ﾃ､ﾆmailing list､ｸ､网ﾊ､ｯ､ﾆIRC､ﾎ･ﾁ･罕ﾍ･ ､ﾎﾊ ､ﾇ､ｹ｡ｼ｡｣
ｸ昀ｷ､ｯ､隍ｦ､ﾊﾉｽｸｽ､ﾇ､ｹ､､､ﾞ､ｻ､｣
Re:BSDライセンス (スコア:1)
Re:BSDライセンス (スコア:0)
#kde-develの件は、あとから読み返していて気がつきました。^^;
-- Takumi ASAKI
Re:BSDライセンス (スコア:1)
#長々とお付き合い有難うございましたm(_ _)m
Re:BSDライセンス (スコア:1)
Re:BSDライセンス (スコア:1)
そうなのか。何らかの審査基準が存在しているのだと思ってました。
「様」については、「お代官様」の「様」と同義です（謎
Re:BSDライセンス (スコア:0)
というのは、ASCIIのデータを食わせるとSJISと判定されて返ってきているようで、そのためこのルーチンをこのまま利用しているとkhtmlでは誤認識が増大する可能性があります。
対処
Re:BSDライセンス (スコア:1)
ライセンスで色々言われたのでそっちが落ち着いたら対処しますね。
一応こんな感じで。
479 | switch ( kc->guess_jp( (const char*)ptr, size ) ) {
480 | case JapaneseCode::ASCII:
481 | return "ascii";
482 | case JapaneseCode::JIS:
483 | return "jis7";
484 | case JapaneseCode::EUC:
485 | return "eucjp";
486 | case JapaneseCode::SJIS:
487 | return "sjis";
488 | case JapaneseCode::UTF8:
489 | return "utf8";
490 | default:
491 | break;
492 | }
Re:BSDライセンス (スコア:0)
済みません。もうちょっとちゃんと説明した方が良かったですね。
単体でいろいろテストするとわかりますが、guess_jp()にASCIIだけで構成された文字列を渡しても、ASCIIではなく、SJIS
Re:BSDライセンス (スコア:1)
ASCIIの場合3つともscoreが1.0になってしまって、<=になっているSJISが判定されていますねぇ。
102 | if (eucj->score == 1.0 && sjis->score == 1.0 && utf8->score == 1.0)
103 | return JapaneseCode::ASCII;
これをambiguousの前に追加する感じで対処。