ja_JP.UTF-8

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

>>151
統一できないから問題があるというか、統一できないような文字を
同一の文字として統合してしまった仕様に問題があるというか。

サロゲートペア考えたやつは死刑

>>154 うむ。あんな変なことするくらいなら、
素直に UCS4 で良かったのにな。

だって16bitで十分だと思ったんだもん…

>>152
へーそうなんですか。曖昧な文字をすべて全角か半角か一方にすればとりあえず
困らないって感じですか?
実装をチェックしてみねば... どのみち、既存の wcswidth() を使ったら OK、という
ような単純なものではなさそうで。

全角半角問題に関しては、逆に CUI 系のプログラムから全角/半角という概念を
捨てきれればいいのかも。常に1文字1カラムで、ターミナルとかで既存の
挙動をしてほしかったらフォントのメトリックで対処すればいいとか。
(可変幅のカラムといいますか... アルファベットが等幅&日本語の文字幅がアル
ファベットの2倍にデザインされたフォントを使う)
って、これって問題をフォントのデザインに押し付けただけ?

あーでも、文字の表示を簡単に揃えたいときには結局固定幅のカラムじゃないと困る
ような気もしてきました。たとえば ls コマンドの表示ルーチンでフォントの
メトリックを計算させる必要があるとしたら (w

やっぱ Unicode がイカン、ということで。

>>157
> あーでも、文字の表示を簡単に揃えたいときには結局固定幅のカラムじゃないと困る
> ような気もしてきました。たとえば ls コマンドの表示ルーチンでフォントの
> メトリックを計算させる必要があるとしたら (w

mozillaのxmltermどうよ?

>>153
確かに。
で、とりあえず話を全角半角問題(?)に絞ると
wcwidth() が
1. 既存のエンコーディングを使うロケール (e.g ja_JP.eucJP)のときは、それらしく動く
(EUC-JP で2バイトな文字は全角、それ以外は半角 <- って、これも問題があるような)
2. Unicode を使うロケール( e.g. ja_JP.UTF-8) のときは
とりあえず EUC-JP -> UTF-8 にマッピングがある文字は 1. と同じ挙動。
ないものは、その他のロケールを探して(e.g. zh_CN.eucCN)、1. と同じような
判定ができればそれを採用。(できない場合は...)
みたいな挙動をしてくれたら、皆でそれを使えばいいような気がするんですが。。。
Ambiguous 云々というのは Unicode をベースに考えるからで、では既存のエンコーディング
をベースに考えると、こういうことになるのではないかと思いますが。。。
どのみち旧来の全角半角というのがあまり明快な考え方ではないので、決め方自体はすっきりしませんが、上のようにすれば、文字幅は地域コードのみに依存してエンコーディングに
は依存しないかなと。

EUC-JPの半角カナは２バイトだよ・・・??

>>158
>mozillaのxmltermどうよ?
う、使ったことないけど、もしかして表示の整列とかを賢くやってくれちゃうのかな?
いろいろ疑問がわくけど (ry とりあえず後で使ってみます。

眠くなったきたので休憩...

>>159
同一ホスト、同一ロケールならそれでなんとかなるが、
端末ソフトの場合はロケールやホストが異なるものが
混じるかもしれないからそんな単純にはいかない。

>>160
3バイトじゃなかったっけ？

>>162
> 3バイトじゃなかったっけ？

そりゃ補助漢字でしょ。半角かなはSI/SO + 文字で2byte。

Unicode 絡みの話題と言えば、最近 Mac OS X のバージョンが変わると特定の文字のコードが変わるとか言う話があったね。
http://slashdot.jp/article.pl?sid=04/11/30/1014219&topic=11&mode=nested
まぁドラフト段階の字形-コードの対応表を使っちゃった Apple が悪いんだけどさ。

ところで、「字形-コードの対応表」って専門用語ではなんて言うの？

Coded Character Set

>>165 符号化文字集合…か。

>Coded Character Set(CCS)
説明不足だった。これは文字毎に一意の番号を振ってある文字集合。
JIS X 0208とか、UCS-2とかがそれ。

CCSをどういうバイト列で表すかがCharacter Encoding Scheme(CES)。
EUC-JPとかUTF-8とかがそれ。

ただ、字形じゃなくて文字概念に番号がついてるから、どっちも
厳密には>>164の言ってるものじゃないのかも。

AdobeのCIDは字形に番号が振ってあるな。

xmlterm、まだ使ってないけどスクリーンショットでそのコンセプトはわかった
気がする。ターミナルを一種のブラウザと考えるとああなるのかな。
今までのターミナルはプレーンテキスト専用のブラウザとも言える訳だ。

こうなったら、ウェブブラウザもファイルブラウザもターミナルも
全部統合した UI を目指す事にします。ってどこかで見た気が...

餅は餅屋ということわざを教えてあげたい

和菓子屋の餅も旨いよ。

佐藤の切り餅って超まずいね。というか餅じゃない。
あんな餅を餅だと思って食べている人がいるかと思うと
かわいそうだ。

>>171

十分うまいよ。

Mac OS X,で使われているUTF-8 with NFDを扱おうとおもって、
http://www.opensource.apple.com/darwinsource/10.3.8/
からAppleハック済みのlibiconvをx86のlinuxでコンパイルしてみました。
configureもmakeも問題なくできるのだけれども、iconv -f UTF-8-MAC -t UTF-8 等としてもどうもうまく動かないんです。
(Mac OS Xでコンパイルすると問題なく動きます。)
どうもエンディアンの問題臭いのですが、自力では解決できず...
netatalkのUTF-8 with NFDの実装が一番上手な気がするのですが、そこからもってくるのは難しいので困っています。
どなたかNFDからComposed Formに変換する方法をご存知の方はいらっしゃいますか？

なんで UTF-8 の変換にエンディアンが関係するんdayo!
って一瞬思ったけど、iconv の内部的には一旦 UTF-16 とかにしてるのかな?
Apple のハックのせいなんなら普通の libiconv と比較してみたらいいんじゃねーの?
それか普通の libiconv にその UTF-8-MAC を追加する方向で修正してみるとか
...ってのができないわけね。
Mac OS X が使えるなら Mac OS X 上で変換してから他のプラットフォームに持って
いくんじゃ駄目なのか?

>>174
> configureもmakeも問題なくできるのだけれども、
> iconv -f UTF-8-MAC -t UTF-8 等としてもどうもうまく動かないんです。

How?

ja_JP.UTF-8 ロケールでeuc-jpのnfs鯖をマウントするときみんなどうやってるの？
（sambaや、webdav使えばできるんだけどネ、nfsでの解決策を教えてね）

問題が本当にエンディアンのせいなら、utf8mac_mbtowc() が呼んでいる
utf8_decodestr() の引数に UTF_REVERSE_ENDIAN をセットしてみたらいいかも。
ハードコーディングになっちゃうけど。
それで駄目だったら >>176 の回答待ちか。

>>176

http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-9.tar.gz
をダウンロードして、
./configure --enable-static=yes --enable-shared=no --disable-nls --prefix=/opt/mac
としてconfigureしてmakeして、スタティックリンクしたバイナリを作って実験してみました。

ls | iconv -f UTF-8-MAC -t UTF-8
で、NKDな文字がちゃんと出てくるか調べてみたのですが、めちゃくちゃな文字化けしか起こりませんでした…

>>178
UTF_REVERSE_ENDIANをセットしてみてもしなくてもですが、めちゃくちゃに文字が化けてしまいました。

一つ怪しいかなと思うのが、
utf8mac.h: In function `utf8mac_mbtowc':
utf8mac.h:1566: warning: passing arg 6 of `utf8_decodestr' makes integer from pointer without a cast
なんてwarningがでるんですが、もしかしてこれのせいでPowerPCでしか動かないコードになっていることなんです。

でもCが全くわからないので意味はわからないのですが…

>>179
気になったので試してみたけど、
http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-10.tar.gz
や
http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-13.tar.gz
なら

-#include <libkern/OSByteOrder.h>
+//#include <libkern/OSByteOrder.h>
+#include <byteswap.h>
+#define OSSwapInt16(x) bswap_16(x)
+#define __LITTLE_ENDIAN__

という変更でいけるみたい。

nkfの最新のCVS版で、
nkf -w --utf8mac-input hoge.txt
などとすればUTF-8-MACをUTF-8に変換できる・・・はずです。
うまくいかない場合は教えてください。

あけおめage

フェどらって、OSの仕様をかえればすぐにソフトの仕様もかわると思ったのかな？

「すぐに」とは思ってないんじゃない。

使っているOSがUTF-8なのかEUC-JPなのか
簡単に判別する方法はあるでしょうか？

とりあえず、今1CDのGeeXboXを日本語対応化してみていますが
USBメモリー(vfat)上のファイル名は正常に表示されますが
HDD上のファイルがうまくいっていません。

たぶん、このHDDへのファイル保存をVineでやっているので
未だEUC-JPのVineだってところか
あるいはGeeXboX側のmount optionの問題か…手詰り。

UTF-8標準に向かったディストリビューションには
ファイル名をUTF-8化するコマンドがあるようですが
とりあえず、Vineではapt-getはできないようで…

いっそ、UTF-8標準のディストリビューションを入れちゃうか？と思ったり。
それとも、FedoraCoreからconvmvのソースとってくるほうが速いのか？
どちらにしろ、もう遅刻する時間を過ぎているので出勤しまつ orz

ちなみに、GeeXboXはlibsmbなんとかやfstabが
ラムディスクイメージの中にあるので、今私には手が出せません。

#気の迷いでパソコン一般板にGeeXboXスレ立て公開中

age
OS が UTF-8 ってのは
UTF-8 対応のロケールが入っているかどうか？という意味なんでしょうかね。

>>187
だね。kernelはutf-8対応なんかしちゃいないよ。

>>188
ん？VFATとかsmbfsなどのNLSにUTF-8が入ってるけど？
他のUTF-8/16なOSとファイルレベルで互換とらないといけないFilesystemはカーネルレベルでNLSサポートしてますよん。

それドライバの話でしょ。カーネルからはNUL端の文字列にすぎないよ。

ドライバがカーネルかどうかなんでどうでもいいから

カーネルをソースからコンパイルするときに
ファイルシステムのエンコーディングを
UTF-8だのSJISだのEUCだの指定できるのはなんなんだろうね。

>>192
ファイルシステムドライバへの指定だから、どのみち>>191だとおもわれ

EUCで書かれたシェルスクリプトをUTF-8でごちゃごちゃいじって、
おなじファイルなのに容量が増えることに愕然としたりして、
それでもいじってとりあえず動くものができたんですが、

日本語の文字化け以外にはやう゛ぁイことって何も無いですよね?

おまえ

とりあえず、LOCALEの設定箇所を調べて
そこを確認すればわかるってことでいいようですね。

それはそうと、アクセス規制の一日の間に
convmvでUTF-8ファイル名にしたら当座の目的は解決。

ともかく、ありがとうございました。

はじめてRedHatES4いれてみた。

# /etc/init.d/xinetd reload
繹・秧莨若榛 [ OK ]

ってな出力がUTF-8ででてるっぽいんだけど
これってEUC-JPに変更できないのかなあ。
ES3まではEUC-JPだったのに。

>>197
Red Hat Enterprise Linux スレッド part 24
http://pc8.2ch.net/test/read.cgi/linux/1136544255/

玄箱を Debian 化して、locale を utf8 にして、日本語manを入れたら、
euc-jp で書いてあって文字化け。orz

gentooの事例だけど
ttp://wiki.gentoo.gr.jp/index.php?%5B%5Btips%BD%B8%5D%5D#content_1_5
ttp://www.jaro68.org/needlejuice/blog/206
ttp://www.sen2or.com/index.php?itemid=1003

>>192
ファイルシステムにエンコーディングは関係ない
ファイル名を決めるのはカーネルじゃないってわからない?

ファイルシステムにエンコーディングは関係あるし。

>>202
どういう意味だろう?
とあるロケールで使用する文字コードが
ファイル名として使える文字コードの範囲内に入ってれば
何の問題も無いと思うんだが

例えばUTF-8のディストリでも、シコシコ設定書き直せば
システム全体の文字コードをEUCにもSJISにもできるわけで

>>203
CONFIG_NLS_*
mount iocharset=*
を調べるか、黙って。

>>204
NLSやcharsetはエンコードと関係あるが
カーネルがエンコードしている事の証明にはならないわけで＾＾；
「黙って」ほしいなら
「お願いですからこれ以上つっこまないでください」と懇願した上で
お前が黙れｗ

つfs/nls/*.c, fs/*fs/*.c

>>205
んじゃ NLS や charset は何がつかってるの？
ファイルシステムはドライバでカーネルじゃないとか言うつもりかｗ

>>204
エンコードはしないが関係無くは無いって事か?
トンチが効いているが言い訳っぽいな…

たとえば'/'をディレクトリの区切りと見なしてるのは、ファイルシステム
だけじゃないと思うんだな。(思うだけでソース見て回ったわけじゃないが。)
とすると、8ビットクリーンな環境ならばファイル名がutf-8やeuc-jpは問題
ないが、iso-2022(-jp)やShift_JISを使うのには困る。

>>209
禿同。

>>208
ん? iso-2022-jpを使ってファイルを取扱うシステムなんてあんの

あらら極論を持ち出して・・・

File system 自身が '/' という「文字」を抱え込んでるってのか？

macでは':'
winでは'\'

まあ、/とか考えるまでもなく、ファイルシステムに文字エンコードは影響するし。

>>214
Windowsも内部的には'/'だよ

あほ

>>216
あ、そなの？知らなかった。

>>216
ソース

NT系列では'\'が本則みたいだねえ。システムコールはもちろんどちらでも
受け付けるけど。
>>219
この一連の議論参照

システムコールがどちらも受け付けるからといって、
内部の扱いかどうかなんてわからんだろ。
ソースかバイナリを追った結果でもどこかにでてるんなら別だけど。

おっと失礼。この一連の議論ね。
http://mail.python.org/pipermail/python-list/2003-September/185195.html

>>221
DOS2.11は/だったが、(ソースは見た)、今は全く違っていても不思議はないね。

>>222
もしかして、脳晦の容量不足している？

JFSのunicodeってなに?
UCS4?

無意味に煽ってる奴のほうがよっぽど顔悪く見える

>>225
そうやって無意味に煽るのはやめなさい。

>>224
UCS2かUTF-16だとおもわれ。

>>222
DOSは switcher を変えると / *も* 使えるようになるだけだ

日本語はさ、1カラム文字と2カラム文字しかないけど
他の言語には３カラム文字とか４カラム文字とかあるの？
端末上で半角３文字分とか４文字分の文字。

>>229
画面に出る時の幅のことを言っているの? プロポーショナルフォントは
W と i で幅が何倍も違うな。

はっ。しまった。あからさまな釣りか。

>>230
固定幅のフォントでの話です。
普通の日本語対応の端末エミュレータの場合そうでしょう？
端的に言って日本語以外だとwcswidthで3や4が返る可能性があるのかないのかなんですけど。

unicode とそうでないので混じってるみたいだけど、
emacs の HELLO ファイルみると
(debian だと /usr/share/emacs/22.0.50/etc/HELLO)
Hindi とか Malayalam とか Kannada とかの
フォントセットのところに3とか4の文字がある。

>>233
ああ、やっぱあるのか。カラム数４ってどんな文字だorz
ありがとー。ちょっと対応を考えないといけないな。

unicodeって、リガチャがあるから面倒くさい。死ね。

>>234
アラビア文字みたいに横に伸びる文字なんじゃないかな。
日本語も実際には伸びる時がある(「おーーーーい」という
時の「ーーー」の部分とか)が、それを普通の文語体の文章
ではあまり使わないから困らないだけだ。

>>236
なるほど。日本語も縦書きだと３カラム分消費する奴がありますよね。
おーーーいの「−−−」をしの長いようなので書く奴。

>>235
確かにUnicodeって色々面倒だとは思うけど
Unicodeに対応するだけで各国語に対応できるのは確かに便利だと思う。

各国語には対応できるけど多国語が微妙なんだよね。

多国語でなくて多言語って言ってほしいかな。

むはぁ

>>237
くの字点のことかな。繰り返しに使う。
普通は2文字分の長さではないかと。

でさ、ファイルシステムにエンコーディングは関係あるの？

実運用上は、そんなエンコーディングの都合よりもftpdの文字化けで困るんだよね。
こればっかりはクライアント側の問題だからサーバ側ではどうにもならないし。

将来的にutf-8に統一されるなら今更eucJP使いたくないけど、
上記の理由で1台はeucJP確実なので、他も統一しないと使い勝手が悪い。
→全てeucjpで稼動。

>>243
ftpdが漢字を返すの? あ、もしや漢字ファイル名のこと?

>>243
ああ、あれで困ってEUC-JPに戻さざるを得なかった。(FTPサーバー立ててるから)
だって、UPされたファイルかたっぱしから文字化けして(LINUX上で)
何がなんだか分からんし。

そりゃ「日本語ファイルUPすんな！」って言えばいいんだけど、実際UPする人いるしな。
UP元のWindows機のファイルを全部英数字にリネームしろ！ っていうのも横暴だし。

eucjpなディレクトリツリーをsambaでローカルにのみ共有して
smbmountでiocharset=utf8でマウントして特定場所のみeucjpで
メインはutf8を共存みたいな

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

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

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

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

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

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

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

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