ja_JP.UTF-8

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

>>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