ja_JP.UTF-8

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

>>134
EUC撲滅のスレッドに見えますが…
スレ違いという理由で誘導されてるのに話題が出ているというだけの理由で
スレ違いのスレッドに案内されても困ります。
それともうにこーだーはすべからくEUCの撲滅を望まなければなりませんか

>>136
スレタイはアレだけど
中身は文字コード総合スレだよ。

xpdf って、UTF-8 に対応してますか？日本語表示できる PDF ファイルと、できない PDF ファイルがあって、どうやら、MS Office で作成した PDF ファイルがダメっぽいので、UTF-8 のせいかな、なんて思ってます。

>>137
文字コードスレ2つも要らんだろ。
削除依頼よろぴく。

だからここは文字コードスレじゃないと主張してるんだろ。
それとも>>134以外に文字コードスレがあるの?

１を見れば分かるように、ここはﾛｹｰﾙのスレで
あって、文字コードのスレではありません。「たまたま」
utfの話題が多いだけなのです。

最近はみんな満足してるのかな？
俺は tcsh に utf-8 パッチをあてたものを使ってるんだが、
ロシア語とか■とか、そういう端末上での文字幅があいまいな文字が
のきなみ半角扱いになってしまって、
ずれるんだよな。
emacs + mule-ucs でも同様なのでずれるんだよな。
どうしたもんかしら(´・ω・｀)

>>123
UNICODEの文字セットを日本語2バイトで扱う符号UTFCP2がある:
ttp://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
特徴は2バイトのコードポイント数が非常に大きいこと、状態非依存であること、
正確にテキストを逆戻り可能なこと。

LightCone乙

test

てｓｔ

>>143
UTFCP2
これただのネタじゃん

何を今更

http://www.ganaware.jp/archives/000060.html

何を今更

>>142
ずれないようにするにはターミナルエミュレータ(xtemとか)とエディタ (emacs
とか)の両方で全角半角判定が共通である必要がある。で、上の方で
1. 判定には何を使うべきか? wcwidth()/wcswidth()? その他?
2. 判定結果はどうあるべきか
... という話があったわけだが、結論は (ry
せめて 1. がこの世のすべての CUI なプログラムで統一されればずれなくなるん
だけどねー。

最近自分もこの問題に巻き込まれてしまった... orz

>>151
最近は端末エミュレータに ck を使っているのですが、
ck （や xterm) は半角/全角があいまいな文字を
半角で表示するか全角で表示するか選択可能なので、
すこしマシになりました。

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