◀一般トップへ
  • 3294 パスにunicodeを含む場合のファイルの開き方
    • 3296 Re:パスにunicodeを含む場合のファイルの開き方
      • 3297 Re2:パスにunicodeを含む場合のファイルの開き方
        • 3303 Re3:パスにunicodeを含む場合のファイルの開き方
          • 3305 Re4:パスにunicodeを含む場合のファイルの開き方
            • 3307 Re5:パスにunicodeを含む場合のファイルの開き方
              • 3309 Re6:パスにunicodeを含む場合のファイルの開き方
                • 3310 Re7:パスにunicodeを含む場合のファイルの開き方
                  • 3311 Re8:パスにunicodeを含む場合のファイルの開き方
                    • 3312 Re9:パスにunicodeを含む場合のファイルの開き方
                      • 3315 Re10:パスにunicodeを含む場合のファイルの開き方
  • [3294] パスにunicodeを含む場合のファイルの開き方 ハク 2003年09月16日 01:49

    はじめまして、サクラエディタ使わせて頂いております。
    いきなり質問で申し訳ないのですが
    題にある通りパスにunicodeが含まれるフォルダがある場合
    unicode文字が「?」と認識されてしまい、
    開くことが出来ない状態です。
    これは現在の仕様なのでしょうか?

    ちなみにnotepadではうまく(unicodeを)認識してくれます

    過去ログを検索したのですが特に無いようなので
    質問させて頂きました。
    既出、もしくは設定等で変更可能でしたら
    申し訳ありません。m(_ _)m
    • [3296] Re:パスにunicodeを含む場合のファイルの開き方 wmlhq 2003年09月16日 11:24

      ▼ ハクさん
      > 題にある通りパスにunicodeが含まれるフォルダがある場合
      > unicode文字が「?」と認識されてしまい、
      > 開くことが出来ない状態です。

      現状ではSJISコードのパスしか開けない仕様です。よろしければ、ドライブのフォーマット形式とWindowsのバージョンを教えてください。ドライブのフォーマット形式は「マイコンピュータ」からドライブを選択して「プロパティ」をクリックすると見れます。
      • [3297] Re2:パスにunicodeを含む場合のファイルの開き方 ハク 2003年09月16日 12:46

        了解です。
        環境が二つあるため(会社と自宅)両方載せておきます。
        両方とも同じく再現します。
        ・Windows2000 sp4
        FAT32
        ・WindowsXPPro sp1
        NTFS

        となっております。
        もし情報が不足していましたらご指摘ください。

        余談なのですがやはり実装は難しいのでしょうか。
        たしか2000以降と9xシリーズでは文字コードの扱いが違ってたはず(・・だと思います(汗))
        notepadはWinごとに対応すればいいから楽でしょうけど・・
        • [3303] Re3:パスにunicodeを含む場合のファイルの開き方 wmlhq 2003年09月17日 11:56

          ▼ ハクさん
          > unicode文字が「?」と認識されてしまい、
          このあたりをもう少し詳しく。文字化けが起こる文字とか、どんな風に表示されるかとか。
          • [3305] Re4:パスにunicodeを含む場合のファイルの開き方 ハク 2003年09月17日 17:22

            ▼ wmlhqさん
            > > unicode文字が「?」と認識されてしまい、
            > このあたりをもう少し詳しく。文字化けが起こる文字とか、どんな風に表示されるかとか。

            自分がフォルダ名に使用した文字はUnicode:0x2620(ドクロマークみたいなやつ)です。
            サクラ自身の出すエラーダイアログは上記のまんまUnicode部分が「?」と表示されます。
            (例:D:\temp\?UG資料室?\hoge.txt など)
            またサクラ自身にクリップボード貼り付け等を行っても「?」と表示されます。

            > 文字化けが起こる文字とか
            これに関してはShift_JIS表に該当しない文字は「?」となると思います。
            サクラ自身のソースは拝見したことがないため詳しくはつっこめませんが・・(^^;
            • [3307] Re5:パスにunicodeを含む場合のファイルの開き方 wmlhq 2003年09月18日 13:21

              開発者の方々へ。そもそもvfatも内部でUnicodeを使っているので、CreateFileW,CreateFileMappingW,GetCommandLineWなどを使うべき。MS Officeでもそのように実装しているはず。win95でもGetCommandLineWは例外的にサポートされているが、その他の関数では下位互換性を保つため、失敗時にGetLastError()==ERROR_NOT_IMPLEMENTEDならばANSIバージョンを呼ぶよう、修正すること。_accessや_lopenなどは古い関数なので、使わない形に修正すべき。いずれにしても、CFile{Read,Write}の周辺は、例外や余分なコードを無くして大幅に修正すべき。
              • [3309] Re6:パスにunicodeを含む場合のファイルの開き方 すい 2003年09月19日 01:34

                なんだかファイルのread/write周りの事しか書いてないみたいですけど。

                サクラエディタは単純に編集対象のファイルを読み書きしているだけじゃ
                なくて、あちこちで様々なパス文字列の処理をしているわけで。

                例えば具体例を挙げると、ダイレクト タグ ジャンプなんかだと、
                ダイレクト タグ ジャンプのための tagsファイルが編集中のファイルと
                同じディレクトリに無い場合、1階層親階層のディレクトリの中から
                tags を探し、無ければ更に1階層親階層のディレクトリの中から...
                とかやっていて、それらの親階層たどる処理とかがバリバリの
                Shift_JIS テキスト処理でやられています。

                この程度だけなら まだ かわいいのですが、この類のパス文字列に対する
                Shift_JIS 依存テキスト処理がエディタ中のあちこちに散在しているんじゃ
                ないかと思うのですが...
                それらも全て直さないと駄目という事になるんじゃないでしょうか?

                あと、タイトルバー表示の編集中ファイル名とか。ここも Unicode 処理にするのかな?
                マクロは?「編集中ファイル名の取得機能では Unicode 特有文字は化ける仕様です」と割り切るのかな?
                メニューは?過去に編集したファイル。「ファイル(F)→最近使ったファイル(F)」とか、
                「ファイル(F)→最近使ったフォルダ(D)」とか。
                Grep の対象のファイル・フォルダ とかは? 他、ダイアログ諸々。設定画面とか。
                まぁ表示だけなら「 Unicode特有の文字は表示が化けるけど我慢して」でも
                済むかもしれませんけど、、、
                「最近使ったファイル」の一覧だとかは sakura.ini に保存されるわけで、
                ここも Unicodeで保存しなくてはならなくなるのでは?
                Unicode特有文字部が化けたら「最近使ったファイル」から開けなくなっちゃいますからね。
                でもそうなると sakura.ini も Unicode にしないと駄目じゃ...
                ファイルの履歴などのパス部分だけ Unicode で格納するのか? → Shift_JIS Unicode 混在テキスト?(汗)
                それとも sakura.ini 全部を完全に Unicode にしちゃうの? → それで問題出ない?

                とか。

                単純に
                「Unicode特有文字をパス中に含むファイルは、とりあえず開く事と
                 保存する事だけは出来る。」
                という仕様で割り切って良いならファイルread/write部だけの修正で
                済むかもしれませんけど、Unicode特有の文字をパスに含むファイルの
                編集中には、正常に動作しない機能があちこち噴出しそうですよね。
                # ↑んで、それが「編集しているファイルによってはコレコレの機能が
                # 動作しません」とかってユーザーからバグ扱い報告されそうです。

                ちょっと考えただけでも“全面改修”とまではいかないかもしれませんが、
                エディタ全体に渡る かなり大規模な改修になりそうに思えるのですが。
                意外にあちこちでパス文字列を参照・加工・利用していると思いますので...
                ...誰がやるんでしょう?
                • [3310] Re7:パスにunicodeを含む場合のファイルの開き方 wmlhq 2003年09月19日 11:29

                  マジレス。
                  > サクラエディタは単純に編集対象のファイルを読み書きしているだけじゃ
                  > なくて、あちこちで様々なパス文字列の処理をしているわけで。
                  劇的に同意。

                  > Shift_JIS 依存テキスト処理がエディタ中のあちこちに散在..(中略)..
                  > それらも全て直さないと駄目
                  すべてではありませんが、ほとんどすべてです。

                  > あと、タイトルバー表示の編集中ファイル名とか。ここも Unicode 処理にするのかな?
                  > 「ファイル(F)→最近使ったフォルダ(D)」とか。
                  > Grep の対象のファイル・フォルダ とかは?
                  言い忘れましたが、当然そうなります。

                  > 編集中ファイル名の取得機能では Unicode 特有文字は化ける
                  CF_UNICODETEXT形式を用意するまでだ! と思ったが、内部形式がSJISなので表示は駄目。

                  > sakura.ini も Unicode にしないと駄目じゃ...
                  「バイナリ埋め込み」かDOS形式に。

                  > 編集中には、正常に動作しない機能があちこち噴出しそうですよね。
                  > かなり大規模な改修になりそう
                  > ...誰がやるんでしょう?
                  諸君の健闘を祈る(爆)。
                  • [3311] Re8:パスにunicodeを含む場合のファイルの開き方 すい 2003年09月20日 03:57

                    >> 編集中ファイル名の取得機能では Unicode 特有文字は化ける
                    >CF_UNICODETEXT形式を用意するまでだ! と思ったが、内部形式がSJISなので表示は駄目。

                    これはマクロ中での「編集中ファイル名の取得機能」の話をしているのですが。
                    マクロ中では Shift_JIS しか扱えませんよね。
                    WSH が使えるようになれば WSH 部では Unicode も問題なく扱えるようになるかもしれませんが、
                    残念ながらまだ WSHは まともに動作しないわけですし。

                    >> sakura.ini も Unicode にしないと駄目じゃ...
                    >「バイナリ埋め込み」かDOS形式に。

                    DOS形式(8.3形式のMS-DOSファイル名ですよね)は以下の2点より却下。

                    理由1
                     「MS-DOSファイル名」と「ロングファイル名」の対応は入れ替わることがある。

                     例えば FAT のドライブにて、以下のようにファイルが2個ある場合、
                     ・C:\foo\textfile-1.txt ← MS-DOSファイル名は TEXTFI~1.TXT
                     ・C:\foo\textfile-2.txt ← MS-DOSファイル名は TEXTFI~2.TXT
                     で、過去に C:\foo\textfile-1.txt をエディタで編集し、C:\foo\TEXTFI~1.TXT と
                     エディタの履歴に記憶されているとします。その後、
                     1.この2個のファイルを他のフォルダに移動する。
                     2.textfile-2.txt を先に元の C:\foo\ に戻す。
                     3.次に textfile-1.txt を元の C:\foo\ に戻す。
                     と作業すると、ファイル名は
                     ・C:\foo\textfile-1.txt ← MS-DOSファイル名は TEXTFI~2.TXT
                     ・C:\foo\textfile-2.txt ← MS-DOSファイル名は TEXTFI~1.TXT
                     と、MS-DOSファイル名が入れ替わってしまいます。(あくまでFATの場合ですよ)
                     その後、エディタで textfile-1.txt を開こうとすると、エディタは
                     C:\foo\TEXTFI~1.TXT を開こうとする → 開かれるのは textfile-2.txt になる。。。
                     別のファイルが開かれるじゃん、と。

                    理由2
                     Windows NT系 + NTFS の環境では、MS-DOSファイル名が存在しない場合がある。
                     デフォルトの設定では常に全てのファイルに対してMS-DOSファイル名を生成して付加
                     していくようになっていますが、設定を変えればMS-DOSファイル名を一切付けないように
                     する事が可能です。(レジストリ NtfsDisable8dot3NameCreation)
                     この場合、昔の“ロングファイル名を扱えないプログラム”等からファイルの読み書きが
                     出来なくなります( GetShortPathName() なんかも失敗する)が、代わりに若干
                     パフォーマンスが向上します。

                     こういう設定で使用している環境において使えないエディタになってしまうのでは?

                    MS-DOSファイル名の使用は何かとトラブルの元になりますので、
                    純Windowsアプリでは MS-DOSファイル名は利用すべきではないかと。
                    • [3312] Re9:パスにunicodeを含む場合のファイルの開き方 wmlhq 2003年09月21日 14:20

                      いずれにしてもUnicode化は先送りということですね。続きは開発掲示板で。
                      • [3315] Re10:パスにunicodeを含む場合のファイルの開き方 すい 2003年09月24日 08:53

                        >いずれにしてもUnicode化は先送りということですね。続きは開発掲示板で。

                        その開発掲示板の過去ログを見て頂ければわかると思いますが、、、
                        過去に Unicode化の計画が話し合われています。
                        その時はファイル名関連だけではなく、文字列編集等も含めたフルUnicode化の話だったわけですが...

                        ただ、あまりにも作業量が多く、部分毎に切り分けて少しずつ、一部分ずつUnicode化していく
                        というのも難しく(全部まとめてゴソっとやるしか...)、結局、事実上の計画頓挫状態
                        とでもいうのが今の状況なわけで。
                        新規機能追加時などに、将来のUnicode化を考慮したプログラミングにしておく、とか、
                        将来のUnicode化のために一部 少しだけ変更、とか、細々とした対応はされてはいますが。

                        よっぽどパワーと時間がある人が登場しない限りUnicode化は無理かと。