◀一般トップへ
  • 3455 UTF-7の自動判別止められないすか？
    • 3456 判定方法を見直します．
      • 3457 Re:判定方法を見直します．
        • 3458 Re2:判定方法を見直します．
          • 3459 Re3:判定方法を見直します．
      • 3461 Re:判定方法を見直します．
        • 3462 Re2:判定方法を見直します．

  • [3455] UTF-7の自動判別止められないすか？ ｓけいし 2003年11月03日 06:16

    Cのプログラムのエディットに便利に遣わさせて頂いてます。

    ファイルを開くときに　なぜかUTF-7と判別されるファイルが
    ありまして困ってます。
    http://winump.sourceforge.jp/sakura_mondai.zip


    気づかずそのまま編集すると＋が＋－になったり他が
    文字化けしたりで、とんでもないことになります。
    もちろんコンパイルエラーがでまくります。

    ”+R○->ほにゃらら”がいけないみたいで
    ”+(R○->ほにゃらら)”にしたらなおるようです。

    自動判別機能の見直しが難しいなら、
    せめてオフにできるようにしてほしいです。

    • [3456] 判定方法を見直します． げんた 2003年11月03日 15:39

      以前もこの話が出たときは「記号の前後にスペースいれないと見にくいだろー」とごまかしたような気がします．しかし他人のソースだとそうも言っていられませんよね．

      RFC2152 http://www.faqs.org/rfcs/rfc2152.html によると直接記入して良い文字から =(等号), \(バックスラッシュ), ~(チルダ)の3文字が除外されていますので，これらの文字が現れたときは必ず「UTF-7ではありえない」と判定するように判定をより厳しくします．

      たぶん等号が1つも現れないCソースってのはあまり無いでしょうから関数本体はこれでほぼ大丈夫ではないでしょうか．

      しかしC++のヘッダファイルで return var1+hoge->foobar; みたいなアクセスメソッドと宣言のみが来てしまうとやばいかも．そういうときは+の後ろにスペース入れて逃げてもらう...じゃだめか...

      http://sakura-editor.sourceforge.net/snapshot/sakura_2003-11-03_UTF7.zip バイナリ置いておきますのでお試しください．

      • [3457] Re:判定方法を見直します． じゅうじ 2003年11月03日 16:18

        ▼ げんたさん
        > 以前もこの話が出たときは「記号の前後にスペースいれないと見にくいだろー」とごまかしたような気がします．しかし他人のソースだとそうも言っていられませんよね．
        > http://sakura-editor.sourceforge.net/snapshot/sakura_2003-11-03_UTF7.zip

        ご無沙汰しております。
        早速ですが、問題解決になっていない様です。
        ４個のファイルで試しましたが、２番目と３番目が駄目です。
        [rever5ok.txt]
        ++REVERB-
        [rever7.txt]
        +REVERB-
        [rtsyn1.txt]
        ++RTSYN-
        [rtsyn2ok.txt]
        +RTSYN-

        なお、ファイルの最後に改行は必要ありません。

        • [3458] Re2:判定方法を見直します． げんた 2003年11月03日 17:47

          >ご無沙汰しております。
          >早速ですが、問題解決になっていない様です。
          >[rever7.txt]
          >+REVERB-
          >[rtsyn1.txt]
          >++RTSYN-

          まずはじめに上の文字列がUTF-7であるかないかはそこだけ見てもわかりませんので，全体としてUTF-7らしいかどうかを判定するときにUTF-7で「無い」証拠があればUTF-7ではないと見なしましょうとしたつもりなのですが．その上で，=をUTF-7でない証拠と見なすことで大抵のCソースでは問題を回避できるのではないかなと考えたわけです．
          ですから，上の文字列がUTF-7であるかどうかはそこだけ見ても判定不能かと思います．

          ただ，rtsyn1.txtの++となっている部分はUTF-7としては変なので，そこが原因でカウントされているとすればカウント対象外とすべきかも．さらなる判定精度向上についてはもう一度RFC見直して考えてみます．

          • [3459] Re3:判定方法を見直します． じゅうじ 2003年11月03日 22:48

            ▼ げんたさん
            > まずはじめに上の文字列がUTF-7であるかないかはそこだけ見てもわかりませんので，全体としてUTF-7らしいかどうかを判定するときにUTF-7で「無い」証拠があればUTF-7ではないと見なしましょうとしたつもりなのですが．その上で，=をUTF-7でない証拠と見なすことで大抵のCソースでは問題を回避できるのではないかなと考えたわけです．
            > ですから，上の文字列がUTF-7であるかどうかはそこだけ見ても判定不能かと思います．

            多分ですが、
            UTF-7で開けるファイルは、全てSJISで開けるのであれば、UTF-7を自動判定に入れない方法も有ると思います。

            diff -U 2 "E:\Program Files\Sakura\ssrc_2003-10-13\sakura_core
            \CMemory.cpp"
            @@ -2544,5 +2544,6 @@
            ||日本語コードセット判別: UTF-7か？
            */
            - CMemory::CheckKanjiCode_UTF7( pBuf, nBufLen, &nUTF7MojiNum, &nUTF7CodeNum );
            + nUTF7MojiNum = nUTF7CodeNum = 0;
            +// CMemory::CheckKanjiCode_UTF7( pBuf, nBufLen, &nUTF7MojiNum, &nUTF7CodeNum );

            if( nEUCCodeNum > 0

            終了コード: 1

      • [3461] Re:判定方法を見直します． ｓけいし 2003年11月04日 02:37

        早速の対応ありがとうございます。
        ちゃんと開けることを確認しました。

        ＞「記号の前後にスペースいれないと見にくいだろー」
        なぜ醜いソースになったかというと、TiMidity++の変数・関数
        呼び出しを構造体を使った方法に改造の途中で
        何も考えずどんどん自動で置き換えていったからでした。

        この手の作業ではさくらエディタは非常に強力ですね。

        完全な自動判別が難しいのであれば、やはり開くファイルの
        種類を固定するオプションをつけてほしいです。
        プログラムソースの場合、コメントが読めないときに他の形式で
        開きなおすのはそれほど苦ではないですから。

        • [3462] Re2:判定方法を見直します． げんた 2003年11月05日 02:21

          >完全な自動判別が難しいのであれば、やはり開くファイルの
          >種類を固定するオプションをつけてほしいです。
          特定の文字コードに固定するコマンドラインオプションは既に存在します．-CODE=0 でSJIS固定になります(ヘルプ参照)．ただし単純にショートカットにオプションを付けてそこにファイルをドラッグしてもオプションが無視されますので注意．右クリックメニューに「SJISで開く」とか入れるのが良いかなと思います．