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

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

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

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

    まあ、メモリ一桁メガバイトの住人のたわごとか。
    --
    ------------------------- Excess and Obsolete
    • by Anonymous Coward on 2002年07月23日 7時16分 (#131171)
      とっても使いたいです…てゆうかばりばり使ってますが。
      # EUC-JP と Shift_JIS が混在するとどう振る舞うんだろう (^^;;
      親コメント
      • by kubota (64) on 2002年07月23日 8時37分 (#131197) ホームページ 日記
        「混在」というのが、よくわからないんですが、

        ja_JP.SJIS ロケールでは、いわゆる半角カナも含めて、 Shift_JIS を正しく扱います。

        ただし、ふつうは ja_JP.SJIS ロケールなんてのが用意されてない だろうから、localedef コマンドを使って作らないといけません。

        親コメント
        • あれ? ja_JP.SJISちゃんと動きますか?
          bash-2.05b$ echo 表表
          とかすると、2byte目の0x5cが悪さするんですが。
          --
          Just a whisper. I hear it in my ghost.
          親コメント
          • うーん、うちでは、うまくいってますけど。(Debian sid です)

            $ ls /usr/lib/locale/
            de_DE en_US.utf8 fr_FR@euro  ja_JP.sjis ko_KR.euckr 
            en_US fr_FR    ja_JP.eucjp ja_JP.utf8 ru_RU.koi8r
            $ echo $LANG
            ja_JP.SJIS
            $ echo 表表
            表表
            $ echo 表表 | od -t x1
            0000000 95 5c 95 5c 0a
            0000005
            $

            ヒストリとか、カーソル移動とか、編集も問題ありません。

            親コメント
          • こちらの環境では動きました。ロケールがうまく生成されてないとかでしょうか?
            $ export LANG=ja_JP.SJIS
            $ bash
            $ echo 表表
            表表
            $ echo 噂

            $
        • ja_JP.SJIS ロケールは,作成可能でしょうか。

          最近流行の,Shift_JIS を厳密に解釈することを求める立場からすると, 0x5C のコードポイントにある文字 (\) は,Shift_JIS ではバックスラッシュ (REVERSE SOLIDUS) ではなくて円記号 (YEN SIGN) です。 そして,ISO C にしろ,POSIX にしろ,バックスラッシュのコードポイントがロケールによって動的に変わってしまう状況は想定していないはずなので, たとえ charmap ファイルは作成可能にしても, それを実際に運用するのは難しいと思います。

          たとえば,0x5C の文字は Shift_JIS では円記号だからエスケープ文字ではないはずなのに,プログラムによってエスケープ文字と解釈されたり(しなかったり)するとか。もっとも
          LANG=ja_JP.SJIS; export LANG
          とかやったとたんに,既存のシェルスクリプトが軒並み動かなくなったりするのも困りますけどね :)

          いや,もちろん,堅いことを言わなければ使えるのはわかりますよ。

          親コメント
          • CP932 (スコア:2, 興味深い)

            by kubota (64) on 2002年07月23日 15時02分 (#131502) ホームページ 日記
            既存のシステムでこの問題をてっとりばやく片付ける方法は、Shift_JIS の代わりに CP932 を使うことです。

            CP932 は、日本語版 Windows で使われている文字コードで、(JIS X 02xx の世界から見れば) Shift_JIS にいわゆる「機種依存文字」を追加したものです。が、ミソは、Unicode から見たとき、Shift_JIS と CP932 はそれ以上の差異があるという点です。

            それは、CP932 と Shift_JIS とでは、Unicode への変換テーブルに一部相違がある、という点です。そのひとつの例として、CP932 では、0x5c は U+005C に変換されます。ほか、JIS X 0208 に属する文字にも、いくつか相違があります。

            問題は、日本語版 Windows では、U+005C は円記号だったりすることなんだけど、いまのところそれは関係ないし。

            親コメント
            • by Anonymous Coward
              内容としては参考になるのですが、

              > 最近流行の,Shift_JIS を厳密に解釈することを求める立場

              の人に

              > 既存のシステムでこの問題をてっとりばやく片付ける方法は、Shift_JIS の代わりに CP932 を使うことです。

              というのは、返答としてどうかな?と思います。

              それはともかく、Single Unix Specification の該当項 [opengroup.org]を読んでみましたが、
              Escape Character って確かに Bac
          • ISO 646 を知っていれば、そういう結論にはなりません。
            Unicode が絡むとまともに処理するのが難しいものの、
            それをちゃんと解決できないのは実装がヘボイだけ、
            というそしりを免れるものではありません。
            • by Anonymous Coward on 2002年07月23日 14時37分 (#131491)
              > ISO 646 を知っていれば、そういう結論にはなりません。

              とか書いたんですけど、よくよく考えてみるとそんな単純な
              話でもないのかなぁ、と思い始めたりして。

              どうもこの辺は実装依存の話で、Single Unix Spec あたりを見ても
              厳密には書いてないのですけど、Portable charset としては確かに、
              \ として reverse solidus とか backslash とか書いてあるんですよね。

              一方で、伝統的な ja_JP.SJIS では、JIS X 0201 Roman は
              ISO 646 の思想に従って \ を ISO 646-IRV のそれと同質に
              解釈するのが普通だったりしますな。

              結局、そこは実装依存という話なので、一概に言い切れない、
              という話ですね。失礼しました。
              親コメント
              • 一方で、伝統的な ja_JP.SJIS では、JIS X 0201 Roman は
                ISO 646 の思想に従って \ を ISO 646-IRV のそれと同質に
                解釈するのが普通だったりしますな。

                苦し紛れにそういうことをしていたのは事実ですが, それは「ISO 646 の思想」というほど 確乎としたものなのでしょうか。 ISO 646 は ASCII をもとにした符号化文字集合で, 「各国版 (National version)」として一部の文字を入れ替えた版を作ることを許してはいましたが, そのうちの入れ替えられた文字を別の National version の文字 あるいは「国際参照版 (IRV)」と同等に解釈してよいという規定はなかったと思います。

                たとえば,日本版では 0x5C は「円記号」ですが, 韓国版ではこれは「ウォン記号」になります。 これを一緒にされたら困るでしょう。 貨幣価値も一桁くらい違うし :-)

                親コメント
            • 補足。#131459 は #131427 へのコメントね。
      • by Anonymous Coward
        あるユーザが ja_JP.eucJP を使って日本語ファイル名を作り、別のユーザが同じファイルシステムに ja_JP.sjis で日本語ファイル名を作るととーーっても悲しいことになりますね。
        • Re:重い (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2002年07月23日 14時15分 (#131463)
          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 ファイルシステムとかのマウントのときに, 文字エンコーディングを指定できるようにした処理系もありますが, これは,どちらかといえば苦し紛れの策ですからね。

              親コメント

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

処理中...