ja_JP.UTF-8

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

2

UTF-8 に対応しているソフト

mlterm - http://mlterm.sourceforge.net/
xterm
tcsh 6.12 - http://www.tcsh.org/
lv - http://www.ff.iij4u.or.jp/~nrt/lv/
samba3.0 - http://www.samba.org/
emacs + mule-ucs

以下、続々登場(予定)

UTF-8 に対応しているソフト

iconv - (問題点⇒http://www.miraclelinux.com/technet/samba30/iconv_issues.html)
mozilla - http://www.mozilla.org/
nkf - http://sourceforge.jp/projects/nkf/
vim - http://www.vim.org/
yudit - http://www.yudit.org/
cocot - http://iwa.ath.cx/software/cygwin/cocot.html

以下、続々登場(予定)

Debian/GNU Linux 3.0 での設定

/etc/locale.gen ファイルに、
ja_JP.UTF-8 UTF-8
の一行を追加して、
/usr/sbin/locale-gen
を実行すると、/usr/lib/locale/ja_JP.utf8 以下にロケールデータができる。

cocot ってよさげっぽいな。
これを使えば utf-8 を扱えないターミナルでも
$ cd 新規フォルダ
とかが出来るようになる？

>>5
できますが、(cocot のせいではないが) シェル自体が utf-8 にちゃんと
対応していないと表示が乱れます。
使い方⇒
cocot -p utf-8 ssh hoge.co.jp

Debian関係:UTF-8
ttp://tagoh.jp/w/wiliki.cgi?Debian%b4%d8%b7%b8%3aUTF-8&l=jp

UTF-8 に対応しているソフト(というかツールキット内部で UTF-8 を使ってる)
Gtk+2/GNOME2 アプリ http://www.gnome.org/
Qt(2|3)/KDE3 アプリ http://www.kde.org/
OpenOffice http://www.openoffice.org/

同上
subversion http://subversion.tigris.org/

>>6
cocot, Debian で compile して使ってみました。

$ echo $LANG
ja_JP.eucJP
$ ./cocot -t EUC-JP -p UTF-8 ssh hoge 'ls utf-8-folder'
あ
い
う

と、上手く行ったけど slogin で bash 2.05b な shell では ls としても
駄目でした。bash が utf-8 に対応していない？ というか、対応している
shell ってある？

>>10
tcsh は対応してることになっているけど、
マルチバイトの utf-8 文字がちゃんとずれずに表示されるかどうかは不明。

emacs + mule-ucs + M-x shell で、
process-coding-system を utf-8 にしたらうまくいくかも…

GNU recode関係はこちらでよろしいのでしょうか？
興味があってこれから勉強しようと思っているのですが、、、
http://www.gnu.org/software/recode/recode.html

>>10
ちゅうか、これ cocot を使わずとも

$ ssh hoge 'ls utf-8-folder' | iconv -f utf-8 -t euc-jp -

とすればいいですね。

>>11
tcsh 試してみます。

しかし、この状況ではja_JP.eucJP並にja_JP.UTF-8が使えるとは思えないのだが、
Fedoraは何で採用してんだ？ 実験的ディストリったって、早過ぎないかね。

Fedora使ってますが、TeX関連とWnn7がUTFだと面倒みたいなので
EUC環境に避難中です。

bash自体(2.05b)はUTF-8に対応してるんじゃないの?
日本語の上でカーソル移動させてもちゃんと文字単位で移動する


関係ないけど自分的に問題なのはターミナルで一部の全角文字が
半角扱いになること。gnome-terminalで★とか−とか。
全角判定をwcswidthなんかでやっていると思うのだが。

プロポーショナル文字フォントを有効にできれば
(そのうえで固定幅文字フォントを指定すれば)解決しそう
(mltermではできる)が、gnome-terminalではそんな設定はない。

あ、あとmanというのもあったな。
man page自体には言語情報は含まれていないっぽくて
man pageのエンコードのまま出力されてしまう。
gettextみたく文字コード変換機能がついていればいいんだが。

>>13
その例自体はそうですが、
cocot の利点は仮想端末を提供してくれるというところですね。
あと >>4 にあるように iconv には色々問題があったり…
(cocot も libiconv を使うだけなので同じ問題を内包してますが)

すんません。
>>10
で login したら駄目、って言ったけど LANG が ja_JP.eucJP のままだから
でした。ja_JP.UTF-8 にすると

fuga:~$ echo $LANG
ja_JP.eucJP
fuga:~$ ./cocot -t EUC-JP -p UTF-8 ssh hoge
...
hoge:~$ export LANG=ja_JP.UTF-8; cd utf-8-folder
hoge:~/utf-8-folder$ ls
test てすと/
hoge:~/utf-8-folder$ cd てすと
hoge:~/utf-8-folder/てすと$ ls
kita- キター

こんな感じで、うまくいきました。
これで、かなり幸せになりそうです、ありがとう！ >>1 と cocot の作者。

# tcsh では 'cd てすと' が、できなかったけど、常用してないので
# 詳しく調べてません。

どうせならLANG=ja_JP.UTF-8した後にさらにbash起動したほうがよいかと
cd てすと
はうまく動くけど、あとからヒストリ編集するとぐちゃぐちゃになる。

と思ったらLANG=ja_JP.UTF-8とやれば現行シェルもちゃんと切り替わるな
LANG=ja_JP.UTF-8 ls とかやると(変更がその場限りなので)ダメだが

Debian sid, KDE 3.2でLANG=ja_JP.UTF-8で使ってます。
ja_JP.EUC-JPから移行するときはゴミ箱に注意。
名前が化けて消しにくいファイルができて往生します。

いろいろやってみた。

Windows から cygwin の rxvt + cocot -p UTF-8 で Linux へログイン。
Linux では、emacs 21.2.1 + mule-ucs で、
M-x set-terminal-coding-system utf-8

まず、M-x help h で、HELLO を読んでみた。
日本語部分はちゃんと表示される。
いくつか問題点があった。

(1) Greek
Greek (Ελληνικ##) Γει## σα##
Russian (Русский) Здравствуйте!
全角文字で表示されてしまっているので、rxvt での文字の表示位置と、
カーソルの位置がずれる。

(2) Chinese
Chinese (中文,普通###,######) ###好
cocot は、sjis (cp932?) へ変換できなかった文字をそのままのバイト数で
# へ変換するようだが、おかげで、カーソル位置とずれる。

それから、emacs で utf-8 のフォルダの中にあるファイルを
開こうと思った。表示がくずれてわけわかりません。
set-filename-coding-system みたいなものってあるのでしょうか？
どうもファイル名などが euc だと思われてしまっているようです。

関係ないけど luit 面白いよ。

喪前らfedorasu刷れへかいれ！

さらに、tcsh-6.12.02 を make して utf8 ファイル名のフォルダへ
移動してみた。
set dspmbyte=utf8
という指定をしておけば、cd UTF8フォルダ、など補完もきく。
ls-F でも UTF8 ファイル名は一応表示できる。

だがしかし、tcsh は日本語の UTF8 文字を半角 3 文字分の
幅だと認識しているようで、カーソル位置が激しくずれる。

>>26
あいにく俺は Debian 使いだ。
それから http://www.routrek.co.jp/product/varaterm/
こんなものもあるらしい。

>>25
http://www.xfree86.org/current/luit.1.html
これでしょうか？cocot と同じようなソフトだと思われます。

cocot は初めて知ったのでよくわかりませんが、
luit は utf-8 さえ表示できればいろんなロケールの表示が可能になるやつです。
むしろ cocot の逆ですかね?
X の標準に入ってて、
XFree86 4.3 からは xterm で自動起動されるようになってます。
フォントさえ設定してあれば、
LANG=ja_JP.eucJP xterm で日本語表示可能。

以前 xfree86 の xterm で日本語を試したときは
日本語は出ることは出るが、
使用できるフォントが限られていて、あまり綺麗に映らなかった。

最近、xtt の TTCap な fonts.dir に
iso1646-1 をつけくわえて、
~/.Xresources などに

xterm*cjkWidth: true
xterm*Font: -kochi-mincho-medium-r-normal--16-*-*-*-m-*-iso8859-1
xterm*BoldFont: -kochi-mincho-bold-r-normal--16-*-*-*-m-*-iso8859-1
xterm*wideFont: -kochi-mincho-medium-r-normal--16-*-*-*-m-*-iso10646-1

のようなリソースを設定してみた。

すると、xterm で 東風 が映って
使用感は ほとんど kterm と同じ。

ja_JP.UTF-8, ja_JP.EUC-JP
の両方が利用できる。

>14
昔から赤帽の日本語環境・デスクトップ環境はだーれも期待してなかった。
Fedoraはその伝統をしっかり受け継いでいる。

>>14
決まってるぢゃん。
JISやらGBといった漢字文化を潰し、欠陥unicodeをCJKの人々にも
強要して西洋人が楽するために決まってるでしょ。
彼らはCJK環境を「CJKのユーザのため」を第一に改善しようとは決して思っていない。
自分らが楽をする事は考えてるけどな。

unicodeとJISとのコード対応関係が日本で混乱してるのは彼らも知ってるはず。
それでも、EUCとSJISで平和に暮らしてるところに、こうやって新たな混乱を強要
してくるってのは、相当利己的だと思う。

UTF-8使う=売国、って事でOK?

>>33
(　´,_ゝ`)バカジャネーノ

[debian-devel:15706] ja_JP.EUC-JP + ja_JP.UTF-8 サポート
http://lists.debian.or.jp/debian-devel/200307/msg00026.html

CJK統合漢字は事実上中国が決めてることも知らない人が
いるスレはここですか?
> UTF-8使う=売国、って事でOK?
はっ、結論が変わらない

ところで、UTFは何の略？

Unicode Text Format
UCS (Universal multi-octet coded Character Set) Transformation Format

などの説明がみつかる。８は８ビット。

必要なし、とか書いたら丁度省略されたな…

ところで、Fedora の人は utf-8 環境でもあまり困ってないのかしら。
端末エミュレータも最初からutf-8に対応してるみたいだし…

>>39
困りまくりw
結局euc-jpに戻して使ってる。

>>33
ｅｕｃはともかく、sjisじゃ幸せになれないよ・・・

>>41
つうかSJISなlocaleは未だにサポートされてないし。
Big5はあるのに。

ないなら作ればいい
localedefで作成できたはず
RedHat8あたりからそうやってSJISとUTF-8のロケール作っていたが
(常用していたのはUTF-8のほう)

いまEUC-JPでないと困るソフトってどれくらいあるかな
lynxとかそうだけど使わないし。tcshはビミョーに使えないな。
Xのソフトはフォント設定で何とかなることが多い。
RedHat9時代はEmacsも使えなかったがFedoraで使えるようになった。

http://bedroomlan.dyndns.org/~alexios/coding_ttyconv.html
cocot と同じもの。

http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm
…

http://pc.2ch.net/test/read.cgi/unix/1012581029/
端末エミュレータスレより

947 名前：名無しさん＠お腹いっぱい。 投稿日：04/03/08 18:08
rxvt の unicode 版結構面白いですね。
ja_JP.eucJP のlocaleでも使えるし、
xft と X11 のフォントまぜて使えるし、
mlterm みたいに server 機能もあるし。

948 名前：名無しさん＠お腹いっぱい。 投稿日：04/03/08 18:14
さらに
locale が utf-8 でも
jisx0208 のフォントも使えますね。こりゃいい。

>>45
御本人が降臨してた。
http://pc.2ch.net/test/read.cgi/linux/1003159137/587

>>46
これですかね。
http://sourceforge.net/projects/rxvt-unicode

>>47
マジかよ@3
ま た き た か ( 別に逝いけどw

>>48
そうです。
debian なら sid に rxvt-unicode-ml ってやつがきてます。

LANG=ja_JP.UTF-8 urxvt -fn "a14,k14,xft:arial unicode ms:size=14"
こんな風に起動すると、英字に iso8859-1 の a14, 漢字に jisx0208 の k14,
その他の言語に xft の arial unicode ms を使うようなことができます。

urxvt詳細解説希望。KTermみたいな感じで日本語入力できないの？

# KTermのUTF-8パッチないのぉ?
# UXTermはフォント設定がよくわからん。-alias-fixed使いたいyo

>>51
--enable-ximってしてもximが聞かないなあ

cygwin の libiconv に
http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.9.1-patch.html
を当てて作り直して、
さらに cocot を使いつつ ssh で Linux へログイン。

Linux 上で emacs + mule-ucs を起動。その時
(set-default-coding-system 'utf-8) をする。
かなりフツーに使える。
あとは tcsh のコマンドラインエディタが utf-8 にマトモに対応してくれりゃいいんだが。

libiconv の日本語パッチの作者は、これを libiconv 本体に取り込んでもらうつもりはないのかな…？

そうそう、emacs 上で HELLO を表示すると、さすがに化け化けになる。
文字幅を適切に反映してくれるだけで、もうちょっとマトモに見えそうなもんだが。

>>53
Brunoに送ったらしいけど、まだ取り込まれていない。理由はようわからん。
glibcの方はもう取り込まれてるんだけど。

>>54UNICODE の文字の固定幅ってどうやったらわかるのでしょう?何かそれっぽい API が存在するのかな… iconv には見当たらないが。

libc的にはwcwidth()を使えばカラム数は取得できる。
もちろんlocale依存だけど。

>>57
locale に依存しない方法がほしいですねぇ(´･ω･｀)

>>58
East Asian Width
ttp://www.unicode.org/reports/tr11/tr11-11.html
↑これを見れ。

ED6. East Asian Ambiguous (A)
のおかげで、どうがむばってもlocale依存だすよ。(´･ω･｀)

>>59
あ、そうではなくて、
プログラム自身は A というlocaleで動いているが、
B という locale での幅を知りたい場合とか。
int wcwidth(wchar_t c, locale_t locale)
みたいな感じにしておかないと困らないかね…？

>>60
CとC++の話がごっちゃになってない？

>>61
誤爆？API関数の話だから言語は関係ないと思うけど。

>>62
Cのlocaleはglobal、C++のlocaleはnon-globalなobjectという
非常に大きな違いがあるが。

>>63
Σ(゜д゜|||)ﾏｼﾞｽｶ
ぜんぜん知らなかった。良かったらその辺の話へのポインタを教えてくださいませ。

>>64
この辺かな。

The Standard C++ Locale
http://www.cantrip.org/locale.html

Differences between the C Locale and the C++ Locales (Rogue Wave)
http://www.roguewave.com/support/docs/sourcepro/stdlibug/24-3.html

C 言語でのロケールと C++ ロケールとの違い (上の日本語版)
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/SUNWspro/WS6U2/ja/manuals/stdlib/user_guide/loc_io/3_3.htm

>>23
UTF-8のときは桁数を考慮するよー修正を検討してみまつ。
しばしお待ちください。(GANAさんとこのパッチも取り込んでおかんと……)
# wcwidth()は使えなさそうだなぁ。>>59を見て考えるか。

全然関係ないけどhttp://www.google.co.krで「utf-8」を検索すると１ページ目の一番最後の所に
何故か日本語のページが出て来ますね。それにそこもutf-8で書かれているぽ

ところで、tcsh は utf8 に対応してることになってますが、
3バイトの文字が来たり、補完したりすると化け化けになります。
http://www.tech-arts.co.jp/macosx/macosx-jp/htdocs/15300/15330.html
このパッチ当ててみたりしましたが、上手く動いてるとはいいがたいような。
誰か解決方法しりません？

というか、mltermもiconvもglibcもその他もろもろのソフトウェア作成者のみなさん！

JISの１区２９点は、U+2015じゃありません！U+2014です！

これを揃って直してもらわないと、困ります！！！

emacs(version 22)と、java (JDK1.4)は、ちゃんと１区２９点をU+2014にしてます。

Unicodeソフトを書こうと考えているみなさんもおねがいしまつ。U+2014にして下さい。

Unicodeは決して多言語化を実現しませんし、こういった深刻な符号の対応
問題を抱えていますので、Unicode「だけ」サポートして事足れりと考えないで
ください・・・・むしろ、JISとの対応に対してきちんと理解しないで使うよりは、
むしろできるだけ使わない方向でお願いします・・・　データが穢れます。

(参考):http://hp.vector.co.jp/authors/VA010341/unicode/

JIS 1-29 は、U+2015 と U+2014 のどちらかが正しいというものではありません。
JDK1.4 互換と CP932 互換の両方の変換テーブルを揃って用意してもらわないと、
困ります。

Unicode ソフトを書こうと考えているみなさんも、おねがいします。
U+2015 と U+2014 のどちらか「だけ」サポートして事足れりと考えないでください。

ここに書いても伝わらないだろう...

>>67
しかも、その日本語のページよりも上位のサイトは
どれも韓国語で書かれてない（ｗ

下世話なことですが、
ウンコードには笑いました。

Uncode
確かにﾜﾛﾀ

愛が足りないとうんこになっちゃうってことか。一つ勉強になりますたよ（藁

>>68
ふと思いついて、set rprompt='%B%n@%m%b' していたのをやめてみました。
かなりマトモに表示さえるようになりました。
ls-F の表示カラムがずれてしまうのはあいかわらずですが、
それ以外はかなりマトモ。
C-a や C-e でカーソルを移動したときに変な位置へ飛ぶとか、
細かいところで色々怪しいですが、C-l でマトモな位置へ移動します。
あと一歩足りないところを修正して tcsh 本体へパッチ投げてくれないかなぁ

>>70
「正しい」のはU+2014 (EM DASH)だよ。JISで規定されてるからね。

ただ、Unicode Consortiumのサイトに置いてある変換表(今はobsolete)に
バグがあって、U+2015 (HORIZONTAL BAR)になっていたのが尾をひいて、
いまだにこちらを使い続けている実装があるというのが現状。

今後は、出力は必ず U+2014にして、入力にはU+2015も許す(JIS 1-29に変換)
というのが妥当かと。

CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。

X 0213:2000にもバグがありましたね。
0221 名前
---- ----
2015 EM DASH
ってどっちやねん(正誤表で2014に訂正されたけど)

> CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。
IANAの登録簿でもWindows-31Jは
> but it is of limited or specialized use (see RFC2278).
と明記されてますね。

でも0x5CがYEN SIGNになるから
Webアプリケーションでは規格票に100%忠実なShift_JISの実装は
事実上不可能ですけど。
JDK 1.4の実装も0x5CはREVERSE SOLIDUSにマップしてますね。

>>77
JISの世界の話としては同意。
CP932の世界ではU+2015が「正しい」というのも前提とするとして、

「限定された環境下」であるところのWindowsが採用するCP932の世界が
unicode-日本語系コード変換の実装としては量的に圧倒的に多い、
というのを無視できるアプリケーションならともかく、
エディタなりウェブアプリなり、CP932の世界が絡む可能性があるなら、
ユーザーにJISとCP932の選択権があるべきじゃないかな？

cp932なりGNUな環境でjis規格ベッタリな変換したら化ける罠。
対象となる環境にあわせてベンダ固有のに従うのが吉かと。

ていうか、変換テーブル大杉。
ttp://www.debian.or.jp/~kubota/unicode-symbols-map2.html

Unicodeで文字幅を取得する(なるべく)ポータブルな方法(特にCJK「以外」)
が知りたいのですが、mltermやw3m-m17nあたりからパク^H^H^H^Hを参考にする
くらいしか手はないでつか?
# ひたすらぐぐってみたんですが、どーにもよさげな情報が……。

文字幅って半角何文字分かということ？
亜がAの2文字分っていう前提からしてフォント依存なのに、
なるべくポータブルの意味がわからん。
「これこれのフォントを使っている」という前提がどこかに必要。

>>82
ここよりpfaeditとかいじってるやつがいるところで聞いた方がいいんじゃないかな？

>>83
フォントのメトリックを含めて取得したいという意味では?

>>23 を読むと rxvt でなんとかしたい模様。

>>83
> 文字幅って半角何文字分かということ？
うぃ。
> 亜がAの2文字分っていう前提からしてフォント依存なのに、
あー、とりあえずターミナルエミュレータとゆーか固定ピッチフォントのみの
世界限定の話です。目的はcocotで変換不能文字を適切なカラム数でスキップす
ることなんで……。(とは言え、ここでがんばったとしてもEast Asian Width
でambiguousになる文字についてはどーにもこーにもcocotのよーなレイヤでは
整合性なんか取りよーがなさそげなので、これはこれで鬱)
>>84
フォントエディタですか。うーん、ちょっと関心のある部分が違うよーな。気
にしているのはUnicode文字列をターミナルエミュレータ上でどうハンドリン
グするかなので。

ぐぐるとemacs-w3m MLのアーカイブとかひっかかるんだけど、先人が(ン年前
に)はまった泥沼に足突っ込んでるオカ〜ン。最新の情報はどっかにまとまっ
てないもんか……。
# 調査すべきもの: 最近のxterm、luit、mlterm、w3m(0.5にはlibwcが入って
# るみたいなので、w3m-m17n相当?)、emacs、他に何かあるかなぁ。

wcwidth, wcswidth じゃダメかね

フォントの幅ならX{mb,wc}TextEscapement。

tcsh スレに utf-8 パッチが投稿されていた。
でも 2 バイトまでの utf-8 までしか扱えないという不完全なもの。
>>68 のほうがまだマシだよ。

>>89
cygwinのはまだi18n化がまっとーじゃなかったよーな……。
# 試してみよーかとは思うけど、1しか返ってこなかったら悲しい。

> tcsh スレ
ってどこ? tcshで検索しても出てこない
> 2 バイトまでの utf-8
それってCJKはぜんぜん対応してないってことじゃん…

テストコードを書こうとして調べていたのですが……。
ttp://www.okisoft.co.jp/esc/cygwin-5.html#5.3
だめぢゃん＿|￣|○
# wide character系の関数はことごとく期待できないとゆーことで
# ファイナルアンサー?(;_;)＞cygwin

>>93 すまん。tcsh-ml の間違いだった。

>>93
> > 2 バイトまでの utf-8
> それってCJKはぜんぜん対応してないってことじゃん…

なかなか笑わせてくれるなｗ＞cygwin

>>96 tcsh の話と cygwin の話はぜんぜん関係ないぞ

>>89
しつこくて済みませんが、cygwin1.dllのソース見てみました。
int
_DEFUN (wcwidth, (wc),
_CONST wchar_t wc)

{
if (iswprint (wc))
return 1;
if (iswcntrl (wc) || wc == L'\0')
return 0;
return -1;
}
はっはっはっはっ……。

>>98
IBMのICUでできそうな。おおげさかね？
こんなかんじ。

#include <icu/uchar.h>
UEastAsianWidth ea = (UEastAsianWidth)u_getIntPropertyValue(c, UCHAR_EAST_ASIAN_WIDTH);

厳密には幅そのものじゃないけど。まぁ使えそう。

>>99
情報感謝。ICUは盲点ですた。でも残念ながらCJK「以外」の文字(列)に関する
文字幅も欲しいんです……。ICUのドキュメントを眺めてみたところでは、そー
ゆーのを直接取得する手段はなさそうな感じ。死ぬほどプロパティが付随して
るので、必要なものを組み合わせてごりごり処理すれば何とかなるかもしれま
せんが、さすがにンな気力は……。
# このあたりの情報がろくに引っ掛かってこないのは、
# 英米(Latin1が使えたらえーやん)
# ＜欧州(Latin*が使えたらえーやん)
# ＜日中韓(CJKが使えたらえーやん)
# 状態になってるから?
産総研のm17n-libも調べてみたけど、やっぱりそのあたりをハンドリングする
手段はないよーな。
テキスト系アプリケーション(特に端末制御するもの)って、アプリと端末エミュ
レータの認識が一致していないと正しく動かないはずなのに、Emacsもw3mも
xtermもmltermもみーんな独自の世界でやってるよーに見えるなぁ……。
# ただ単にcocotにちょっとしたパッチを当てよー、と思っただけなのに何で
# こんなにハマるんだか(´_｀;

East Asian Widthプロパティって、Not East Asianなら半角幅やん。
結局CJK以外でも文字幅は判る(Ambiguous以外)。
ttp://www.unicode.org/reports/tr11/

それとも漏れ何か勘違いしてる？＞識者