ja_JP.UTF-8

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

文字幅って半角何文字分かということ？
亜が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に変換できる・・・はずです。
うまくいかない場合は教えてください。