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

重い

[manba256 (10135)]

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

まあ、メモリ一桁メガバイトの住人のたわごとか。

--
------------------------- Excess and Obsolete

Re:重い

[Anonymous Coward]

とっても使いたいです…てゆうかばりばり使ってますが。
# EUC-JP と Shift_JIS が混在するとどう振る舞うんだろう (^^;;

Re:重い

[Anonymous Coward]

あるユーザが ja_JP.eucJP を使って日本語ファイル名を作り、別のユーザが同じファイルシステムに ja_JP.sjis で日本語ファイル名を作るととーーっても悲しいことになりますね。

Re:重い

[Anonymous Coward]

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

Re:重い

[M-FalconSky (8868)]

Big-5とか混じってもいやですね。

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

実際は、"UTF-

--
M-FalconSky (暑いか寒い)

Re:重い

[numa (4467)]

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

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

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