パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

bashがマルチバイト文字に正式対応」記事へのコメント

  • 重い (スコア:3, 興味深い)

    ただでさえメモリ食うし、重いbashがさらに肥大化。
    そんなに多バイト文字つかいたいんですか?

    まあ、メモリ一桁メガバイトの住人のたわごとか。
    --
    ------------------------- Excess and Obsolete
    • by Anonymous Coward
      とっても使いたいです…てゆうかばりばり使ってますが。
      # EUC-JP と Shift_JIS が混在するとどう振る舞うんだろう (^^;;
      • by Anonymous Coward
        あるユーザが ja_JP.eucJP を使って日本語ファイル名を作り、別のユーザが同じファイルシステムに ja_JP.sjis で日本語ファイル名を作るととーーっても悲しいことになりますね。
        • Re:重い (スコア:1, すばらしい洞察)

          by Anonymous Coward
          ISO-8859-x と UTF-8 でも同じですな ;-)
          所詮 filename は NULL と / を含まない バイト列。
          どっかで紳士協定が無いとね…
          • Big-5とか混じってもいやですね。

            ただ、ファイルシステムにファイル名を書き込むなら、そのファイルシステムでサポートするコーディングで格納するべきで、ロケール設定に従うのはちょっと変かなと思う。

            実際は、"UTF-8とかで、NULLと/を含まない文字列を許す(制御文字はダメだけど)"ほうが現実的ですよね。(問題起こしにくいですよね)

            # 当たり前なのかな
            # 変なこと言ってる?
            --
            M-FalconSky (暑いか寒い)
            親コメント
            • by Anonymous Coward on 2002年07月23日 22時48分 (#131776)

              ファイルシステムにファイル名を書き込むなら、そのファイルシステムでサポートするコーディングで格納するべきで、ロケール設定に従うのはちょっと変かなと思う。

              これはこれで納得できる考え方ではあります。普通に現実的解法を求めるなら、ほとんど必然的結論とすら言えるかもしれません。

              とはいえ、UNIXといえば昔から、カーネル内ではなるべくテキスト表現の方法に依存せず、単なるバイト列として生のまま処理しようとするところに特徴があったという考えもできます。例えばファイルの中身はある長さを持つバイト列というだけあって、カーネルはそれが「80文字レコード」だの「可変長文字レコード」だのといった構造を持っているかどうかは関知しません。UnixやWindowsなどはその点で同じ特徴を持っていますが、そうでないOSもあります。UnixとWindowsでは改行文字が違うと言われることもありますが、それはOSが何か改行文字を特別扱いしているというわけではなくて、それぞれのアプリケーションが特定のバイト列をどう改行と見なすかというだけの違いで、実はアプリケーション毎に異なった扱いでも(OSから見れば)構いません(少なくともUnixでは。Windowsではもしかすると特別扱いがあるのかもしれませんが、寡聞にして知りません)。

              ファイル名にしても同様で、伝統的Unixではディレクトリ中のファイル名は(必要ならNULで終端した)14バイト以内(その後もっと長くできるよう拡張された)の列と決まっていただけでした。ファイルシステム自体は、NULだけは特殊な意味を持っていたものの、あとは長さの制限だけしか持っておらず、それを守る限りは、アプリケーションが、ファイル名自身バイナリ列であるようなファイルを使っても、OSは気にしません(ただしカーネル内のnamei()関数が"/"を特別扱いするために、NULに加えて"/"も特別扱いになっています。これは、個人的にはUnixの齟齬の一つと思います)。

              しかしファイルシステムにlocaleを持ち込んでしまうと、アプリケーションの指定したファイル名というバイト列が、暗黙の内に別のバイト列に変換されてしまうわけで、これはせっかくの「単なるバイト列」という特徴を崩してしまう気がします。極端な話アプリケーションがファイル名自体がバイナリであるようなファイルを作る場合、あるlocaleの下では同一ではあっても、バイト列としては異なるファイル名に変換されてしまい、アプリケーションが不具合を起こすということもあるでしょう。(まあ、そんな変なファイル名をつける方が悪いというのは常識的には正しい指摘なのですが。)

              そういったわけで、私の個人的感情としては、Unixカーネルはあくまですべてを単なるバイト列として扱い、そこにテキスト表現を見いだすのはアプリケーションレベル以上だけにして欲しい、という気持ちがあります。カーネルはあくまでシンプルに、完全に予測可能な動作だけをするべし……。

              とはいえ、それでは実在のUnixは完全にテキスト表現から完全に独立だったかと言うと、まあ"/"の例もあるように、実際にはそうではないわけで。いわばUnixは「ASCIIとその拡張文字集合およびASCIIと矛盾しない文字符号系」を暗黙に仮定していたとも言えます。だとすると、この暗黙の制限を、より強く明示的にして、その強い制限の下ですべてのアプリケーションを書くことにするのも、Unixの延長としてはあながち不自然ではないのかもしれません。そういう意味では、例えば元コメントのように、

              > UTF-8とかで、NULLと/を含まない文字列を許す

              とかはアリなのかもしれません。これならば、アプリケーションがUTF-8として作ったファイル名というバイト列を、カーネルはそのままファイルシステムに格納すれば良いだけだからです。これがUnix的思想の自然な拡張として有り得る形であるという 証拠に、元々のUnix開発者がその後開発した(している)Plan9では、ファイルシステムはunicodeで統一されていると聞いています。(それにしても「何もunicodeでなくてもいいじゃないかぁ!」というanti-unicode派としての叫びはおいておいて……)

              何が言いたかったかと言うと、カーネルは暗黙の文字変換なんてせずに、あくまでアプリケーションの言うがままのバイト列を生のまま扱うことに徹するべきだと私は思う、ということです。そのためには、アプリケーションが(localeなどの)それぞれの解釈でファイルシステムを見るのは、別におかしなことではないが、それが嫌ならすべてのアプリケーションが(unicodeなどの)同一の解釈でファイルシステムを見ることに決めてしまっても良い、と。

              もっとも、ドラスティックな変更を避け、簡便に使うという目的にあっては、ファイルシステム自体がlocaleを持つという仕組みを否定するものではありません。また、最後ついでに言うと、Plan9みたいに統一するにしてもunicode

              親コメント
            • Re:重い (スコア:2, 参考になる)

              by numa (4467) on 2002年07月23日 18時22分 (#131605) ホームページ 日記
              ただ、ファイルシステムにファイル名を書き込むなら、そのファイルシステムでサポートするコーディングで格納するべきで、ロケール設定に従うのはちょっと変かなと思う。

              Windows NT/NTFS とかだと, ディスクに格納されるファイル名は Unicode で, かつプロセスが非 Unicode エンコーディングを使う場合に何を使うかという情報がプロセスの属性としてあるので,ファイル操作システムコールでファイル名としてどの文字エンコーディングが渡されるかが判定できます。それに対して UNIX の場合,「プロセスがファイル名文字列をどの文字エンコーディングで渡してくるか」という情報をカーネルレベルでもっていないので,変換しようにもできない。 (ロケール処理はライブラリレベルで実現されていて, カーネルレベルでは認識されていないので。)

              NFS とか FAT ファイルシステムとかのマウントのときに, 文字エンコーディングを指定できるようにした処理系もありますが, これは,どちらかといえば苦し紛れの策ですからね。

              親コメント

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...