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

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

>>24
こうすれば見える。最後の2行はおそらく必要なし。
(let* ((utf-8-p
　　　　(let ((case-fold-search t))
　　　　　(string-match "ja_JP.UTF-?8" (getenv "LANG"))))
　　　 (cs (if utf-8-p 'utf-8 'euc-japan)))
　(condition-case ()
　　　(progn
　　　　(require 'un-define)
　　　　(require 'un-supple)
　　　　(un-supple-enable 'windows))
　　(error nil))
　(set-language-environment "japanese")
　(set-default-coding-systems cs)
　(set-terminal-coding-system cs)
　(set-keyboard-coding-system cs)
　;;(setq coding-category-iso-8-2 cs)
　;;(setq file-name-coding-system cs)
　)

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

ところで、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/

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

うむ、等幅フォントというくらいだから本来はすべて同じ幅のはずなのだ。
CJKのほうがある意味特殊。

>>101
一概には言えない。おいらが気付いている範囲では、
ttp://www.unicode.org/versions/Unicode4.0.0/ch05.pdf
5.6 Normalization
5.8 Newline Guidelines
5.10 Language Information in Plain Text
あたりが頭痛の種かと。
# MacOSXで濁点・半濁点が正規化されてるのは割と有名な話。5.8や5.10は、
# どーせンなもん使ってるシステムなんてあらへんやろ、と割り切れそーだけ
# ど、5.6だけはなぁ……。
他にも、Bidi(Bidirectional Algorithm)ってターミナルエミュレータではどー
扱うことになってんの、とか、他にも気付いてない謎仕様があるんだろーなぁ、
とか……。

Bidiはmltermをデファクトスタンダードとして広めてしまえ。
他に対応している端末エミュレータなんて無いだろ？

>>91
よく見たらちゃんと 3 バイトにも対応してた。
けど日本語のファイル名補完できない(´･ω･｀)

ja_JPなのになんでBidiが関係あるの?

>>106
そのためのUTF-8なんじゃない？

さまざまな言語のテキストから
% grep '毛沢東'

>>107
それだと Mao Ze-dong や Мао Цзе-Дун を
検索することができないよ。

つーか
繁体字中国語では「毛澤東」
簡体字中国語では「毛？x6CFD;？x4E1C;」だから
Unicodeでもgrep '毛沢東'に意味がないのは明白なんだが。
誰が広めた都市伝説なんだろうか。

う、UNIX板は文字参照が使えないのか

そこで Han unification ですよw

だから毛沢東は統合されてへんねん
つーか>>106からどんどん話がそれていくんだが

Debian:i18nキタ━━━━━━(゜∀゜)━━━━━━!!
http://ukai.org/wiliki/wiliki.cgi?Debian:i18n&l=jp

東大のコンピュータシステムのMacOS Xではja_JP.utf-8 になりました．
現在TAのチームがひたすらラッパやパッチを作っているようです．
そのうち各ソフトウェアの本家に還元されるかもしれません．

Mac OS X ということは NFD ですか

ワイド版ncursesを使ったり、libtextwrapを使ったり、fribidiを使ったり
ということでしょうか

ja_JP.UTF-8 環境で、bash で PS1=長い日本語プロンプト
なんてことをすると、行の折り返し位置の計算が間違ってる
みたいですね。バイト数とカラム数を同一視してるみたい。

Apacheつかって表示するファイル一覧もなー(サイズの位置とかがずれる)

cygwin 専用 utf-8 対応端末エミュレータ
http://www.geocities.co.jp/SiliconValley-PaloAlto/8946/

>>114TAじゃないよん。ちなみに学部生ばっかりなので期待しない方がいいかもしれない。

screen も utf-8 対応してる。
eucjp やその他の euc、sjis、big5、iso8859-x 等々にも対応している。
実際の表示端末に使う encoding と各スクリーンに使う encoding を
それぞれ独立して設定できるので cocot や luit、ttyconv と同様のことができる。
例えば、utf-8 対応の xterm 配下でスクリーン 1 を eucjp、スクリーン 2 を sjis、
スクリーン 3 を utf-8 で動かすといったことが可能。
実行中、他に影響を与えることなく変更することも可能。

で、最近はまともに生活できるようになってるんですか。

EUCからUTF-8にすると遅くなったりしないの？
少なくとも2バイトから3バイトになった分のメモリは使ってるんでしょ。
これは微々たる物だと思うけど、webでは流行らないんじゃないかな。
たとえば掲示板系の大手サイトがsjisからUTF-8に移行したりすると
転送量増えそうだし（でも、圧縮とかすれば問題ないのかな
画像一枚の方が負荷的には大きいけど、文字だけでも結構あると思うよ。

最近はライブラリとかツールキットで内部はUCS4とかUTF8とかが
あるから、そういう場合は逆に変換の手間がなくなるかと。

Webページについては、掲示板のたぐいはたしかにメリットがないかも。
翻訳とか、複数言語を同時に表示する必要があるところでは
使われるだろうな。

>翻訳とか、複数言語を同時に表示する必要があるところでは

おお、まさにうちだ。
とある洋ゲーの英文テキストを多人数でよってたかって翻訳するwikiみたいなCGIなんだが
原文にウムラウトやアクサンの入った固有名詞が頻出してるので
DBの内部コードから表示系まで全部 UTF-8 で作った。

いわゆる先進国の言語だけ扱うんだったら、それはそれは
便利なコードだからね。

>>122
UTF-8はEUC-JP, ISO2022-JP, WindowsSJIS(Windows-31J)のすべての
特殊文字を含んでるので、どの環境でもすべての文字が正しく読めるメリット
はあると思いますよ。さらに付け加えると、WindowsSJISは本来のShisftJIS
の仕様にはない文字があるし、それから「〜」がShiftJISの仕様書と異なる
コードになってます。この辺の問題はUnicodeとかUTF-8にする事でだいたい
解決できます。

メールもUTF-8で出していいですか？

>>128
受ける側が読めるなら。

>>129 つまり携帯以外ですか？

メールのために UTF-7 があるが、まず使われないだろうな…

お前ら勘違いしてませんか？
ここは ja_JP.UTF-8 のスレであって，Unicode のスレではない．

Unicodeのスレはどこにありますか?
なかったとして何板に立てるのが適切ですか?

>>133
http://pc5.2ch.net/test/read.cgi/linux/1003159137/

xmmsでwinampとtagを共有するには使えない

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

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

別にいわゆる半角文字に限らなくてもいいんでない？
端末によっては表示できない文字だってあるだろうし、それをどう扱うかは
端末が勝手に決めればいいんじゃないの？
結果として端末によっては、?で表示されたり、〓で表示されたり、\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)
もかな。

>>296
さん　　utf-8 >> utf-8-unix
と　変えてみました
なんとかいけそうです　ありがとうございました。

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にも関係ないし。

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

>>342
utf-8は最短の表現以外は仕様で許さなくなったね。
複数表現があると禁止リストの回避がセキュリティ上の問題になるから。

なるほどね(´・ω・`)

仕様が「許さない」といったってそれを強制できない以上は備えるしかあるまいよ。

それはもちろんだ。きちんとエラーとして処さないといけない。

ぬるぽ

ﾇﾙﾎﾟ

>>353
ｶﾞｯ

時々、文字コードを思い出したように変えるのは止めて欲しい。
既存の製品等をオブソレートにして市場から除去する為の口実ぢゃないか？

>>355
一体何の話？

グリフのことを言いたいんじゃないのか？

なんというか何もかも間違ってるレスだなそれ。

グ・グ・グリフの大爆笑

最近のLinuxって、LANG=ja_JP は ja_JP.UTF-8 ですか？それともja_JP.EUCですか。

sjis>>360

>>360
ふつー UTF-8

日本語１文字が何バイトになっているのかなＵＴＦ８は？

$ echo -n "日本語１文字" | wc -c
[Gnome] アプリケーション→アクセサリ→文字マップ

ぬるぽ

スレタイトルの改名が必要じゃないか？

＞Linux で ja_JP.EUC ロケールで暮らす方法についてのスレです。
いいかげんEUCは止めて欲しい。SJISを使えみたいな話と同じだ。
いまさらEUCがデフォなのってどんな鳥？

釣り針にすらなってないただのまっすぐな針金だな

>>366
次スレで変更よろ

Windows７のNFSサービスがEUCやShiftJISに対応してるのに
意図的なのか本気で不要と考えてるのか、UTF-8に対応してないの知ってビビった。
クソ高いUltimate買わないどNFSサービスついてないくせに。
実質WinのNFSサービスは使い物にならん。

そもそもWinとNFSではロックのセマンティクスが違うし。

Jconsole消滅
KON-UTF8化消滅
Utf8-kernel消滅
UNICON消滅

カーネルレベルでUTF8対応するのを阻む流れがあるんでしょうか？
>>366
たぶんBSDなら使える。Linuxじゃないって？だからLinuxでは拒否

X window systemがｸﾗｲｱﾝﾄに特化できないからこそGPUﾀﾞｲﾚｸﾄで描画できない
GUI上だけがLinuxでいいじゃないかという奴とCUIがLinuxだという流れで
争っているからこそｶｰﾈﾙﾚﾍﾞﾙでUTF8が実装されない(表示できない)

そもそもconsole自体kernelからなくそうという動きもあるしな。

Unicode対応をまじめにやるのは大変。
サロゲートペアとか合成文字とか異体字セレクタとか。
どこまで実装して、どこでサボるかを見極めるのすら難しい。

EXT2、EXT3がNLS機能に対応せず。
UTF8でujis,eucJPに対応できない問題をどうすればいいの？

必要ない。> ujis,eucJP

>>375
おまえが人類には必要がない人間。