「Konqueror[文字判別] - UTF8編 - part2 (committed)」記事へのコメント

BSDライセンス

[Daicki (4060)]

いわゆる修正BSDライセンスなら、(L)GPLなコードに含めるのは
問題なしです。逆は問題がありますが。
#もちろん、コピーライトは残す必要があります。

Webを調べれば、いろいろと事例があるんじゃないかな。

あっ、微妙な間違いがあるかもしれないので、
一応いろいろ調べてみてください。特にGPLのFAQとか。

Re:BSDライセンス

[Anonymous Coward]

http://www.gnu.org/licenses/license-list.ja.html

一応調べてみました。
Daickiさんのおっしゃられてる通り、修正BSDライセンスならOKなようです。
作者様にも連絡を取りましたし、後は本家に投げるだけって感じです。

Re:BSDライセンス

[Daicki (4060)]

本家に投げるなら、具体的に失敗していたサイトを示して、
それが上手く表示できるってことを見せたほうが良いかも。

Re:BSDライセンス

[kzk (16011)]

ん、一旦設定消したのでなんかACになってましたね。すません。
実は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 cau

Re:BSDライセンス

[asataku (2091)]

ざっと、パッチを見てみました。

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ライセンス

[kzk (16011)]

お久しぶりです。

>* 他の言語用の判定ルーチンは 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ライセンス

[Anonymous Coward]

これに対して改善したパッチを作りましたので覗いてみて下さい。
HEADに対するパッチです。

特に問題はないと思います。

んとQBufferとかを用意しておいて次にdecodeが呼ばれる時にdataに繋げるという感じでよろしいでしょうか？
最後がマルチバイト文字の1バイト目とか、2バイト目以降から始まっているバイト列とかをどうやって判断するのかが分からなかったり。すいません、ちっとお時間を下さい。

現在のkhtmlのルーチンでも境界の対処はしてませんのでおそらく大きな問題はないと思いますが、そういった場合の認識がどのようになるかの確認をしておけば多少安心になるかと。

Re:BSDライセンス

[kzk (16011)]

長文どうもですm(_ _)m
一応指摘されたものは全部直してみました。

が、やはりこれ以上はという感じですね。
文字列が全て来てからdecodeを呼ぶようにするとか、他の場所をいぢるしかなさそうですね。
この場所で処理する問題ではなさそうな気がします。

#お蔭様で当初よりかなり良いパッチに仕上ってしまいました
#こうなるとなんとしてもコミットしたい所です
#勝手にコミットしちゃっても良いものなんでしょうかね？(汗

DIFF : http://mover.cool.ne.jp/others/trivialpatches/add_ja-utf8detection_to_khtml-ver3.diff

Re:BSDライセンス

[Anonymous Coward]

パッチを見てみましたが、ESCが来た時の処理が変ですね。
私が言っていたのはESCが文字列の最後の場合(i >= buflen-1)です。
その場合に、前回の最終文字列がESCということを記憶して、次回の呼出時の先頭バイトでJISのシーケンスかのチェックを行なうということです。
このパッチだとJIS_escape == trueな場合はKanjiCode::JISを返していますので、次回の呼

Re:BSDライセンス

[kzk (16011)]

あ、そいうことでしたか。
ちょっと意味を汲み取れてませんでした、すません(@_@;

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ライセンス

[Anonymous Coward]

パッチの変更箇所で一点だけ。

last_JIS_escapeの処理ですが、 C == 0x1b の場合も last_JIS_escape == true の場合も全く同じ処理をしているため、last_JIS_escape == true の場合に、一文字飛ばして判定してしまいます。
(c == 0x1b || last_JIS_escape)で判断した直後、last_JIS_escapeならi--してやるのが良いでしょう。(他の手法もありますので、うまく動くようならどの形でも構いません)
他はとくに問題ないと思います。(とかいいつつ、一度も実行しての

Re:BSDライセンス

[Daicki (4060)]

> #お蔭様で当初よりかなり良いパッチに仕上ってしまいました
> #こうなるとなんとしてもコミットしたい所です
> #勝手にコミットしちゃっても良いものなんでしょうかね？(汗

ちと質問なんだけど、もしかしてcvsのcommit権限持ってるの？

Re:BSDライセンス

[kzk (16011)]

> ちと質問なんだけど、もしかしてcvsのcommit権限持ってるの？
えぇ。一応。

Re:BSDライセンス

[kzk (16011)]

､ｷ､ﾞ､ﾃ､ｿ｡ｪ
､ﾛ､ﾈﾃ擎ﾕﾎﾏﾌｵ､､､ﾇ､ｹ｡｣ﾈｿｾﾊ｡｣

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ライセンス

[Daicki (4060)]

committer様とは知らなんだ...

Re:BSDライセンス

[Anonymous Coward]

OKです。コミットしてください。

#kde-develの件は、あとから読み返していて気がつきました。^^;

-- Takumi ASAKI

Re:BSDライセンス

[kzk (16011)]

コミット完了。

#長々とお付き合い有難うございましたm(_ _)m

Re:BSDライセンス

[kzk (16011)]

「様」というとあれですが、メール一通で誰でもなれる訳で。。。

Re:BSDライセンス

[Daicki (4060)]

> メール一通で誰でもなれる訳で。。。

そうなのか。何らかの審査基準が存在しているのだと思ってました。

「様」については、「お代官様」の「様」と同義です（謎

Re:BSDライセンス

[Anonymous Coward]

コミット後にあれですが、どうやらこの認識ルーチンに問題があるようです。
というのは、ASCIIのデータを食わせるとSJISと判定されて返ってきているようで、そのためこのルーチンをこのまま利用しているとkhtmlでは誤認識が増大する可能性があります。

対処

Re:BSDライセンス

[kzk (16011)]

有難う御座います。
ライセンスで色々言われたのでそっちが落ち着いたら対処しますね。

一応こんな感じで。

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ライセンス

[Anonymous Coward]

問題があるのはそこではなくて、guess_jpの中です。その場所の変更は必要ありません。というか、してはいけません。
済みません。もうちょっとちゃんと説明した方が良かったですね。

単体でいろいろテストするとわかりますが、guess_jp()にASCIIだけで構成された文字列を渡しても、ASCIIではなく、SJIS

Re:BSDライセンス

[kzk (16011)]

俺も単体で色々テストしてみました。
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の前に追加する感じで対処。