ja_JP.UTF-8

Linux で ja_JP.UTF-8 ロケールで暮らす方法についてのスレです。

そういや自宅では玄箱を utf8 にしてるな。
たまに Windows マシンから samba でアクセスするが、それは
ちゃんと設定してあってファイル名は玄箱側に utf8 で書かれる
ようになっている。通常は utf8 になっている Linux マシン
から nfs (autofs) で一部をマウントして使っている。

ftp ねえ。でも ftp を使ったとしても ftp クライアントが
utf8 のファイル名に対応してさえいればいいんだよね。
そういうのってまだないのかな?

8bitスルーなら問題ないでしょ。
readline使ったヤツとか。

利用者側にftpクライアントを指定する時点で不合格じゃない？

>>249
んなこたねえと思うが。

素朴な疑問なんだけど、ある文字が何カラムになるかがロケールで決定できる
と考えるのがそもそもの間違いであって、TerminfoとかTermcapみたいな物に
そこら辺を全部面倒みて貰う方がすっきりするんじゃないの？
ここで言ってる文字幅って結局端末に依存する情報でしょ？

できるかどうかは知らんけど

文字幅? 一応 Unicode には Halfwidth と名前の付いた文字はあるけどな。
まあ、端末やプリンタで等幅の時に半分で出ることが期待された文字という
ことなんだろうが、こんな半角文字は早く消えて欲しいものだ。

別にいわゆる半角文字に限らなくてもいいんでない？
端末によっては表示できない文字だってあるだろうし、それをどう扱うかは
端末が勝手に決めればいいんじゃないの？
結果として端末によっては、?で表示されたり、〓で表示されたり、\uXXXXで
エスケープして表示されたりするかもしれないけど、それって端末の勝手だよね？
最終的に端末で表示した時にズレなきゃそれでいいんだし、ロケールで面倒
みる必要はないと思うんだけどな。
まあ、代替文字として何が表示されてるか分からないと困る場合はあるかも
しれないから、そういう時は代替文字を端末データベースに問い合わせて
教えて貰えればそれで済むんじゃない？
なんかおかしな事言ってる？

Unicode Standard Annex #11
East Asian Width
http://www.unicode.org/unicode/reports/tr11/

Draft Unicode Technical Report #30
Character Foldings
http://unicode.org/reports/tr30/

合字があるから、面倒くさいんだよ。

>>216-222
内部を覗いて見ないと分からないけど、
Win32 API では、"\" が本則っぽいな。

ファイル名の先頭に \\?\ を付けると解釈が厳格になる。
その時、"/" を受けつけなくなる。


NTFS と VFAT はファイル名は UTF-16 で格納すると決まっていて、
API やカーネル内部も UTF-16 で統一されてるから、
その点では頭を抱えずに済んでる。

Debian の次期バージョンは UTF-8 らしいけど、どんな感じになるだろう。

UNICODE も弱点は多いけど他の良い手段が思い当たらないので、
UNICODE 自身の改良に期待するしかないと思っている。

>>256 馬鹿発見

バックスラッシュと\が同じ文字コードだったとか
聞いた気がしたんだが…

勘違い？

で？

>>258
バックスラシュと\は同じコードだけど、
スラッシュと\は違うコードで、
今回の話しはスラッシュと\の話しね。

>>260
> バックスラシュと\は同じコードだけど、

ムチャ言うなよ。

>>260
http://ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C

俺、今、Linux からおちゅ〜しゃでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w

俺、今、英語版Windows からIEでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w

俺、今、(かん高い声で！)、navi2ch！

>>262
僕もそこを見た上でレスした。
UNICODEでは本来は 半角の＼ と 半角の￥ が区別されるのは知っているよ。
しかし、

> Unicodeを利用するアプリケーションは
> 0x007F以下のコードに関しては移動させないと言う
> 暗黙のルールができている。

この事実があるから区別されてないと書いたわけです。
（Windows も Linux も区別していない。）

>>261
ムチャなことが現実になっているから
小さいながら問題になってしまっているのが悩ましい。

WAVE DASH - FULLWIDTH TILDE問題
は、海外のCDDBを利用する僕も影響を受けている。

>>266
区別していない？バックスラッシュとバックスラッシュは同じ文字なのに、どう区別するんだよ？

何がどういう風に問題なのかわからん。

SJISはともかく、EUC-JPも使い分けられないんだっけ?
ISO-2022-JPは問題ないよね。

iso-2022-jp の半角部分は jis x 0201 だから、
\ は円マークだよ。
euc-jp は半角カナ以外の半角部分は ascii らしいので
\ はバックスラッシュだと思う。

>>270
前半は嘘というかミスリーディングというか……、
ISO-2022-JPがASCIIを書けないとでも思ってんのかいな。
生半可な聞きかじりを垂れ流す前に考えるなり調べるなりしような。

