[4554] お試し版でのアプリケーションエラーについてげんた 2006年08月29日 08:12

文字コード自動認識を入れ換えたお試し版でgrepを行うとアプリケーションエラーになることがあります．
mapファイルがあるバージョンで再現したのでアドレスを調べたところ，charcode.cppのCheckEucJpChar()に不正なアドレスが渡されているようでした．

[4555] Re:お試し版でのアプリケーションエラーについて ryoji 2006年08月29日 23:10

まだ使い込みが足りないせいか、自分の環境ではいまのところエラーには出くわしていません。
何か条件があるんでしょうかね？
- [4556] Re2:お試し版でのアプリケーションエラーについてげんた 2006年08月30日 01:06
  
  >まだ使い込みが足りないせいか、自分の環境ではいまのところエラーには出くわしていません。
  >何か条件があるんでしょうかね？
  私は，海外物のソフトのソースコードにgrepを掛けたときに発生しました．
  しかし，職場のPCでは発生するのに自分のPCでは発生しません．
  そして，これまた困ったことにDebug buildで試しましたが全然発生しませんでした．
  
  ちなみに，渡されたアドレスの周辺をVisual Studioのメモリダンプで見たら?? ?? ??でしたので，メモリマップから外れたアドレスなのでしょう．ですが，charcode.cppでとんでもなく外れたアドレスが渡される可能性があるんでしょうか？？
  
  実に謎です．
  - [4557] Re3:お試し版でのアプリケーションエラーについてラスティブ 2006年08月30日 13:57
    
    遅ればせながら，
    ご無沙汰しております．
    
    デバッグビルドでは通るがリリースビルドで落ちる…
    ということは，charcode.cpp のどこかで
    変数の初期化が抜けている可能性があります．
    
    SourceForge Patches にも
    いろいろとご指摘いただいておりますのに，
    こちら少々お取り込み中でして；；
    環境が整い次第修正を入れようと思います～
    - [4559] ん，わかったかもげんた 2006年08月31日 10:31
      
      落ちたときのスタックダンプからCheckEucJpCharが nLen=0 で呼びだされていることがわかりました．
      nLen = 0ということはバッファのデータを全て読み終わった後ですよね．
      ということは，pSはバッファの末尾の次を指しているのでアクセスしてはまずいはず．
      int CheckEucJpChar( const uchar_t* pS, const int nLen )
      {
      　　uchar_t uc = *pS; <--- ここ！
      
      　　if( 0 < nLen ){
      　　　　if( (uc & 0x80) == 0 ){
      　　　　　　// ASCII またはローマ字です. (JIS X 0201 Roman.)
      
      なので，1文字読み出すのは長さ判定より後ろになくてはなりません．
      - [4587] Re:ん，わかったかもラスティブ 2006年09月21日 16:18
        
        CheckEucJpChar() 内で落ちるバグの修正パッチを，
        Patches#1513775 の方にアップしました．
        
        # 追伸：
        # Visual C++ 6.0 で最新のソースコードをコンパイルしようとすると，
        # sakura_core\CPropTypesKeyHelp.cpp(284) : error C2065: 'ListView_SetCheckState' : 定義されていない識別子です。
        # と出てコンパイルできなかったので，
        # http://www14.cds.ne.jp/~neg/pro/piyo1/clc/lvscs.html
        # このページを参考にしてコンパイルのテストをしました…．
        
        [4588] 自動判別精度げんた 2006年09月23日 00:55
        
        最近，ラスティブさんの自動判別が入ったファイルを使っているのですが，EUCのファイルをよくUnicodeと誤判別されてしまいます．
        ほとんど英数字のファイルとかソースコードで，たまにEUCで日本語が入っていたり，謎のバイナリデータがちょろっと混ざっているようなデータです．
        
        日本語が少ないと，SJIS/EUC/JISに比べてUnicodeに大きく加点されてしまうのでしょうか．
        現行のアルゴリズムではUnicodeへの誤判別というのはあまり無かったように感じます．
        
        [4590] Re:自動判別精度ラスティブ 2006年09月23日 12:17
        
        ユニコード固有値として認識される値の範囲を
        狭めたものを Patches #1513775 の方にアップしました．
        
        ▼ げんたさん
        > 日本語が少ないと，SJIS/EUC/JISに比べて
        > Unicodeに大きく加点されてしまうのでしょうか．
        > 現行のアルゴリズムではUnicodeへの誤判別というのは
        > あまり無かったように感じます．
        
        そうとは言い切れないところがありそうです．
        Unicode として検査したときに不正な値が１バイトも
        見つからず，それ以外の文字コードでみたときは
        すべて不正バイトが検出された場合に，Unicode と
        判別されてしまう，つまり，特有バイト数より
        不正バイト数の方を優先的にみていることが
        原因となっているかもしれず…；；
        
        [4596] Re2:自動判別精度げんた 2006年09月26日 23:54
        
        誤判別はEUCの半角かなの部分が不正な文字としてカウントされていたことが原因のようです．
        修正してテスト版を作り直しました．
        http://sakura.qp.land.to/?Junk%2F1
        
        ▼ ラスティブさん
        >ユニコード固有値として認識される値の範囲を
        >狭めたものを Patches #1513775 の方にアップしました．
        こちらはあんまり関係なかったみたいです．
        
        ▼ ラスティブさん
        >不正バイト数の方を優先的にみていることが
        >原因となっているかもしれず…；；
        例えばSJISの中に何かの都合でEUCが混ざっているようなファイルを開くと，SJIS, EUCともに不正バイトが検出され，どちらでもないUnicodeで開かれてしまう可能性がありますよね．判定時にまず不正バイトの文字数を比較していますが，不正な文字数が同じになるケースというのはほとんど0ではないでしょうか．とすると不正な文字が出た時点でアウト．
        
        SJIS，EUC，JISあたりで間違われる分には良いのですが，Unicodeに間違われると改行が改行とみなされないので全部1行になってしまうのが気持ち悪いですし，
        
        例えばある程度の長さの文書であれば改行が入っているのが当然．と仮定するとCRLFがたくさん入っていたら文字列的にはUnicodeと解釈できてもUnicodeではないだろうとか，そういうのも考慮に入れることはできないでしょうか．
        
        [4597] 本日の誤判定げんた 2006年09月29日 00:19
        
        本日も誤判定に遭遇したので一応書いておきます．
        
        1. ファイルに0xff 0xff 0xff 0xffが含まれるASCIIファイル．
        1バイト系のコードはこの4バイト全てが不正文字になったのですが，
        最初の0xffの前にスペースがあったので，Unicodeでは中央のffffのみが不正と判断されて不正文字は2バイト．
        よってUnicodeで開かれてしまいました．
        
        2.欧米のアクセント文字が混ざっていたアスキーファイル
        問題の文字は1文字だけだったのですが，EUC/SJISどちらでも不正な文字だったためにUnicodeで開かれてしまいました．
        
        ということで，日本語主体の場合はよいのですが，1バイト文字主体の場合にUnicode行きになりやすいです．
        
        しかし，単純に文字集合に入っているかどうかだけでは判断は無理かなと感じています．
        
        [4598] Re:本日の誤判定ラスティブ 2006年10月01日 12:17
        
        >>dev:4596
        > 誤判別はEUCの半角かなの部分が不正な文字として
        > カウントされていたことが原因のようです．
        
        >>dev:4597
        > 1. ファイルに0xff 0xff 0xff 0xffが含まれるASCIIファイル．
        > 1バイト系のコードはこの4バイト全てが不正文字に
        > なったのですが，最初の0xffの前にスペースがあったので，
        > Unicodeでは中央のffffのみが不正と判断されて
        > 不正文字は2バイト．
        > よってUnicodeで開かれてしまいました．
        >
        > 2.欧米のアクセント文字が混ざっていたアスキーファイル
        > 問題の文字は1文字だけだったのですが，
        > EUC/SJISどちらでも不正な文字だったために
        > Unicodeで開かれてしまいました．
        
        不具合ご報告ありがとうございます～．
        暫定パッチを Patches #1513775 の方にアップしました．
        Unicode への誤判別に関しては，
        作り間違ってたところが主な原因だったようでした；；
        
        >>dev:4596
        > JISの中に何かの都合でEUCが混ざっているような
        > ファイルを開くと，SJIS, EUCともに不正バイトが
        > 検出され，どちらでもないUnicodeで開かれてしまう
        > 可能性がありますよね．
        
        Charcode::DetectEncodingType 関数が入力データを
        Unicode または Unicode BE と判別した場合，
        入力データの不正バイトが検出されていないときは
        DetectEncodingType の判別結果に従い，
        検出されているときは SJIS を返すようにしていますので，
        この例の場合，どちらでもない Unicode で開かれる可能性は
        低いにしても…，EUC と UTF-8 の組み合わせとかなら，
        どちらでもない SJIS で開かれる可能性があります，はい．
        
        Unicode または Unicode BE が判別候補に出る場合は，
        もう一つ Unicode 以外の候補を見つけるようにすると
        解決できるような気がします．
        が，この問題に関してはしばらくかかりそうです；；
        
        >>dev:4596
        > 例えばある程度の長さの文書であれば改行が入って
        > いるのが当然．と仮定するとCRLFがたくさん入って
        > いたら文字列的にはUnicodeと解釈できても
        > Unicodeではないだろうとか，そういうのも考慮に
        > 入れることはできないでしょうか．
        
        新たに構造体を定義して改行情報も含められるよう，
        コツコツやってこうかと思います．
        
        [4599] Re2:本日の誤判定 maru 2006年10月04日 00:29
        
        ▼ ラスティブ
        仮にUnicodeとして有効バイトが大多数なら、不正バイトが少しくらい(１％未満とか)あっても素直にUnicodeで開いてほしい気もします。
        
        > 改行が改行とみなされないので全部1行…
        > CRLFがたくさん入っていたら…
        ここ賛成です。
        
        ▼ げんたさん
        > Properyページに詳細を出す
        これは評価版専用の機能ですよね。
        サイズが０ＫＢのファイルでプロパティを表示すると強制終了してしまうので。
        
        [4600] Re3:本日の誤判定げんた 2006年10月04日 00:50
        
        >サイズが０ＫＢのファイルでプロパティを表示すると強制終了してしまうので。
        あ，本当だ．０でわり算しちゃいます．
        
        ここはDEBUGコードなので普通は使われないのですが，直した方がいいですね．

[4554] お試し版でのアプリケーションエラーについて げんた 2006年08月29日 08:12

[4555] Re:お試し版でのアプリケーションエラーについて ryoji 2006年08月29日 23:10

[4556] Re2:お試し版でのアプリケーションエラーについて げんた 2006年08月30日 01:06

[4557] Re3:お試し版でのアプリケーションエラーについて ラスティブ 2006年08月30日 13:57

[4559] ん，わかったかも げんた 2006年08月31日 10:31

[4587] Re:ん，わかったかも ラスティブ 2006年09月21日 16:18

[4588] 自動判別精度 げんた 2006年09月23日 00:55

[4590] Re:自動判別精度 ラスティブ 2006年09月23日 12:17

[4596] Re2:自動判別精度 げんた 2006年09月26日 23:54

[4597] 本日の誤判定 げんた 2006年09月29日 00:19

[4598] Re:本日の誤判定 ラスティブ 2006年10月01日 12:17

[4599] Re2:本日の誤判定 maru 2006年10月04日 00:29

[4600] Re3:本日の誤判定 げんた 2006年10月04日 00:50

[4554] お試し版でのアプリケーションエラーについてげんた 2006年08月29日 08:12

[4556] Re2:お試し版でのアプリケーションエラーについてげんた 2006年08月30日 01:06

[4557] Re3:お試し版でのアプリケーションエラーについてラスティブ 2006年08月30日 13:57

[4559] ん，わかったかもげんた 2006年08月31日 10:31

[4587] Re:ん，わかったかもラスティブ 2006年09月21日 16:18

[4588] 自動判別精度げんた 2006年09月23日 00:55

[4590] Re:自動判別精度ラスティブ 2006年09月23日 12:17

[4596] Re2:自動判別精度げんた 2006年09月26日 23:54

[4597] 本日の誤判定げんた 2006年09月29日 00:19

[4598] Re:本日の誤判定ラスティブ 2006年10月01日 12:17

[4600] Re3:本日の誤判定げんた 2006年10月04日 00:50