パスワードを忘れた? アカウント作成

kzk (16011) の日記

2004 年 01 月 27 日
午後 11:16

Konqueror[文字判別] - UTF8編 - part2

khtml/misc/decoder.cppにUTF8判別サポートを組み込んでみような計画。

コード表なんかと睨めっこしてみたがイマイチ良い方法(判別方法)が思い浮かばなかった。
してるうちに、こんなもんがあるのを思い出した。

で、さっそくShiro Kawai氏作のguess_jpをkhtmlを組み込んでみました。(diffは下)
UTF-8もしっかり認識してくれる賢い奴です。
ただライセンスがBSD。これってGPLなソフトウェアに組み込めるんでしょうか?

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

----------------------------------------------------------

面倒だが本人に聞いたが早いな。

----------------------------------------------------------

というわけでShiro Kawaiさんに直接聞きました。
「ライセンスの表記をどこかに入れておいて頂ければこちらは構いません。」とのことなので、後はkfm-develにでも投げて採用されればヤッターという感じですか。

#というかこの人acmの人なんだ。
#チューリング賞とか決めるんだろうか。すげ

----------------------------------------------------------

「HEADにcommit済です」

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Daicki (4060) on 2004年01月28日 0時08分 (#482517) 日記
    いわゆる修正BSDライセンスなら、(L)GPLなコードに含めるのは
    問題なしです。逆は問題がありますが。
    #もちろん、コピーライトは残す必要があります。

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

    あっ、微妙な間違いがあるかもしれないので、
    一応いろいろ調べてみてください。特にGPLのFAQとか。
    • by Anonymous Coward
      http://www.gnu.org/licenses/license-list.ja.html

      一応調べてみました。
      Daickiさんのおっしゃられてる通り、修正BSDライセンスならOKなようです。
      作者様にも連絡を取りましたし、後は本家に投げるだけって感じです。
      • by Daicki (4060) on 2004年01月28日 21時05分 (#483064) 日記
        本家に投げるなら、具体的に失敗していたサイトを示して、
        それが上手く表示できるってことを見せたほうが良いかも。
        親コメント
        • by kzk (16011) on 2004年01月28日 21時56分 (#483094) 日記
          ん、一旦設定消したのでなんか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 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
          親コメント
          • by Daicki (4060) on 2004年01月28日 22時29分 (#483115) 日記
            > ん、一旦設定消したのでなんかACになってましたね。すません。

            まあ、内容で大体推測できたので大丈夫です。


            > とりあえず文面はこんな感じです。

            こんだけスラスラ英語が書けるのはうらやましい限り(苦笑
            なので、文面自体には特に言うことは無いです。

            強いて言うと、もしかすると、表がよく理解できなくて、
            突っ込みが入る可能性があるかもしれないですねえ。
            なので、その可能性は頭の隅に置いておいたほうが良いかも。


            しかし、この時期にこんなことしていて大丈夫かな?(汗

            親コメント
          • ざっと、パッチを見てみました。

            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
            親コメント
            • by kzk (16011) on 2004年01月30日 18時36分 (#484723) 日記
              お久しぶりです。

              >* 他の言語用の判定ルーチンは 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]に投げてしまったのでアドバイスだけ受け取らせて頂きます(@_@;
              まぁ予想通り無反応な訳ですが。
              親コメント
              • by Anonymous Coward

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

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

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

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

              • by kzk (16011) on 2004年01月31日 0時43分 (#485044) 日記
                長文どうもですm(_ _)m
                一応指摘されたものは全部直してみました。

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

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

                DIFF : http://mover.cool.ne.jp/others/trivialpatches/add_ja-utf8detection_to_khtml-ver3.diff
                親コメント
              • by Anonymous Coward
                パッチを見てみましたが、ESCが来た時の処理が変ですね。
                私が言っていたのはESCが文字列の最後の場合(i >= buflen-1)です。
                その場合に、前回の最終文字列がESCということを記憶して、次回の呼出時の先頭バイトでJISのシーケンスかのチェックを行なうということです。
                このパッチだとJIS_escape == trueな場合はKanjiCode::JISを返していますので、次回の呼
              • by kzk (16011) on 2004年02月01日 19時41分 (#485769) 日記
                あ、そいうことでしたか。
                ちょっと意味を汲み取れてませんでした、すません(@_@;

                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さんですよね?
                親コメント
              • by Anonymous Coward
                パッチの変更箇所で一点だけ。

                last_JIS_escapeの処理ですが、 C == 0x1b の場合も last_JIS_escape == true の場合も全く同じ処理をしているため、last_JIS_escape == true の場合に、一文字飛ばして判定してしまいます。
                (c == 0x1b || last_JIS_escape)で判断した直後、last_JIS_escapeならi--してやるのが良いでしょう。(他の手法もありますので、うまく動くようならどの形でも構いません)
                他はとくに問題ないと思います。(とかいいつつ、一度も実行しての
              • by Daicki (4060) on 2004年02月02日 12時21分 (#486136) 日記
                > #お蔭様で当初よりかなり良いパッチに仕上ってしまいました
                > #こうなるとなんとしてもコミットしたい所です
                > #勝手にコミットしちゃっても良いものなんでしょうかね?(汗

                ちと質問なんだけど、もしかしてcvsのcommit権限持ってるの?
                親コメント
              • by kzk (16011) on 2004年02月02日 23時30分 (#486717) 日記
                > ちと質問なんだけど、もしかしてcvsのcommit権限持ってるの?
                えぇ。一応。
                親コメント
              • by kzk (16011) on 2004年02月02日 23時33分 (#486721) 日記
                、キ、゙、テ、ソ。ェ
                、ロ、ネテ擎ユホマフオ、、、ヌ、ケ。」ネソセハ。」

                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、ホ・チ・罕ヘ・ 、ホハ 、ヌ、ケ。シ。」
                ク昀キ、ッ、隍ヲ、ハノスクス、ヌ、ケ、、、゙、サ、」
                親コメント
              • by Daicki (4060) on 2004年02月03日 18時25分 (#487398) 日記
                committer様とは知らなんだ...
                親コメント
              • by Anonymous Coward
                OKです。コミットしてください。

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

                -- Takumi ASAKI
              • by kzk (16011) on 2004年02月03日 21時43分 (#487555) 日記
                コミット完了。

                #長々とお付き合い有難うございましたm(_ _)m
                親コメント
              • by kzk (16011) on 2004年02月03日 21時46分 (#487558) 日記
                「様」というとあれですが、メール一通で誰でもなれる訳で。。。
                親コメント
              • by Daicki (4060) on 2004年02月04日 20時02分 (#488641) 日記
                > メール一通で誰でもなれる訳で。。。

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

                「様」については、「お代官様」の「様」と同義です(謎
                親コメント
              • by Anonymous Coward
                コミット後にあれですが、どうやらこの認識ルーチンに問題があるようです。
                というのは、ASCIIのデータを食わせるとSJISと判定されて返ってきているようで、そのためこのルーチンをこのまま利用しているとkhtmlでは誤認識が増大する可能性があります。

                対処
              • by kzk (16011) on 2004年02月05日 1時03分 (#488935) 日記
                有難う御座います。
                ライセンスで色々言われたのでそっちが落ち着いたら対処しますね。

                一応こんな感じで。

                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 | }
                親コメント
              • by Anonymous Coward
                問題があるのはそこではなくて、guess_jpの中です。その場所の変更は必要ありません。というか、してはいけません。
                済みません。もうちょっとちゃんと説明した方が良かったですね。

                単体でいろいろテストするとわかりますが、guess_jp()にASCIIだけで構成された文字列を渡しても、ASCIIではなく、SJIS
              • by kzk (16011) on 2004年02月06日 1時47分 (#489902) 日記
                俺も単体で色々テストしてみました。
                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の前に追加する感じで対処。
                親コメント

アレゲはアレゲを呼ぶ -- ある傍観者

処理中...