Emacsで新しいファイルを作って、次の一行を入れて保存し開き直してみ。
\^[(J\^[(B
(^[はESCなのでEmacsだとC-q ESCで入力)
一つめはバックスラッシュに、二つめは円記号になるから。

すまん。
http://ja.wikipedia.org/wiki/ISO-2022-JP
ここに書いてなかったから勘違いしたよ。
http://www.ietf.org/rfc/rfc1468.txt
こっちみたらちゃんと ascii 入ってるわ。

http://www.iana.org/assignments/character-sets

>>272
「ISO646の国際基準版図形文字」って ASCII のことだろ？

ASCIIは、ISO646-USじゃん。
http://www.asahi-net.or.jp/~yw3t-trns/code/iso646.html

>>275
irv と比べてどこが違うの？

UTF-8な環境を結構長く使っているけど、いまだに
解決できないのがEmacsでギリシャ文字を使おうとすると
なぜか「全角」の文字上のカーソル移動が「半角」単位に
なって、編集ができなくなってしまうこと。

このあたりのノウハウ集みたいなのって、ないですかね・・・

>>277
それ emacs だけでなることではないのでは?
wcswidth()が返す値が既におかしいとか端末の問題なのでは?

-nwなの?

あ、たしかにコマンドラインでもなるね。
いままで文書書く時とか emacs -nw な中でしかそういった文字
使おうとしたことがなかったから気づいてなかった。

Debian GNU/Linux (sid) な環境で Putty(UTF-8-CJK) 経由で
使ってるんだけど、これはしょうがないのかな？

端末エミュレータの問題なので、そっちを直してください。
putty使い続けたいなら、puttyスレかな。

そだね、炒ってきます

ttp://diary.imou.to/~AoiMoe/2006.07/early.html#2006.07.10_s01

すばらしい!

Unicode の〜　Unicodeの〜　旗の〜もと〜♪

ageてみる。
ttp://nijino.homelinux.net/diary/200605.shtml
経由で、
ttp://www.mhsin.org/~mhsin/patches/screen/patch-cjkwidth
を当ててみた。ちょっと幸せ。
でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz

>>285
>でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz
wcswidth() って、glibc のやつ? それって誰（どのプログラム）が使ってるの?

文字幅という概念をこのまま使い続けるなら、各文字の文字幅の値（おそらくロケール依存）
をちゃんと定義して、各プログラム／ライブラリで共通の値を使うになってもらわないと
困る訳だが...
Unicode が提唱している East Asian Width （上の PuTTY のパッチもそれを参照している
模様）で、いいのかねえ?

UTFって英字(0x00-0x7f)は２バイト目以降には使ってないんでしょうか？

すべてはMicrosoftの都合のままに...

仕様書に載ってました。
ttp://www.asahi-net.or.jp/~CI5M-NMR/w3/utf-8.html
2バイト以降は、常に最上位 2ビットが 10 になる。

良い仕様ですね。

UCS4ベタでいいよ。

fedora５使ってますemacs でutf８のファイルは見られるんですが
日本語入力できません
mule-ucsというのをいれればいいのでしょうか？

試してから書けよ、な？

試しました
でも 日本語入力モードになってくれません

>>291=293
何を使って日本語入力したいの？ そもそもutf8云々ではないのではないの？

>>294 さん
localeが　utf-8のまま日本語入力したいだけです
手段は　何でもいいんです
utf8　のファイルを扱うのに　mule-ucs が　必要みたいなことを
目にしたので。。　

.emacsはいじった？
(set-language-environment "Japanese")
(prefer-coding-system 'utf-8-unix)
(set-keyboard-coding-system 'utf-8-unix)
(set-terminal-coding-system 'utf-8-unix)
くらいは変更しないといけないと思う。
(set-buffer-process-coding-system 'utf-8 'utf-8)
もかな。

utf8

みなさん日本語辞書には何を使われていますか？

新明さん

すいません。日本語入力ソフトで単語登録するための辞書のことです。
kasumiがeucなので、みなさんは何を使われているのかなと思って。

>>300
おお！私も新明解国語辞典使ってるヨ。
あれはマニアがいて全版で持ってる人も少なくないという話だそうで。
自分は第三版しか持ってないけど。

「新解さん」だろ。

今やUTF-8は標準じゃん

【参院選】民主党から、在日コリアンの期待背負った金氏（民団幹部）が立候補…在日参政権訴え
http://news22.2ch.net/test/read.cgi/newsplus/1184200703/l50

UTF-8って移行が大変･･･

一番辛いのが less +123 hogefile ができなくなってしまう点だな。
まともな（意：限りなくlessな）ページャはないのだろうか？

jlessかlvぐらいじゃね？

ファイル名が255バイトまでしか使えないファイルシステムがまだまだあるから
移行が不安だ

>>307
最新のless-406試したんだけどUTF8環境の挙動が良くなってない？検索の時とか。
（正確にはless-394以降から変わってる）

http://www.greenwoodsoftware.com/less/download.html

>>309
マジレスだが、
255バイトって、大抵そんなもんじゃ? linux で割と普通に使うファイルシステムで
それより大きいのってどんなのがあるの?

ってゆうか、仮にそういうファイルシステムを使ったとしても、POSIX API で
NAME_MAX とかの縛りに引っかかる気が。

ちなみにMac OS XのHFS+はユニコードで255「文字」だったりする。

decomposed UTF-16で255。
サロゲートペアとか合成文字は2文字以上で数えないといかん。
やたら面倒。

windows系ってルートからの合計文字数が255とかじゃなかったっけ？
NTFSだとそんな制限ないのかな。

>>312
それがユニコードクオリティー。

たしか normalization form D とかいうやつな。濁点とかもだからなあ。

いや、アプリケーションレベルで考えると、なかなかうまい仕組みだとは思います。
曖昧検索とかに利用出来そうです。
ただ、それをファイルシステムに使う神経がわからん。

ファイル名の曖昧検索をシステム（コール）レベルでしたかったということか。

でも曖昧検索って、例えばどんなの?
日本語の場合を無理矢理考えると、例えば「たかださん」と「たかたさん」
（「高田さん」の読み方ね）を区別せずに検索とか? そんなにうれしいかねえ。

「曖昧」関係ないだろ？
DにしてもCにしても、
normalization formにするのは当然だと思う。
が、か+compose様゛と見た目は一緒の別のファイルができたらイヤだから。

ただMac OS Xの場合、
kernel levelで正規化をサポートしているのはhfs+だけ。

>>317
>DにしてもCにしても、
DとCならCの方がよくない?

>normalization formにするのは当然だと思う。
確かに。ただ、normlizationを必要とするのはUnicodeを採用してるからともいえるわけで...
あら、ループしてるかな。

>kernel levelで正規化をサポートしているのはhfs+だけ。
ま、逆に言うとファイル名としてUnicodeを使うと明言しているのがそれだけ
だったりして... 確かにufsなんかは単にバイト列を渡しているっぽいね。

Dの方が、単純にbyte列としてsortした場合、
sortの事情に合っている国が多いんじゃないかな?
まあノー資料の妄想ですが。

しかし、ファイルシステムレベルではnormalizationによってうまく機能するんだろうが、
今度はファイル名の文字列を上の層に持っていったとき、ハマりやすいような気がする。
例えばアプリケーション内でファイル名の比較をするときとか。

結局、扱っている文字列がファイル名の文字列であることを常に意識してないと
いけないような。

>>320
Unicodeのnormalizationなんて持ち出さなくても以前からパス名の同値関係は
あるし、どっちみち意識は必要だろ
連続するスラッシュや..が使われてる時の扱いとか
FATやNTFSのようにcase insensitiveなファイルシステムもあるし

short filenameとの比較ってのもある。

>>313
NTFS自体は、各階層で255文字でルートから含めると32767文字まで。
ただ多くのアプリはルートから含めて260前後の文字数しか対応できない。
Explorerも含めて・・・。

>>323
>ただ多くのアプリは
なんだ、Windowsの制限って訳ではなかったのか
知らなかった

VineをUTF-8化しようと思って、
http://homepage3.nifty.com/tearoller/Vine2e.html#UTF8
な感じで設定したけど、bashが文字化けする。
lv使ってのUTF-8ファイル閲覧とかはできてるけど、bashでUTF-8を表示することって出来ないかな。
Fedoraはどうしてんだろ、bash標準らしいけど。

>>325
仮想端末は何使っているの？
kterm とかなら UTF-8 に対応してないので、xterm なんかに切替えろ。

仮想端末についてはよく知らないけど、GUIを入れてない環境だから仮想端末は使ってないと思う。たぶん直にbashが動いてるはず。
SSH接続時はPuttyで、直接操作するときはフレームバッファ有効なCUIで使ってます。
んで、直接操作するときに化けないで表示したいなあと。
(Vine4.2)

>>327
vine のことは良く知らないが、cui のままなら unicon じゃね？
>>325 のページにもあるが、unicon は utf-8 対応してないんじゃない？

フレームバッファを有効にして jfbterm あたりを使うといいんじゃね？
vine の jfbterm が utf-8 対応しているかは知らないが。

>>328
そうみたいです。VineはUNICONパッチのあたったカーネルで、フレームバッファ有効にするだけでEUCとかを表示出来ると。
ただしUTF-8は対応が難しいらしく未実装。

で、jfbterm使おうと思ったけどVineのaptに無いのでとりあえずbterm使ってみた。が、背景が青になるのが気にくわなくて諦め。
また気が向いたらjfbtermインストールしようかな。

Vine('A`)

>>320
Mac OS Xを仕事で使ってますが、
フレームワーク、ファイルシステムごとに扱いが違うので結構面倒です。

ブラウザでUSBサムドライブのファイルを開こうとすると、
ファイル名がNFCでひかかったり。

アプリが必ず読み書きする前後両方でにNFDあるいはNFCする必要があります。

>>331
>フレームワーク、ファイルシステムごとに扱いが違うので結構面倒です。

確かにファイルシステム毎に違うね。まあ歴史的経緯でどうしようもない気もする。
フレームワーク毎というのはよくわかんないけど。

>ブラウザでUSBサムドライブのファイルを開こうとすると、
>ファイル名がNFCでひかかったり。

ファイルシステム云々ゆってるのにUSBサムドライブって別階層を... FATの話?

>アプリが必ず読み書きする前後両方でにNFDあるいはNFCする必要があります。

アプリ内でファイル名の比較をするときなどのことを言ってるのかな?

>>332
> フレームワーク毎というのはよくわかんないけど。

Carbon, Cocoa
10.2で検証した。

> アプリ内でファイル名の比較をするときなどのことを言ってるのかな?

ファイルシステムとフレームワークの組合わせによっては、
オープンするだけでもアウト。

>>333
>ファイルシステムとフレームワークの組合わせによっては、
>オープンするだけでもアウト。

具体的にどんな組み合わせですか?

HFS+だと、確かかなり下の方でnormalizeをしてるので結構大丈夫だと踏んでるけど...?
UFSだと、たぶんただのバイト比較だから簡単に駄目な例は作るはず。
でもUFSはUnicode以前からあるわけだし、今更どうしようもないという感じ。
しかし全然Linuxじゃないというw

さすがに板違いだろ。HFS+まで出てきた日には。まぁ、カーネルは入ってるけどな。

>>334
Linuxはiocharset=でmount時に指定できるFSが多いよな。
VFSのレイヤーでやればいいのにな。

DarwinはどのFSも決め撃ちオンリーだな。

だから板違いだってば。

そういえばこの前ubuntuというものを初めてインストールしてみたら
ホームディレクトリに「デスクトップ」とか作られててビビったんですがw

ext3ってエンコーディングとかの規定はどうなってるんでしたっけ?

Unixのファイルシステムは基本的に8ビットスルーだろ
2バイト目に/が被るS-JISは事実上使えないだろうが

ttp://ja.wikipedia.org/wiki/Shift_JIS
> Shift_JISの2バイトコードの空間は、第1バイトが81-9FならびにE0-FC、
> 第2バイトが40-7Eならびに80-FCである。

昔の話だけど、jfsでUTF-8のファイル名するのになんか問題があった気がする。

>>339
要はファイル名の比較はバイトデータの比較ってことでいいでしょうか。

ということは上の方に書いてあるみたいにnormalizationの違うファイル名を使うと
問題が起きたりすると。

>>342
ファイルシステム的には違うバイト列名の別ファイルだから問題は
特に起きない。が、ファイルマネージャとかアプリが表示段階で
正規化とかするとアボン。

>>342
一番やっかいなのは、
正規化されてないファイル名がある時。
ファイル名が正規化されていることが分かっていれば、
二つのファイルが別のファイルシステムにあって、
違う正規化がされていても、一旦正規化してから、比較すれば良い。

ただこういうことを包括的に扱っているVFSはまだない。

ファイルシステムレベルでは問題ないかもしれませんが、例えばディレクトリをlsしたときに
同じ名前のファイルが複数表示されたらユーザーはアセるんじゃないですかね。

>>344
VFSですか。だとするととりあえず
「システムコールに渡すパス名はUTF-8ということになったので、そこんとこヨロシク」
みたいな宣言がいつか行われるとか?

>>345
別にUnicodeに限った話じゃなくて

　touch he11o hello

が識別できない環境あるけどどうよ？とかかつてなされた
文字が「同一」とはどのレイヤ（コードマップなのか
エンコーディングなのかフォントなのかコンテンツなのか）が
定めるのか？というお定まりの侃々諤々が始まるだけだと思われ。

>>346
>　touch he11o hello

これ、単にグリフのデザインの話でしょ。ファイルシステムにもUnicodeにも関係ないし。

「同じ様に見えるファイルが複数表示される」というのは単にユーザが結果を確認する
ときの現象を書いてみただけで、
正規化の問題で本来一つのファイルが複数できてる、みたいな問題自体は文字の
見た目にかかわらず存在する。