X
トップページ⇒Linux
377コメント121KB
ja_JP.UTF-8
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
垢版 |
04/02/19 17:09ID:EuXdEmYH
Linux で ja_JP.UTF-8 ロケールで暮らす方法についてのスレです。
0002login:Penguin
垢版 |
04/02/19 17:10ID:jzhqSI1H
2
0004login:Penguin
垢版 |
04/02/19 17:28ID:EuXdEmYH
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 以下にロケールデータができる。
0005login:Penguin
垢版 |
04/02/19 18:17ID:xXNDJeIj
cocot ってよさげっぽいな。
これを使えば utf-8 を扱えないターミナルでも
$ cd 新規フォルダ
とかが出来るようになる？
0006login:Penguin
垢版 |
04/02/19 18:28ID:EuXdEmYH
>>5
できますが、(cocot のせいではないが) シェル自体が utf-8 にちゃんと
対応していないと表示が乱れます。
使い方⇒
cocot -p utf-8 ssh hoge.co.jp
0007login:Penguin
垢版 |
04/02/19 18:35ID:wXxKmQwW
Debian関係:UTF-8
ttp://tagoh.jp/w/wiliki.cgi?Debian%b4%d8%b7%b8%3aUTF-8&l=jp
0010login:Penguin
垢版 |
04/02/19 22:18ID:xXNDJeIj
>>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 ってある？
0011login:Penguin
垢版 |
04/02/19 22:22ID:EuXdEmYH
>>10
tcsh は対応してることになっているけど、
マルチバイトの utf-8 文字がちゃんとずれずに表示されるかどうかは不明。

emacs + mule-ucs + M-x shell で、
process-coding-system を utf-8 にしたらうまくいくかも…
0013login:Penguin
垢版 |
04/02/19 22:36ID:xXNDJeIj
>>10
ちゅうか、これ cocot を使わずとも

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

とすればいいですね。

>>11
tcsh 試してみます。
0014login:Penguin
垢版 |
04/02/19 22:47ID:5Wvc5pyS
しかし、この状況ではja_JP.eucJP並にja_JP.UTF-8が使えるとは思えないのだが、
Fedoraは何で採用してんだ？ 実験的ディストリったって、早過ぎないかね。
0015login:Penguin
垢版 |
04/02/19 23:04ID:5dM6BKnm
Fedora使ってますが、TeX関連とWnn7がUTFだと面倒みたいなので
EUC環境に避難中です。
0016login:Penguin
垢版 |
04/02/19 23:08ID:aWaxrpHY
bash自体(2.05b)はUTF-8に対応してるんじゃないの?
日本語の上でカーソル移動させてもちゃんと文字単位で移動する


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

プロポーショナル文字フォントを有効にできれば
(そのうえで固定幅文字フォントを指定すれば)解決しそう
(mltermではできる)が、gnome-terminalではそんな設定はない。
0017login:Penguin
垢版 |
04/02/19 23:15ID:aWaxrpHY
あ、あとmanというのもあったな。
man page自体には言語情報は含まれていないっぽくて
man pageのエンコードのまま出力されてしまう。
gettextみたく文字コード変換機能がついていればいいんだが。
0018login:Penguin
垢版 |
04/02/19 23:57ID:EuXdEmYH
>>13
その例自体はそうですが、
cocot の利点は仮想端末を提供してくれるというところですね。
あと >>4 にあるように iconv には色々問題があったり…
(cocot も libiconv を使うだけなので同じ問題を内包してますが)
0019login:Penguin
垢版 |
04/02/20 00:46ID:J9DGChFD
すんません。
>>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 てすと' が、できなかったけど、常用してないので
# 詳しく調べてません。
0020login:Penguin
垢版 |
04/02/20 01:36ID:UfU4oXPS
どうせならLANG=ja_JP.UTF-8した後にさらにbash起動したほうがよいかと
cd てすと
はうまく動くけど、あとからヒストリ編集するとぐちゃぐちゃになる。
0021login:Penguin
垢版 |
04/02/20 01:40ID:UfU4oXPS
と思ったらLANG=ja_JP.UTF-8とやれば現行シェルもちゃんと切り替わるな
LANG=ja_JP.UTF-8 ls とかやると(変更がその場限りなので)ダメだが
0022login:Penguin
垢版 |
04/02/21 14:03ID:+LxRviDa
Debian sid, KDE 3.2でLANG=ja_JP.UTF-8で使ってます。
ja_JP.EUC-JPから移行するときはゴミ箱に注意。
名前が化けて消しにくいファイルができて往生します。
0023login:Penguin
垢版 |
04/02/23 00:15ID:cAXIkKBR
いろいろやってみた。

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?) へ変換できなかった文字をそのままのバイト数で
# へ変換するようだが、おかげで、カーソル位置とずれる。
0024login:Penguin
垢版 |
04/02/23 00:27ID:cAXIkKBR
それから、emacs で utf-8 のフォルダの中にあるファイルを
開こうと思った。表示がくずれてわけわかりません。
set-filename-coding-system みたいなものってあるのでしょうか？
どうもファイル名などが euc だと思われてしまっているようです。
0025login:Penguin
垢版 |
04/02/23 00:30ID:PMf+9Ivm
関係ないけど luit 面白いよ。
0026login:Penguin
垢版 |
04/02/23 00:30ID:CMqbSbol
喪前らfedorasu刷れへかいれ！
0027login:Penguin
垢版 |
04/02/23 00:33ID:cAXIkKBR
さらに、tcsh-6.12.02 を make して utf8 ファイル名のフォルダへ
移動してみた。
set dspmbyte=utf8
という指定をしておけば、cd UTF8フォルダ、など補完もきく。
ls-F でも UTF8 ファイル名は一応表示できる。

だがしかし、tcsh は日本語の UTF8 文字を半角 3 文字分の
幅だと認識しているようで、カーソル位置が激しくずれる。
0030login:Penguin
垢版 |
04/02/23 01:08ID:PMf+9Ivm
cocot は初めて知ったのでよくわかりませんが、
luit は utf-8 さえ表示できればいろんなロケールの表示が可能になるやつです。
むしろ cocot の逆ですかね?
X の標準に入ってて、
XFree86 4.3 からは xterm で自動起動されるようになってます。
フォントさえ設定してあれば、
LANG=ja_JP.eucJP xterm で日本語表示可能。
0031login:Penguin
垢版 |
04/02/23 01:46ID:q2htmMvi
以前 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
の両方が利用できる。
0032login:Penguin
垢版 |
04/02/23 07:23ID:hEHXw/KY
>14
昔から赤帽の日本語環境・デスクトップ環境はだーれも期待してなかった。
Fedoraはその伝統をしっかり受け継いでいる。
0033login:Penguin
垢版 |
04/02/23 18:58ID:zGIsbfM2
>>14
決まってるぢゃん。
JISやらGBといった漢字文化を潰し、欠陥unicodeをCJKの人々にも
強要して西洋人が楽するために決まってるでしょ。
彼らはCJK環境を「CJKのユーザのため」を第一に改善しようとは決して思っていない。
自分らが楽をする事は考えてるけどな。

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

UTF-8使う=売国、って事でOK?
0036login:Penguin
垢版 |
04/02/24 21:47ID:O5/fwBER
CJK統合漢字は事実上中国が決めてることも知らない人が
いるスレはここですか?
> UTF-8使う=売国、って事でOK?
はっ、結論が変わらない
0037login:Penguin
垢版 |
04/02/25 02:50ID:545ZflI/
ところで、UTFは何の略？

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

などの説明がみつかる。８は８ビット。
0038login:Penguin
垢版 |
04/02/26 11:43ID:acWb0Ca5
>>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)
　)
0039login:Penguin
垢版 |
04/02/26 11:45ID:acWb0Ca5
必要なし、とか書いたら丁度省略されたな…

ところで、Fedora の人は utf-8 環境でもあまり困ってないのかしら。
端末エミュレータも最初からutf-8に対応してるみたいだし…
0040login:Penguin
垢版 |
04/02/26 16:57ID:6SrjPF7S
>>39
困りまくりw
結局euc-jpに戻して使ってる。
0041login:Penguin
垢版 |
04/02/26 17:41ID:rQy1jDD8
>>33
ｅｕｃはともかく、sjisじゃ幸せになれないよ・・・
0042login:Penguin
垢版 |
04/02/26 18:18ID:rR8Lcw99
>>41
つうかSJISなlocaleは未だにサポートされてないし。
Big5はあるのに。
0043login:Penguin
垢版 |
04/02/26 22:34ID:ZY4sGg1m
ないなら作ればいい
localedefで作成できたはず
RedHat8あたりからそうやってSJISとUTF-8のロケール作っていたが
(常用していたのはUTF-8のほう)

いまEUC-JPでないと困るソフトってどれくらいあるかな
lynxとかそうだけど使わないし。tcshはビミョーに使えないな。
Xのソフトはフォント設定で何とかなることが多い。
RedHat9時代はEmacsも使えなかったがFedoraで使えるようになった。
0046login:Penguin
垢版 |
04/03/08 18:20ID:knQdpHRd
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 のフォントも使えますね。こりゃいい。

0049login:Penguin
垢版 |
04/03/08 19:42ID:dmU+GFkA
>>47
マジかよ@3
ま た き た か ( 別に逝いけどw
0050端末スレに書いた人
垢版 |
04/03/08 20:07ID:CDAnHB+K
>>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 を使うようなことができます。
0051login:Penguin
垢版 |
04/03/08 21:28ID:dmU+GFkA
urxvt詳細解説希望。KTermみたいな感じで日本語入力できないの？

# KTermのUTF-8パッチないのぉ?
# UXTermはフォント設定がよくわからん。-alias-fixed使いたいyo
0052login:Penguin
垢版 |
04/03/10 16:40ID:XYz8ACQw
>>51
--enable-ximってしてもximが聞かないなあ
0053login:Penguin
垢版 |
04/03/11 16:09ID:w0ox2sq1
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 本体に取り込んでもらうつもりはないのかな…？
0054login:Penguin
垢版 |
04/03/11 16:11ID:w0ox2sq1
そうそう、emacs 上で HELLO を表示すると、さすがに化け化けになる。
文字幅を適切に反映してくれるだけで、もうちょっとマトモに見えそうなもんだが。
0055login:Penguin
垢版 |
04/03/11 17:03ID:5SXwbIF3
>>53
Brunoに送ったらしいけど、まだ取り込まれていない。理由はようわからん。
glibcの方はもう取り込まれてるんだけど。
0056login:Penguin
垢版 |
04/03/11 18:04ID:w0ox2sq1
>>54UNICODE の文字の固定幅ってどうやったらわかるのでしょう?何かそれっぽい API が存在するのかな… iconv には見当たらないが。
0057login:Penguin
垢版 |
04/03/11 18:14ID:5SXwbIF3
libc的にはwcwidth()を使えばカラム数は取得できる。
もちろんlocale依存だけど。
0058login:Penguin
垢版 |
04/03/11 22:28ID:w0ox2sq1
>>57
locale に依存しない方法がほしいですねぇ(´･ω･｀)
0059login:Penguin
垢版 |
04/03/11 23:31ID:O42OfURm
>>58
East Asian Width
ttp://www.unicode.org/reports/tr11/tr11-11.html
↑これを見れ。

ED6. East Asian Ambiguous (A)
のおかげで、どうがむばってもlocale依存だすよ。(´･ω･｀)
0060login:Penguin
垢版 |
04/03/12 04:06ID:r4gmyMD+
>>59
あ、そうではなくて、
プログラム自身は A というlocaleで動いているが、
B という locale での幅を知りたい場合とか。
int wcwidth(wchar_t c, locale_t locale)
みたいな感じにしておかないと困らないかね…？
0062login:Penguin
垢版 |
04/03/12 23:18ID:r4gmyMD+
>>61
誤爆？API関数の話だから言語は関係ないと思うけど。
0063login:Penguin
垢版 |
04/03/13 00:38ID:WWQ2I/Yq
>>62
Cのlocaleはglobal、C++のlocaleはnon-globalなobjectという
非常に大きな違いがあるが。
0064login:Penguin
垢版 |
04/03/13 01:34ID:Olzrdh4Q
>>63
Σ(゜д゜|||)ﾏｼﾞｽｶ
ぜんぜん知らなかった。良かったらその辺の話へのポインタを教えてくださいませ。
0066login:Penguin
垢版 |
04/03/15 17:16ID:arceEVVZ
>>23
UTF-8のときは桁数を考慮するよー修正を検討してみまつ。
しばしお待ちください。(GANAさんとこのパッチも取り込んでおかんと……)
# wcwidth()は使えなさそうだなぁ。>>59を見て考えるか。
0067login:Penguin
垢版 |
04/03/16 04:01ID:ByfzHSPG
全然関係ないけどhttp://www.google.co.krで「utf-8」を検索すると１ページ目の一番最後の所に
何故か日本語のページが出て来ますね。それにそこもutf-8で書かれているぽ
0068login:Penguin
垢版 |
04/03/16 19:59ID:4DIxjUwA
ところで、tcsh は utf8 に対応してることになってますが、
3バイトの文字が来たり、補完したりすると化け化けになります。
http://www.tech-arts.co.jp/macosx/macosx-jp/htdocs/15300/15330.html
このパッチ当ててみたりしましたが、上手く動いてるとはいいがたいような。
誰か解決方法しりません？
0069login:Penguin
垢版 |
04/03/17 01:51ID:8JDKSyga
というか、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/
0070login:Penguin
垢版 |
04/03/17 07:09ID:cehwlQdD
JIS 1-29 は、U+2015 と U+2014 のどちらかが正しいというものではありません。
JDK1.4 互換と CP932 互換の両方の変換テーブルを揃って用意してもらわないと、
困ります。

Unicode ソフトを書こうと考えているみなさんも、おねがいします。
U+2015 と U+2014 のどちらか「だけ」サポートして事足れりと考えないでください。
0071login:Penguin
垢版 |
04/03/17 09:36ID:v1NfxXgC
ここに書いても伝わらないだろう...
0072login:Penguin
垢版 |
04/03/17 19:28ID:/v+B0EmE
>>67
しかも、その日本語のページよりも上位のサイトは
どれも韓国語で書かれてない（ｗ
0073login:Penguin
垢版 |
04/03/17 22:19ID:OPdte4Z/
下世話なことですが、
ウンコードには笑いました。
0075login:Penguin
垢版 |
04/03/19 16:32ID:WDcHt9kU
愛が足りないとうんこになっちゃうってことか。一つ勉強になりますたよ（藁
007668
垢版 |
04/03/23 03:47ID:Wz1FIJjA
>>68
ふと思いついて、set rprompt='%B%n@%m%b' していたのをやめてみました。
かなりマトモに表示さえるようになりました。
ls-F の表示カラムがずれてしまうのはあいかわらずですが、
それ以外はかなりマトモ。
C-a や C-e でカーソルを移動したときに変な位置へ飛ぶとか、
細かいところで色々怪しいですが、C-l でマトモな位置へ移動します。
あと一歩足りないところを修正して tcsh 本体へパッチ投げてくれないかなぁ
0077login:Penguin
垢版 |
04/03/25 09:01ID:aLdLDvmf
>>70
「正しい」のはU+2014 (EM DASH)だよ。JISで規定されてるからね。

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

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

CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。
0078login:Penguin
垢版 |
04/03/25 11:34ID:n6uaZHdd
X 0213:2000にもバグがありましたね。
0221 名前
---- ----
2015 EM DASH
ってどっちやねん(正誤表で2014に訂正されたけど)

> CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。
IANAの登録簿でもWindows-31Jは
> but it is of limited or specialized use (see RFC2278).
と明記されてますね。
0079login:Penguin
垢版 |
04/03/25 12:00ID:n6uaZHdd
でも0x5CがYEN SIGNになるから
Webアプリケーションでは規格票に100%忠実なShift_JISの実装は
事実上不可能ですけど。
JDK 1.4の実装も0x5CはREVERSE SOLIDUSにマップしてますね。
0080login:Penguin
垢版 |
04/03/25 13:06ID:AqIEMmRl
>>77
JISの世界の話としては同意。
CP932の世界ではU+2015が「正しい」というのも前提とするとして、

「限定された環境下」であるところのWindowsが採用するCP932の世界が
unicode-日本語系コード変換の実装としては量的に圧倒的に多い、
というのを無視できるアプリケーションならともかく、
エディタなりウェブアプリなり、CP932の世界が絡む可能性があるなら、
ユーザーにJISとCP932の選択権があるべきじゃないかな？
0081login:Penguin
垢版 |
04/03/28 01:30ID:XvF+To5+
cp932なりGNUな環境でjis規格ベッタリな変換したら化ける罠。
対象となる環境にあわせてベンダ固有のに従うのが吉かと。

ていうか、変換テーブル大杉。
ttp://www.debian.or.jp/~kubota/unicode-symbols-map2.html
008266
垢版 |
04/03/30 02:07ID:c1zMVIom
Unicodeで文字幅を取得する(なるべく)ポータブルな方法(特にCJK「以外」)
が知りたいのですが、mltermやw3m-m17nあたりからパク^H^H^H^Hを参考にする
くらいしか手はないでつか?
# ひたすらぐぐってみたんですが、どーにもよさげな情報が……。
0083login:Penguin
垢版 |
04/03/30 10:23ID:2+ZkdaEN
文字幅って半角何文字分かということ？
亜がAの2文字分っていう前提からしてフォント依存なのに、
なるべくポータブルの意味がわからん。
「これこれのフォントを使っている」という前提がどこかに必要。
0084login:Penguin
垢版 |
04/03/30 10:44ID:D5b8R0dA
>>82
ここよりpfaeditとかいじってるやつがいるところで聞いた方がいいんじゃないかな？
0085login:Penguin
垢版 |
04/03/30 11:27ID:+N0HhOX2
>>83
フォントのメトリックを含めて取得したいという意味では?
0086login:Penguin
垢版 |
04/03/30 11:30ID:ApCTMVrY
>>23 を読むと rxvt でなんとかしたい模様。
008766=82
垢版 |
04/03/30 11:43ID:c1zMVIom
>>83
> 文字幅って半角何文字分かということ？
うぃ。
> 亜がAの2文字分っていう前提からしてフォント依存なのに、
あー、とりあえずターミナルエミュレータとゆーか固定ピッチフォントのみの
世界限定の話です。目的はcocotで変換不能文字を適切なカラム数でスキップす
ることなんで……。(とは言え、ここでがんばったとしてもEast Asian Width
でambiguousになる文字についてはどーにもこーにもcocotのよーなレイヤでは
整合性なんか取りよーがなさそげなので、これはこれで鬱)
>>84
フォントエディタですか。うーん、ちょっと関心のある部分が違うよーな。気
にしているのはUnicode文字列をターミナルエミュレータ上でどうハンドリン
グするかなので。
008866
垢版 |
04/03/30 12:09ID:c1zMVIom
ぐぐるとemacs-w3m MLのアーカイブとかひっかかるんだけど、先人が(ン年前
に)はまった泥沼に足突っ込んでるオカ〜ン。最新の情報はどっかにまとまっ
てないもんか……。
# 調査すべきもの: 最近のxterm、luit、mlterm、w3m(0.5にはlibwcが入って
# るみたいなので、w3m-m17n相当?)、emacs、他に何かあるかなぁ。
0089login:Penguin
垢版 |
04/03/30 18:12ID:8/uyDw3m
wcwidth, wcswidth じゃダメかね
0090login:Penguin
垢版 |
04/03/30 19:34ID:6qOQKc6W
フォントの幅ならX{mb,wc}TextEscapement。
0091login:Penguin
垢版 |
04/03/30 21:19ID:cj3Zi+AV
tcsh スレに utf-8 パッチが投稿されていた。
でも 2 バイトまでの utf-8 までしか扱えないという不完全なもの。
>>68 のほうがまだマシだよ。
009266
垢版 |
04/03/31 02:45ID:f7K9ZfXB
>>89
cygwinのはまだi18n化がまっとーじゃなかったよーな……。
# 試してみよーかとは思うけど、1しか返ってこなかったら悲しい。
0093login:Penguin
垢版 |
04/03/31 09:49ID:6/tPX99p
> tcsh スレ
ってどこ? tcshで検索しても出てこない
> 2 バイトまでの utf-8
それってCJKはぜんぜん対応してないってことじゃん…
009466
垢版 |
04/03/31 10:53ID:f7K9ZfXB
テストコードを書こうとして調べていたのですが……。
ttp://www.okisoft.co.jp/esc/cygwin-5.html#5.3
だめぢゃん＿|￣|○
# wide character系の関数はことごとく期待できないとゆーことで
# ファイナルアンサー?(;_;)＞cygwin
0095login:Penguin
垢版 |
04/03/31 12:55ID:aNoBOFKp
>>93 すまん。tcsh-ml の間違いだった。
0096login:Penguin
垢版 |
04/03/31 15:40ID:BTqfWFS5
>>93
> > 2 バイトまでの utf-8
> それってCJKはぜんぜん対応してないってことじゃん…

なかなか笑わせてくれるなｗ＞cygwin
0097login:Penguin
垢版 |
04/03/31 16:49ID:aNoBOFKp
>>96 tcsh の話と cygwin の話はぜんぜん関係ないぞ
009866=92=94
垢版 |
04/03/31 17:10ID:f7K9ZfXB
>>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;
}
はっはっはっはっ……。
0099login:Penguin
垢版 |
04/03/31 17:58ID:o1W2fgfD
>>98
IBMのICUでできそうな。おおげさかね？
こんなかんじ。

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

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

それとも漏れ何か勘違いしてる？＞識者
0102login:Penguin
垢版 |
04/03/31 21:35ID:ZB8ltdIE
うむ、等幅フォントというくらいだから本来はすべて同じ幅のはずなのだ。
CJKのほうがある意味特殊。
010366
垢版 |
04/03/31 22:00ID:f7K9ZfXB
>>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)ってターミナルエミュレータではどー
扱うことになってんの、とか、他にも気付いてない謎仕様があるんだろーなぁ、
とか……。
0104login:Penguin
垢版 |
04/04/01 06:08ID:4WIXUreh
Bidiはmltermをデファクトスタンダードとして広めてしまえ。
他に対応している端末エミュレータなんて無いだろ？
0105login:Penguin
垢版 |
04/04/02 13:55ID:Q4WUuZrw
>>91
よく見たらちゃんと 3 バイトにも対応してた。
けど日本語のファイル名補完できない(´･ω･｀)
0106login:Penguin
垢版 |
04/04/03 02:15ID:8rtp/FCG
ja_JPなのになんでBidiが関係あるの?
0107login:Penguin
垢版 |
04/04/03 22:05ID:m8RgfiGD
>>106
そのためのUTF-8なんじゃない？

さまざまな言語のテキストから
% grep '毛沢東'
0108login:Penguin
垢版 |
04/04/05 08:38ID:Yy2AZo4/
>>107
それだと Mao Ze-dong や Мао Цзе-Дун を
検索することができないよ。
0109login:Penguin
垢版 |
04/04/05 15:42ID:fVLXvA3l
つーか
繁体字中国語では「毛澤東」
簡体字中国語では「毛？x6CFD;？x4E1C;」だから
Unicodeでもgrep '毛沢東'に意味がないのは明白なんだが。
誰が広めた都市伝説なんだろうか。
0110login:Penguin
垢版 |
04/04/05 15:43ID:fVLXvA3l
う、UNIX板は文字参照が使えないのか
0111login:Penguin
垢版 |
04/04/05 16:57ID:rNILKf1h
そこで Han unification ですよw
0112login:Penguin
垢版 |
04/04/05 17:32ID:fVLXvA3l
だから毛沢東は統合されてへんねん
つーか>>106からどんどん話がそれていくんだが
0114login:Penguin
垢版 |
04/04/08 05:26ID:q3IUWRt2
東大のコンピュータシステムのMacOS Xではja_JP.utf-8 になりました．
現在TAのチームがひたすらラッパやパッチを作っているようです．
そのうち各ソフトウェアの本家に還元されるかもしれません．
0115login:Penguin
垢版 |
04/04/08 07:32ID:XquLn+B2
Mac OS X ということは NFD ですか
0116login:Penguin
垢版 |
04/04/09 07:36ID:7V6eqqUK
ワイド版ncursesを使ったり、libtextwrapを使ったり、fribidiを使ったり
ということでしょうか
0117login:Penguin
垢版 |
04/04/11 14:48ID:9+C9vXmC
ja_JP.UTF-8 環境で、bash で PS1=長い日本語プロンプト
なんてことをすると、行の折り返し位置の計算が間違ってる
みたいですね。バイト数とカラム数を同一視してるみたい。
0118login:Penguin
垢版 |
04/04/11 21:25ID:gbdBsXOA
Apacheつかって表示するファイル一覧もなー(サイズの位置とかがずれる)
0120login:Penguin
垢版 |
04/04/19 16:27ID:wtI4wXfK
>>114TAじゃないよん。ちなみに学部生ばっかりなので期待しない方がいいかもしれない。
0121login:Penguin
垢版 |
04/04/21 10:49ID:87XNAVif
screen も utf-8 対応してる。
eucjp やその他の euc、sjis、big5、iso8859-x 等々にも対応している。
実際の表示端末に使う encoding と各スクリーンに使う encoding を
それぞれ独立して設定できるので cocot や luit、ttyconv と同様のことができる。
例えば、utf-8 対応の xterm 配下でスクリーン 1 を eucjp、スクリーン 2 を sjis、
スクリーン 3 を utf-8 で動かすといったことが可能。
実行中、他に影響を与えることなく変更することも可能。
0122login:Penguin
垢版 |
04/06/05 14:46ID:FZ7KtiyQ
で、最近はまともに生活できるようになってるんですか。
0123login:Penguin
垢版 |
04/06/06 00:26ID:InK4icog
EUCからUTF-8にすると遅くなったりしないの？
少なくとも2バイトから3バイトになった分のメモリは使ってるんでしょ。
これは微々たる物だと思うけど、webでは流行らないんじゃないかな。
たとえば掲示板系の大手サイトがsjisからUTF-8に移行したりすると
転送量増えそうだし（でも、圧縮とかすれば問題ないのかな
画像一枚の方が負荷的には大きいけど、文字だけでも結構あると思うよ。
0124login:Penguin
垢版 |
04/06/06 02:54ID:O+pxj2S+
最近はライブラリとかツールキットで内部はUCS4とかUTF8とかが
あるから、そういう場合は逆に変換の手間がなくなるかと。

Webページについては、掲示板のたぐいはたしかにメリットがないかも。
翻訳とか、複数言語を同時に表示する必要があるところでは
使われるだろうな。
0125login:Penguin
垢版 |
04/06/06 03:35ID:KxbaNUGk
>翻訳とか、複数言語を同時に表示する必要があるところでは

おお、まさにうちだ。
とある洋ゲーの英文テキストを多人数でよってたかって翻訳するwikiみたいなCGIなんだが
原文にウムラウトやアクサンの入った固有名詞が頻出してるので
DBの内部コードから表示系まで全部 UTF-8 で作った。
0126login:Penguin
垢版 |
04/06/06 08:19ID:S/boGRmd
いわゆる先進国の言語だけ扱うんだったら、それはそれは
便利なコードだからね。
0127login:Penguin
垢版 |
04/06/06 11:20ID:deT4Xqu2
>>122
UTF-8はEUC-JP, ISO2022-JP, WindowsSJIS(Windows-31J)のすべての
特殊文字を含んでるので、どの環境でもすべての文字が正しく読めるメリット
はあると思いますよ。さらに付け加えると、WindowsSJISは本来のShisftJIS
の仕様にはない文字があるし、それから「〜」がShiftJISの仕様書と異なる
コードになってます。この辺の問題はUnicodeとかUTF-8にする事でだいたい
解決できます。
0128login:Penguin
垢版 |
04/06/06 13:24ID:EGqCVEuE
メールもUTF-8で出していいですか？
0130login:Penguin
垢版 |
04/06/06 13:58ID:F4MfuIYb
>>129 つまり携帯以外ですか？
0131login:Penguin
垢版 |
04/06/06 15:05ID:Gm0vxGXW
メールのために UTF-7 があるが、まず使われないだろうな…
0132login:Penguin
垢版 |
04/06/06 16:45ID:8Zpd8Gr7
お前ら勘違いしてませんか？
ここは ja_JP.UTF-8 のスレであって，Unicode のスレではない．
0133login:Penguin
垢版 |
04/06/13 23:45ID:hijPyot4
Unicodeのスレはどこにありますか?
なかったとして何板に立てるのが適切ですか?
0135login:Penguin
垢版 |
04/06/14 13:11ID:Kpo/7hO+
xmmsでwinampとtagを共有するには使えない
0136login:Penguin
垢版 |
04/06/15 00:19ID:1nIdf8BO
>>134
EUC撲滅のスレッドに見えますが…
スレ違いという理由で誘導されてるのに話題が出ているというだけの理由で
スレ違いのスレッドに案内されても困ります。
それともうにこーだーはすべからくEUCの撲滅を望まなければなりませんか
0137login:Penguin
垢版 |
04/06/15 07:49ID:+9gsKEDe
>>136
スレタイはアレだけど
中身は文字コード総合スレだよ。
0138login:Penguin
垢版 |
04/06/17 10:41ID:TUtqbBWf
xpdf って、UTF-8 に対応してますか？日本語表示できる PDF ファイルと、できない PDF ファイルがあって、どうやら、MS Office で作成した PDF ファイルがダメっぽいので、UTF-8 のせいかな、なんて思ってます。
0139login:Penguin
垢版 |
04/06/17 14:51ID:Wuxldr94
>>137
文字コードスレ2つも要らんだろ。
削除依頼よろぴく。
0140login:Penguin
垢版 |
04/06/19 01:35ID:hBPlVOmh
だからここは文字コードスレじゃないと主張してるんだろ。
それとも>>134以外に文字コードスレがあるの?
0141へりくつ星人
垢版 |
04/06/27 16:21ID:o/ZzpKCM
１を見れば分かるように、ここはﾛｹｰﾙのスレで
あって、文字コードのスレではありません。「たまたま」
utfの話題が多いだけなのです。
0142login:Penguin
垢版 |
04/06/28 00:15ID:Tve7N2OE
最近はみんな満足してるのかな？
俺は tcsh に utf-8 パッチをあてたものを使ってるんだが、
ロシア語とか■とか、そういう端末上での文字幅があいまいな文字が
のきなみ半角扱いになってしまって、
ずれるんだよな。
emacs + mule-ucs でも同様なのでずれるんだよな。
どうしたもんかしら(´・ω・｀)
0143login:Penguin
垢版 |
04/06/28 06:24ID:fWk93VUD
>>123
UNICODEの文字セットを日本語2バイトで扱う符号UTFCP2がある:
ttp://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
特徴は2バイトのコードポイント数が非常に大きいこと、状態非依存であること、
正確にテキストを逆戻り可能なこと。
0151login:Penguin
垢版 |
04/12/04 21:05:30ID:6+KTXyp/
>>142
ずれないようにするにはターミナルエミュレータ(xtemとか)とエディタ (emacs
とか)の両方で全角半角判定が共通である必要がある。で、上の方で
1. 判定には何を使うべきか? wcwidth()/wcswidth()? その他?
2. 判定結果はどうあるべきか
... という話があったわけだが、結論は (ry
せめて 1. がこの世のすべての CUI なプログラムで統一されればずれなくなるん
だけどねー。

最近自分もこの問題に巻き込まれてしまった... orz
0152login:Penguin
垢版 |
04/12/04 21:24:29ID:Ac1hFSyz
>>151
最近は端末エミュレータに ck を使っているのですが、
ck （や xterm) は半角/全角があいまいな文字を
半角で表示するか全角で表示するか選択可能なので、
すこしマシになりました。
0153login:Penguin
垢版 |
04/12/04 21:25:47ID:5ZS2CgHD
>>151
統一できないから問題があるというか、統一できないような文字を
同一の文字として統合してしまった仕様に問題があるというか。
0154login:Penguin
垢版 |
04/12/04 21:33:56ID:ziFkWoAh
サロゲートペア考えたやつは死刑
0155login:Penguin
垢版 |
04/12/04 21:39:06ID:uTy9W2B7
>>154 うむ。あんな変なことするくらいなら、
素直に UCS4 で良かったのにな。
0156中の人
垢版 |
04/12/04 22:01:59ID:b+GZcVVR
だって16bitで十分だと思ったんだもん…
0157login:Penguin
垢版 |
04/12/04 22:16:44ID:6+KTXyp/
>>152
へーそうなんですか。曖昧な文字をすべて全角か半角か一方にすればとりあえず
困らないって感じですか?
実装をチェックしてみねば... どのみち、既存の wcswidth() を使ったら OK、という
ような単純なものではなさそうで。

全角半角問題に関しては、逆に CUI 系のプログラムから全角/半角という概念を
捨てきれればいいのかも。常に1文字1カラムで、ターミナルとかで既存の
挙動をしてほしかったらフォントのメトリックで対処すればいいとか。
(可変幅のカラムといいますか... アルファベットが等幅&日本語の文字幅がアル
ファベットの2倍にデザインされたフォントを使う)
って、これって問題をフォントのデザインに押し付けただけ?

あーでも、文字の表示を簡単に揃えたいときには結局固定幅のカラムじゃないと困る
ような気もしてきました。たとえば ls コマンドの表示ルーチンでフォントの
メトリックを計算させる必要があるとしたら (w

やっぱ Unicode がイカン、ということで。
0158login:Penguin
垢版 |
04/12/04 22:34:42ID:b+GZcVVR
>>157
> あーでも、文字の表示を簡単に揃えたいときには結局固定幅のカラムじゃないと困る
> ような気もしてきました。たとえば ls コマンドの表示ルーチンでフォントの
> メトリックを計算させる必要があるとしたら (w

mozillaのxmltermどうよ?
0159login:Penguin
垢版 |
04/12/04 22:40:54ID:6+KTXyp/
>>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 をベースに考えるからで、では既存のエンコーディング
をベースに考えると、こういうことになるのではないかと思いますが。。。
どのみち旧来の全角半角というのがあまり明快な考え方ではないので、決め方自体はすっきりしませんが、上のようにすれば、文字幅は地域コードのみに依存してエンコーディングに
は依存しないかなと。
0160login:Penguin
垢版 |
04/12/04 22:47:51ID:RHj7f47U
EUC-JPの半角カナは２バイトだよ・・・??
0161login:Penguin
垢版 |
04/12/04 22:48:37ID:6+KTXyp/
>>158
>mozillaのxmltermどうよ?
う、使ったことないけど、もしかして表示の整列とかを賢くやってくれちゃうのかな?
いろいろ疑問がわくけど (ry とりあえず後で使ってみます。

眠くなったきたので休憩...
0162login:Penguin
垢版 |
04/12/04 22:54:15ID:5ZS2CgHD
>>159
同一ホスト、同一ロケールならそれでなんとかなるが、
端末ソフトの場合はロケールやホストが異なるものが
混じるかもしれないからそんな単純にはいかない。

>>160
3バイトじゃなかったっけ？
0163login:Penguin
垢版 |
04/12/04 22:57:36ID:b+GZcVVR
>>162
> 3バイトじゃなかったっけ？

そりゃ補助漢字でしょ。半角かなはSI/SO + 文字で2byte。
0164login:Penguin
垢版 |
04/12/05 07:11:53ID:3PBNWURc
Unicode 絡みの話題と言えば、最近 Mac OS X のバージョンが変わると特定の文字のコードが変わるとか言う話があったね。
http://slashdot.jp/article.pl?sid=04/11/30/1014219&topic=11&mode=nested
まぁドラフト段階の字形-コードの対応表を使っちゃった Apple が悪いんだけどさ。

ところで、「字形-コードの対応表」って専門用語ではなんて言うの？
0167login:Penguin
垢版 |
04/12/05 22:36:47ID:U+jxCrh2
>Coded Character Set(CCS)
説明不足だった。これは文字毎に一意の番号を振ってある文字集合。
JIS X 0208とか、UCS-2とかがそれ。

CCSをどういうバイト列で表すかがCharacter Encoding Scheme(CES)。
EUC-JPとかUTF-8とかがそれ。

ただ、字形じゃなくて文字概念に番号がついてるから、どっちも
厳密には>>164の言ってるものじゃないのかも。

AdobeのCIDは字形に番号が振ってあるな。
0168login:Penguin
垢版 |
04/12/15 17:38:23ID:CmtNvJ+T
xmlterm、まだ使ってないけどスクリーンショットでそのコンセプトはわかった
気がする。ターミナルを一種のブラウザと考えるとああなるのかな。
今までのターミナルはプレーンテキスト専用のブラウザとも言える訳だ。

こうなったら、ウェブブラウザもファイルブラウザもターミナルも
全部統合した UI を目指す事にします。ってどこかで見た気が...
0169login:Penguin
垢版 |
04/12/15 20:35:16ID:AiVgzkM7
餅は餅屋ということわざを教えてあげたい
0170login:Penguin
垢版 |
04/12/15 23:06:31ID:pwu6u1JE
和菓子屋の餅も旨いよ。
0171login:Penguin
垢版 |
04/12/15 23:18:48ID:v6Owr1lz
佐藤の切り餅って超まずいね。というか餅じゃない。
あんな餅を餅だと思って食べている人がいるかと思うと
かわいそうだ。
0173login:Penguin
垢版 |
05/01/18 15:41:07ID:Wb3X1dyN
>>171

十分うまいよ。
0174login:Penguin
垢版 |
05/02/26 04:56:11ID:OxqQlLig
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に変換する方法をご存知の方はいらっしゃいますか？
0175login:Penguin
垢版 |
05/03/07 02:10:29ID:233WSAJL
なんで UTF-8 の変換にエンディアンが関係するんdayo!
って一瞬思ったけど、iconv の内部的には一旦 UTF-16 とかにしてるのかな?
Apple のハックのせいなんなら普通の libiconv と比較してみたらいいんじゃねーの?
それか普通の libiconv にその UTF-8-MAC を追加する方向で修正してみるとか
...ってのができないわけね。
Mac OS X が使えるなら Mac OS X 上で変換してから他のプラットフォームに持って
いくんじゃ駄目なのか?
0176login:Penguin
垢版 |
05/03/07 12:53:14ID:v/gznSFy
>>174
> configureもmakeも問題なくできるのだけれども、
> iconv -f UTF-8-MAC -t UTF-8 等としてもどうもうまく動かないんです。

How?
0177login:Penguin
垢版 |
05/03/08 12:02:39ID:FpUM9LjU
ja_JP.UTF-8 ロケールでeuc-jpのnfs鯖をマウントするときみんなどうやってるの？
（sambaや、webdav使えばできるんだけどネ、nfsでの解決策を教えてね）
0178175
垢版 |
05/03/08 12:30:30ID:p+KoiNpg
問題が本当にエンディアンのせいなら、utf8mac_mbtowc() が呼んでいる
utf8_decodestr() の引数に UTF_REVERSE_ENDIAN をセットしてみたらいいかも。
ハードコーディングになっちゃうけど。
それで駄目だったら >>176 の回答待ちか。
0179174
垢版 |
05/03/10 00:01:21ID:AGM4jA9o
>>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が全くわからないので意味はわからないのですが…
0181naruse
垢版 |
2005/07/07(木) 20:26:04ID:Ajp7X6MQ
nkfの最新のCVS版で、
nkf -w --utf8mac-input hoge.txt
などとすればUTF-8-MACをUTF-8に変換できる・・・はずです。
うまくいかない場合は教えてください。
0182login:Penguin
垢版 |
2005/07/13(水) 03:15:25ID:GiU0rXXK
　　
0183login:Penguin
垢版 |
2006/01/10(火) 14:40:21ID:s0uQ10WF
あけおめage
0184login:Penguin
垢版 |
2006/01/18(水) 17:33:51ID:1b8YR8q0
フェどらって、OSの仕様をかえればすぐにソフトの仕様もかわると思ったのかな？
0185login:Penguin
垢版 |
2006/01/21(土) 16:33:52ID:e7e/lB8H
「すぐに」とは思ってないんじゃない。
0186login:Penguin
垢版 |
2006/02/01(水) 08:31:41ID:H6kL8c39
使っている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スレ立て公開中
0187login:Penguin
垢版 |
2006/02/01(水) 10:57:17ID:5OoK6VSB
age
OS が UTF-8 ってのは
UTF-8 対応のロケールが入っているかどうか？という意味なんでしょうかね。
0188login:Penguin
垢版 |
2006/02/01(水) 11:00:41ID:fQfoX2Vz
>>187
だね。kernelはutf-8対応なんかしちゃいないよ。
0189login:Penguin
垢版 |
2006/02/01(水) 13:51:37ID:IyxnkmjE
>>188
ん？VFATとかsmbfsなどのNLSにUTF-8が入ってるけど？
他のUTF-8/16なOSとファイルレベルで互換とらないといけないFilesystemはカーネルレベルでNLSサポートしてますよん。
0190login:Penguin
垢版 |
2006/02/01(水) 15:11:08ID:fQfoX2Vz
それドライバの話でしょ。カーネルからはNUL端の文字列にすぎないよ。
0191login:Penguin
垢版 |
2006/02/01(水) 16:05:56ID:qAxvh4Kn
ドライバがカーネルかどうかなんでどうでもいいから
0192login:Penguin
垢版 |
2006/02/01(水) 18:36:18ID:/PUwsy/N
カーネルをソースからコンパイルするときに
ファイルシステムのエンコーディングを
UTF-8だのSJISだのEUCだの指定できるのはなんなんだろうね。
0193login:Penguin
垢版 |
2006/02/01(水) 21:30:09ID:/ik9G5r3
>>192
ファイルシステムドライバへの指定だから、どのみち>>191だとおもわれ
0194login:Penguin
垢版 |
2006/02/01(水) 22:51:36ID:axKot8bp
EUCで書かれたシェルスクリプトをUTF-8でごちゃごちゃいじって、
おなじファイルなのに容量が増えることに愕然としたりして、
それでもいじってとりあえず動くものができたんですが、

日本語の文字化け以外にはやう゛ぁイことって何も無いですよね?
0196186
垢版 |
2006/02/02(木) 21:37:38ID:I2B8ecnQ
とりあえず、LOCALEの設定箇所を調べて
そこを確認すればわかるってことでいいようですね。

それはそうと、アクセス規制の一日の間に
convmvでUTF-8ファイル名にしたら当座の目的は解決。

ともかく、ありがとうございました。
0197login:Penguin
垢版 |
2006/03/09(木) 13:51:20ID:Bujq6YPa
はじめてRedHatES4いれてみた。

# /etc/init.d/xinetd reload
繹・秧莨若榛 [ OK ]

ってな出力がUTF-8ででてるっぽいんだけど
これってEUC-JPに変更できないのかなあ。
ES3まではEUC-JPだったのに。
0199login:Penguin
垢版 |
2006/03/09(木) 15:10:08ID:LBUAWqfA
玄箱を Debian 化して、locale を utf8 にして、日本語manを入れたら、
euc-jp で書いてあって文字化け。orz
0200login:Penguin
垢版 |
2006/03/09(木) 18:00:07ID:kAtX1v8U
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
0201login:Penguin
垢版 |
2006/03/12(日) 01:04:13ID:fe5y18+Z
>>192
ファイルシステムにエンコーディングは関係ない
ファイル名を決めるのはカーネルじゃないってわからない?
0202login:Penguin
垢版 |
2006/03/12(日) 01:34:49ID:zOXA93u/
ファイルシステムにエンコーディングは関係あるし。
0203login:Penguin
垢版 |
2006/03/12(日) 02:24:44ID:/fczP50N
>>202
どういう意味だろう?
とあるロケールで使用する文字コードが
ファイル名として使える文字コードの範囲内に入ってれば
何の問題も無いと思うんだが

例えばUTF-8のディストリでも、シコシコ設定書き直せば
システム全体の文字コードをEUCにもSJISにもできるわけで
0204login:Penguin
垢版 |
2006/03/12(日) 02:51:32ID:Qy+1QTbg
>>203
CONFIG_NLS_*
mount iocharset=*
を調べるか、黙って。
0205login:Penguin
垢版 |
2006/03/12(日) 03:56:15ID:K2J5B9uh
>>204
NLSやcharsetはエンコードと関係あるが
カーネルがエンコードしている事の証明にはならないわけで＾＾；
「黙って」ほしいなら
「お願いですからこれ以上つっこまないでください」と懇願した上で
お前が黙れｗ
0207login:Penguin
垢版 |
2006/03/12(日) 04:38:25ID:zOXA93u/
>>205
んじゃ NLS や charset は何がつかってるの？
ファイルシステムはドライバでカーネルじゃないとか言うつもりかｗ
0208login:Penguin
垢版 |
2006/03/12(日) 12:48:03ID:/fczP50N
>>204
エンコードはしないが関係無くは無いって事か?
トンチが効いているが言い訳っぽいな…
0209login:Penguin
垢版 |
2006/03/12(日) 15:19:01ID:Oc3RTicA
たとえば'/'をディレクトリの区切りと見なしてるのは、ファイルシステム
だけじゃないと思うんだな。(思うだけでソース見て回ったわけじゃないが。)
とすると、8ビットクリーンな環境ならばファイル名がutf-8やeuc-jpは問題
ないが、iso-2022(-jp)やShift_JISを使うのには困る。
0211login:Penguin
垢版 |
2006/03/12(日) 20:27:33ID:ydqBlaR7
>>208
ん? iso-2022-jpを使ってファイルを取扱うシステムなんてあんの
0212login:Penguin
垢版 |
2006/03/13(月) 00:57:05ID:8cnv7aJ6
あらら極論を持ち出して・・・
0213login:Penguin
垢版 |
2006/03/14(火) 15:01:37ID:ZJm9Ix4t
File system 自身が '/' という「文字」を抱え込んでるってのか？
0215login:Penguin
垢版 |
2006/03/14(火) 23:40:20ID:SOaD9AK3
まあ、/とか考えるまでもなく、ファイルシステムに文字エンコードは影響するし。
0220login:Penguin
垢版 |
2006/03/18(土) 17:46:45ID:KLdgQbg+
NT系列では'\'が本則みたいだねえ。システムコールはもちろんどちらでも
受け付けるけど。
>>219
この一連の議論参照
0221login:Penguin
垢版 |
2006/03/18(土) 19:56:18ID:TivuVR12
システムコールがどちらも受け付けるからといって、
内部の扱いかどうかなんてわからんだろ。
ソースかバイナリを追った結果でもどこかにでてるんなら別だけど。
0223login:Penguin
垢版 |
2006/03/18(土) 20:10:35ID:rRI0eBQC
>>222
もしかして、脳晦の容量不足している？
0224login:Penguin
垢版 |
2006/03/19(日) 00:37:05ID:wDljjOw3
JFSのunicodeってなに?
UCS4?
0225login:Penguin
垢版 |
2006/03/19(日) 03:30:27ID:cmjBOE+n
無意味に煽ってる奴のほうがよっぽど顔悪く見える
0226login:Penguin
垢版 |
2006/03/19(日) 13:45:56ID:zdRlaDhI
>>225
そうやって無意味に煽るのはやめなさい。
0228login:Penguin
垢版 |
2006/03/21(火) 01:13:28ID:M+2sG4Eb
>>222
DOSは switcher を変えると / *も* 使えるようになるだけだ
0229login:Penguin
垢版 |
2006/03/23(木) 17:04:49ID:YW27Dazl
日本語はさ、1カラム文字と2カラム文字しかないけど
他の言語には３カラム文字とか４カラム文字とかあるの？
端末上で半角３文字分とか４文字分の文字。
0230login:Penguin
垢版 |
2006/03/23(木) 19:27:17ID:tr7Z4cN+
>>229
画面に出る時の幅のことを言っているの? プロポーショナルフォントは
W と i で幅が何倍も違うな。
0231login:Penguin
垢版 |
2006/03/23(木) 19:28:31ID:tr7Z4cN+
はっ。しまった。あからさまな釣りか。
0232login:Penguin
垢版 |
2006/03/23(木) 20:01:27ID:YW27Dazl
>>230
固定幅のフォントでの話です。
普通の日本語対応の端末エミュレータの場合そうでしょう？
端的に言って日本語以外だとwcswidthで3や4が返る可能性があるのかないのかなんですけど。
0233login:Penguin
垢版 |
2006/03/23(木) 22:40:43ID:KIoq1Iks
unicode とそうでないので混じってるみたいだけど、
emacs の HELLO ファイルみると
(debian だと /usr/share/emacs/22.0.50/etc/HELLO)
Hindi とか Malayalam とか Kannada とかの
フォントセットのところに3とか4の文字がある。
0234login:Penguin
垢版 |
2006/03/23(木) 22:57:17ID:YW27Dazl
>>233
ああ、やっぱあるのか。カラム数４ってどんな文字だorz
ありがとー。ちょっと対応を考えないといけないな。
0235login:Penguin
垢版 |
2006/03/24(金) 01:34:23ID:JGNnmuyn
unicodeって、リガチャがあるから面倒くさい。死ね。
0236login:Penguin
垢版 |
2006/03/24(金) 17:08:59ID:u8A96IKS
>>234
アラビア文字みたいに横に伸びる文字なんじゃないかな。
日本語も実際には伸びる時がある(「おーーーーい」という
時の「ーーー」の部分とか)が、それを普通の文語体の文章
ではあまり使わないから困らないだけだ。
0237login:Penguin
垢版 |
2006/03/25(土) 00:18:32ID:J9uW1TTI
>>236
なるほど。日本語も縦書きだと３カラム分消費する奴がありますよね。
おーーーいの「−−−」をしの長いようなので書く奴。

>>235
確かにUnicodeって色々面倒だとは思うけど
Unicodeに対応するだけで各国語に対応できるのは確かに便利だと思う。
0238login:Penguin
垢版 |
2006/03/25(土) 00:21:28ID:FjiAaDQS
各国語には対応できるけど多国語が微妙なんだよね。
0239login:Penguin
垢版 |
2006/03/25(土) 03:07:23ID:IICSJlaQ
多国語でなくて多言語って言ってほしいかな。
0241login:Penguin
垢版 |
2006/04/29(土) 11:21:21ID:3FCe/A1k
>>237
くの字点のことかな。繰り返しに使う。
普通は2文字分の長さではないかと。
0242login:Penguin
垢版 |
2006/04/29(土) 21:33:35ID:N4s8B/kn
でさ、ファイルシステムにエンコーディングは関係あるの？
0243login:Penguin
垢版 |
2006/05/07(日) 13:49:44ID:9szlYmVt
実運用上は、そんなエンコーディングの都合よりもftpdの文字化けで困るんだよね。
こればっかりはクライアント側の問題だからサーバ側ではどうにもならないし。

将来的にutf-8に統一されるなら今更eucJP使いたくないけど、
上記の理由で1台はeucJP確実なので、他も統一しないと使い勝手が悪い。
→全てeucjpで稼動。
0244login:Penguin
垢版 |
2006/05/08(月) 12:07:10ID:EWKIbwjX
>>243
ftpdが漢字を返すの? あ、もしや漢字ファイル名のこと?
0245login:Penguin
垢版 |
2006/05/08(月) 15:11:47ID:0ATCNism
>>243
ああ、あれで困ってEUC-JPに戻さざるを得なかった。(FTPサーバー立ててるから)
だって、UPされたファイルかたっぱしから文字化けして(LINUX上で)
何がなんだか分からんし。

そりゃ「日本語ファイルUPすんな！」って言えばいいんだけど、実際UPする人いるしな。
UP元のWindows機のファイルを全部英数字にリネームしろ！ っていうのも横暴だし。
0246login:Penguin
垢版 |
2006/05/10(水) 12:05:03ID:PqdFQ5lv
eucjpなディレクトリツリーをsambaでローカルにのみ共有して
smbmountでiocharset=utf8でマウントして特定場所のみeucjpで
メインはutf8を共存みたいな
0247login:Penguin
垢版 |
2006/05/10(水) 13:05:10ID:loEZm4Y3
そういや自宅では玄箱を utf8 にしてるな。
たまに Windows マシンから samba でアクセスするが、それは
ちゃんと設定してあってファイル名は玄箱側に utf8 で書かれる
ようになっている。通常は utf8 になっている Linux マシン
から nfs (autofs) で一部をマウントして使っている。

ftp ねえ。でも ftp を使ったとしても ftp クライアントが
utf8 のファイル名に対応してさえいればいいんだよね。
そういうのってまだないのかな?
0248login:Penguin
垢版 |
2006/05/10(水) 14:54:55ID:gPG0recc
8bitスルーなら問題ないでしょ。
readline使ったヤツとか。
0249login:Penguin
垢版 |
2006/05/11(木) 04:59:01ID:iZnowODo
利用者側にftpクライアントを指定する時点で不合格じゃない？
0250login:Penguin
垢版 |
2006/05/11(木) 14:17:34ID:tz1hDbmm
>>249
んなこたねえと思うが。
0251login:Penguin
垢版 |
2006/05/11(木) 21:20:12ID:MPosGOlv
素朴な疑問なんだけど、ある文字が何カラムになるかがロケールで決定できる
と考えるのがそもそもの間違いであって、TerminfoとかTermcapみたいな物に
そこら辺を全部面倒みて貰う方がすっきりするんじゃないの？
ここで言ってる文字幅って結局端末に依存する情報でしょ？

できるかどうかは知らんけど
0252login:Penguin
垢版 |
2006/05/11(木) 21:38:34ID:tz1hDbmm
文字幅? 一応 Unicode には Halfwidth と名前の付いた文字はあるけどな。
まあ、端末やプリンタで等幅の時に半分で出ることが期待された文字という
ことなんだろうが、こんな半角文字は早く消えて欲しいものだ。
0253login:Penguin
垢版 |
2006/05/11(木) 22:08:50ID:MPosGOlv
別にいわゆる半角文字に限らなくてもいいんでない？
端末によっては表示できない文字だってあるだろうし、それをどう扱うかは
端末が勝手に決めればいいんじゃないの？
結果として端末によっては、?で表示されたり、〓で表示されたり、\uXXXXで
エスケープして表示されたりするかもしれないけど、それって端末の勝手だよね？
最終的に端末で表示した時にズレなきゃそれでいいんだし、ロケールで面倒
みる必要はないと思うんだけどな。
まあ、代替文字として何が表示されてるか分からないと困る場合はあるかも
しれないから、そういう時は代替文字を端末データベースに問い合わせて
教えて貰えればそれで済むんじゃない？
なんかおかしな事言ってる？
0255login:Penguin
垢版 |
2006/05/11(木) 23:03:46ID:bYbMBCWq
合字があるから、面倒くさいんだよ。
0256login:Penguin
垢版 |
2006/05/13(土) 03:27:14ID:0C6WASA7
>>216-222
内部を覗いて見ないと分からないけど、
Win32 API では、"\" が本則っぽいな。

ファイル名の先頭に \\?\ を付けると解釈が厳格になる。
その時、"/" を受けつけなくなる。


NTFS と VFAT はファイル名は UTF-16 で格納すると決まっていて、
API やカーネル内部も UTF-16 で統一されてるから、
その点では頭を抱えずに済んでる。

Debian の次期バージョンは UTF-8 らしいけど、どんな感じになるだろう。

UNICODE も弱点は多いけど他の良い手段が思い当たらないので、
UNICODE 自身の改良に期待するしかないと思っている。
0258login:Penguin
垢版 |
2006/05/17(水) 22:28:14ID:FZX45EoA
バックスラッシュと\が同じ文字コードだったとか
聞いた気がしたんだが…

勘違い？
0260login:Penguin
垢版 |
2006/05/19(金) 01:06:49ID:ifty74/J
>>258
バックスラシュと\は同じコードだけど、
スラッシュと\は違うコードで、
今回の話しはスラッシュと\の話しね。
0261login:Penguin
垢版 |
2006/05/19(金) 08:05:17ID:GW8la2YX
>>260
> バックスラシュと\は同じコードだけど、

ムチャ言うなよ。
0263login:Penguin
垢版 |
2006/05/22(月) 11:05:24ID:IgouP2VU
俺、今、Linux からおちゅ〜しゃでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w
0264login:Penguin
垢版 |
2006/05/22(月) 13:43:15ID:GrV5T77x
俺、今、英語版Windows からIEでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w
0265login:Penguin
垢版 |
2006/05/22(月) 23:15:37ID:PaXuCUI2
俺、今、(かん高い声で！)、navi2ch！
0266login:Penguin
垢版 |
2006/05/23(火) 00:38:55ID:MNyc16BX
>>262
僕もそこを見た上でレスした。
UNICODEでは本来は 半角の＼ と 半角の￥ が区別されるのは知っているよ。
しかし、

> Unicodeを利用するアプリケーションは
> 0x007F以下のコードに関しては移動させないと言う
> 暗黙のルールができている。

この事実があるから区別されてないと書いたわけです。
（Windows も Linux も区別していない。）

>>261
ムチャなことが現実になっているから
小さいながら問題になってしまっているのが悩ましい。

WAVE DASH - FULLWIDTH TILDE問題
は、海外のCDDBを利用する僕も影響を受けている。
0267login:Penguin
垢版 |
2006/05/23(火) 02:56:03ID:+D3NsWKB
>>266
区別していない？バックスラッシュとバックスラッシュは同じ文字なのに、どう区別するんだよ？
0268login:Penguin
垢版 |
2006/05/23(火) 07:50:38ID:YpTnBhhN
何がどういう風に問題なのかわからん。
0269login:Penguin
垢版 |
2006/05/23(火) 08:14:43ID:sMe4PIZ0
SJISはともかく、EUC-JPも使い分けられないんだっけ?
ISO-2022-JPは問題ないよね。
0270login:Penguin
垢版 |
2006/05/23(火) 09:31:32ID:YpTnBhhN
iso-2022-jp の半角部分は jis x 0201 だから、
\ は円マークだよ。
euc-jp は半角カナ以外の半角部分は ascii らしいので
\ はバックスラッシュだと思う。
0271login:Penguin
垢版 |
2006/05/23(火) 10:13:01ID:s/6PQypJ
>>270
前半は嘘というかミスリーディングというか……、
ISO-2022-JPがASCIIを書けないとでも思ってんのかいな。
生半可な聞きかじりを垂れ流す前に考えるなり調べるなりしような。

Emacsで新しいファイルを作って、次の一行を入れて保存し開き直してみ。
\^[(J\^[(B
(^[はESCなのでEmacsだとC-q ESCで入力)
一つめはバックスラッシュに、二つめは円記号になるから。
0274login:Penguin
垢版 |
2006/05/23(火) 22:41:11ID:+D3NsWKB
>>272
「ISO646の国際基準版図形文字」って ASCII のことだろ？
0277login:Penguin
垢版 |
2006/06/04(日) 15:42:45ID:jkHVDhT6
UTF-8な環境を結構長く使っているけど、いまだに
解決できないのがEmacsでギリシャ文字を使おうとすると
なぜか「全角」の文字上のカーソル移動が「半角」単位に
なって、編集ができなくなってしまうこと。

このあたりのノウハウ集みたいなのって、ないですかね・・・

0278login:Penguin
垢版 |
2006/06/05(月) 09:29:08ID:bL9pWPFE
>>277
それ emacs だけでなることではないのでは?
wcswidth()が返す値が既におかしいとか端末の問題なのでは?
0280login:Penguin
垢版 |
2006/06/06(火) 01:46:26ID:kAFvi9EP
あ、たしかにコマンドラインでもなるね。
いままで文書書く時とか emacs -nw な中でしかそういった文字
使おうとしたことがなかったから気づいてなかった。

Debian GNU/Linux (sid) な環境で Putty(UTF-8-CJK) 経由で
使ってるんだけど、これはしょうがないのかな？
0281login:Penguin
垢版 |
2006/06/06(火) 07:42:13ID:jrnahNgL
端末エミュレータの問題なので、そっちを直してください。
putty使い続けたいなら、puttyスレかな。
0282login:Penguin
垢版 |
2006/06/06(火) 22:46:29ID:kAFvi9EP
そだね、炒ってきます
0283login:Penguin
垢版 |
2006/07/10(月) 20:50:34ID:nmNyvjRy
ttp://diary.imou.to/~AoiMoe/2006.07/early.html#2006.07.10_s01

すばらしい!

0284login:Penguin
垢版 |
2006/08/05(土) 16:04:26ID:QVT4c80E
Unicode の〜　Unicodeの〜　旗の〜もと〜♪
0285login:Penguin
垢版 |
2006/09/06(水) 01:51:11ID:IrLQmI4G
ageてみる。
ttp://nijino.homelinux.net/diary/200605.shtml
経由で、
ttp://www.mhsin.org/~mhsin/patches/screen/patch-cjkwidth
を当ててみた。ちょっと幸せ。
でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz
0286login:Penguin
垢版 |
2006/09/06(水) 20:31:28ID:WxxjRdHU
>>285
>でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz
wcswidth() って、glibc のやつ? それって誰（どのプログラム）が使ってるの?

文字幅という概念をこのまま使い続けるなら、各文字の文字幅の値（おそらくロケール依存）
をちゃんと定義して、各プログラム／ライブラリで共通の値を使うになってもらわないと
困る訳だが...
Unicode が提唱している East Asian Width （上の PuTTY のパッチもそれを参照している
模様）で、いいのかねえ?
0287login:Penguin
垢版 |
2006/09/10(日) 17:39:46ID:EBW7Z88N
UTFって英字(0x00-0x7f)は２バイト目以降には使ってないんでしょうか？
0288login:Penguin
垢版 |
2006/09/10(日) 17:43:19ID:QArT0E9g
すべてはMicrosoftの都合のままに...
0289login:Penguin
垢版 |
2006/09/10(日) 17:47:58ID:EBW7Z88N
仕様書に載ってました。
ttp://www.asahi-net.or.jp/~CI5M-NMR/w3/utf-8.html
2バイト以降は、常に最上位 2ビットが 10 になる。

良い仕様ですね。
0291お茶碗
垢版 |
2006/10/04(水) 23:56:15ID:h1r5LKWn
fedora５使ってますemacs でutf８のファイルは見られるんですが
日本語入力できません
mule-ucsというのをいれればいいのでしょうか？
0292login:Penguin
垢版 |
2006/10/05(木) 00:03:30ID:Rwz1aiUe
試してから書けよ、な？
0293お茶碗
垢版 |
2006/10/05(木) 14:32:54ID:wqpoHcXI
試しました
でも 日本語入力モードになってくれません
0294login:Penguin
垢版 |
2006/10/05(木) 16:25:48ID:PqMrisKX
>>291=293
何を使って日本語入力したいの？ そもそもutf8云々ではないのではないの？
0295お茶碗
垢版 |
2006/10/07(土) 11:31:44ID:i+qvpb1B
>>294 さん
localeが　utf-8のまま日本語入力したいだけです
手段は　何でもいいんです
utf8　のファイルを扱うのに　mule-ucs が　必要みたいなことを
目にしたので。。　
0296login:Penguin
垢版 |
2006/10/07(土) 11:42:18ID:lTs1ivId
.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)
もかな。
0297お茶碗
垢版 |
2006/10/07(土) 15:29:32ID:i+qvpb1B
>>296
さん　　utf-8 >> utf-8-unix
と　変えてみました
なんとかいけそうです　ありがとうございました。
0299login:Penguin
垢版 |
2006/11/12(日) 03:26:08ID:RBYyZwrm
みなさん日本語辞書には何を使われていますか？
0301299
垢版 |
2006/11/13(月) 04:53:51ID:DjtpFn1c
すいません。日本語入力ソフトで単語登録するための辞書のことです。
kasumiがeucなので、みなさんは何を使われているのかなと思って。
0302login:Penguin
垢版 |
2007/05/10(木) 14:27:19ID:eb3cjhOQ
>>300
おお！私も新明解国語辞典使ってるヨ。
あれはマニアがいて全版で持ってる人も少なくないという話だそうで。
自分は第三版しか持ってないけど。
0303login:Penguin
垢版 |
2007/06/06(水) 20:26:45ID:c+BVw1Km
「新解さん」だろ。
0304login:Penguin
垢版 |
2007/07/12(木) 12:50:24ID:wmI/CkqL
今やUTF-8は標準じゃん
0306login:Penguin
垢版 |
2007/07/14(土) 06:29:47ID:GI9wOt/U
UTF-8って移行が大変･･･
0307login:Penguin
垢版 |
2007/07/14(土) 12:08:55ID:ZWo0296M
一番辛いのが less +123 hogefile ができなくなってしまう点だな。
まともな（意：限りなくlessな）ページャはないのだろうか？
0308login:Penguin
垢版 |
2007/07/14(土) 12:16:04ID:ZfK7d6BJ
jlessかlvぐらいじゃね？
0309login:Penguin
垢版 |
2007/07/14(土) 18:19:49ID:DdVdDxxU
ファイル名が255バイトまでしか使えないファイルシステムがまだまだあるから
移行が不安だ
0311login:Penguin
垢版 |
2007/08/09(木) 22:07:54ID:E8Z++yUo
>>309
マジレスだが、
255バイトって、大抵そんなもんじゃ? linux で割と普通に使うファイルシステムで
それより大きいのってどんなのがあるの?

ってゆうか、仮にそういうファイルシステムを使ったとしても、POSIX API で
NAME_MAX とかの縛りに引っかかる気が。

ちなみにMac OS XのHFS+はユニコードで255「文字」だったりする。
0312login:Penguin
垢版 |
2007/08/09(木) 22:57:46ID:GmhH65pi
decomposed UTF-16で255。
サロゲートペアとか合成文字は2文字以上で数えないといかん。
やたら面倒。
0313login:Penguin
垢版 |
2007/08/10(金) 00:14:36ID:XwVgHFEc
windows系ってルートからの合計文字数が255とかじゃなかったっけ？
NTFSだとそんな制限ないのかな。
0314login:Penguin
垢版 |
2007/08/10(金) 02:14:01ID:CR2Glwk1
>>312
それがユニコードクオリティー。

たしか normalization form D とかいうやつな。濁点とかもだからなあ。
0315login:Penguin
垢版 |
2007/08/10(金) 23:20:31ID:QITngYGM
いや、アプリケーションレベルで考えると、なかなかうまい仕組みだとは思います。
曖昧検索とかに利用出来そうです。
ただ、それをファイルシステムに使う神経がわからん。
0316login:Penguin
垢版 |
2007/08/11(土) 10:41:10ID:f4144F1K
ファイル名の曖昧検索をシステム（コール）レベルでしたかったということか。

でも曖昧検索って、例えばどんなの?
日本語の場合を無理矢理考えると、例えば「たかださん」と「たかたさん」
（「高田さん」の読み方ね）を区別せずに検索とか? そんなにうれしいかねえ。
0317login:Penguin
垢版 |
2007/08/11(土) 11:18:42ID:KQuQCd+k
「曖昧」関係ないだろ？
DにしてもCにしても、
normalization formにするのは当然だと思う。
が、か+compose様゛と見た目は一緒の別のファイルができたらイヤだから。

ただMac OS Xの場合、
kernel levelで正規化をサポートしているのはhfs+だけ。
0318login:Penguin
垢版 |
2007/08/12(日) 08:28:39ID:yOIQf12/
>>317
>DにしてもCにしても、
DとCならCの方がよくない?

>normalization formにするのは当然だと思う。
確かに。ただ、normlizationを必要とするのはUnicodeを採用してるからともいえるわけで...
あら、ループしてるかな。

>kernel levelで正規化をサポートしているのはhfs+だけ。
ま、逆に言うとファイル名としてUnicodeを使うと明言しているのがそれだけ
だったりして... 確かにufsなんかは単にバイト列を渡しているっぽいね。
0319login:Penguin
垢版 |
2007/08/12(日) 09:32:23ID:v0PapVfX
Dの方が、単純にbyte列としてsortした場合、
sortの事情に合っている国が多いんじゃないかな?
まあノー資料の妄想ですが。
0320login:Penguin
垢版 |
2007/08/20(月) 21:17:26ID:/qwFMA91
しかし、ファイルシステムレベルではnormalizationによってうまく機能するんだろうが、
今度はファイル名の文字列を上の層に持っていったとき、ハマりやすいような気がする。
例えばアプリケーション内でファイル名の比較をするときとか。

結局、扱っている文字列がファイル名の文字列であることを常に意識してないと
いけないような。
0321login:Penguin
垢版 |
2007/08/23(木) 10:48:24ID:SlTBZyzH
>>320
Unicodeのnormalizationなんて持ち出さなくても以前からパス名の同値関係は
あるし、どっちみち意識は必要だろ
連続するスラッシュや..が使われてる時の扱いとか
FATやNTFSのようにcase insensitiveなファイルシステムもあるし
0322login:Penguin
垢版 |
2007/08/23(木) 11:32:32ID:rO/+iFi7
short filenameとの比較ってのもある。
0323login:Penguin
垢版 |
2007/09/19(水) 07:01:34ID:WYOyjk06
>>313
NTFS自体は、各階層で255文字でルートから含めると32767文字まで。
ただ多くのアプリはルートから含めて260前後の文字数しか対応できない。
Explorerも含めて・・・。
0324login:Penguin
垢版 |
2008/04/01(火) 19:08:30ID:vg6rofSk
>>323
>ただ多くのアプリは
なんだ、Windowsの制限って訳ではなかったのか
知らなかった
0325login:Penguin
垢版 |
2008/05/06(火) 03:16:11ID:YokaBOcM
VineをUTF-8化しようと思って、
http://homepage3.nifty.com/tearoller/Vine2e.html#UTF8
な感じで設定したけど、bashが文字化けする。
lv使ってのUTF-8ファイル閲覧とかはできてるけど、bashでUTF-8を表示することって出来ないかな。
Fedoraはどうしてんだろ、bash標準らしいけど。
0326login:Penguin
垢版 |
2008/05/06(火) 14:31:11ID:2QnDaXqe
>>325
仮想端末は何使っているの？
kterm とかなら UTF-8 に対応してないので、xterm なんかに切替えろ。
0327325
垢版 |
2008/05/06(火) 18:04:21ID:7GDee/mn
仮想端末についてはよく知らないけど、GUIを入れてない環境だから仮想端末は使ってないと思う。たぶん直にbashが動いてるはず。
SSH接続時はPuttyで、直接操作するときはフレームバッファ有効なCUIで使ってます。
んで、直接操作するときに化けないで表示したいなあと。
(Vine4.2)
0328login:Penguin
垢版 |
2008/05/06(火) 18:49:41ID:2QnDaXqe
>>327
vine のことは良く知らないが、cui のままなら unicon じゃね？
>>325 のページにもあるが、unicon は utf-8 対応してないんじゃない？

フレームバッファを有効にして jfbterm あたりを使うといいんじゃね？
vine の jfbterm が utf-8 対応しているかは知らないが。
0329325
垢版 |
2008/05/06(火) 20:31:21ID:7GDee/mn
>>328
そうみたいです。VineはUNICONパッチのあたったカーネルで、フレームバッファ有効にするだけでEUCとかを表示出来ると。
ただしUTF-8は対応が難しいらしく未実装。

で、jfbterm使おうと思ったけどVineのaptに無いのでとりあえずbterm使ってみた。が、背景が青になるのが気にくわなくて諦め。
また気が向いたらjfbtermインストールしようかな。
0331login:Penguin
垢版 |
2008/07/17(木) 15:36:28ID:5pKN5CSc
>>320
Mac OS Xを仕事で使ってますが、
フレームワーク、ファイルシステムごとに扱いが違うので結構面倒です。

ブラウザでUSBサムドライブのファイルを開こうとすると、
ファイル名がNFCでひかかったり。

アプリが必ず読み書きする前後両方でにNFDあるいはNFCする必要があります。
0332login:Penguin
垢版 |
2008/07/20(日) 17:09:47ID:VPRlcszf
>>331
>フレームワーク、ファイルシステムごとに扱いが違うので結構面倒です。

確かにファイルシステム毎に違うね。まあ歴史的経緯でどうしようもない気もする。
フレームワーク毎というのはよくわかんないけど。

>ブラウザでUSBサムドライブのファイルを開こうとすると、
>ファイル名がNFCでひかかったり。

ファイルシステム云々ゆってるのにUSBサムドライブって別階層を... FATの話?

>アプリが必ず読み書きする前後両方でにNFDあるいはNFCする必要があります。

アプリ内でファイル名の比較をするときなどのことを言ってるのかな?
0333login:Penguin
垢版 |
2008/07/20(日) 22:23:44ID:RZXdwXj/
>>332
> フレームワーク毎というのはよくわかんないけど。

Carbon, Cocoa
10.2で検証した。

> アプリ内でファイル名の比較をするときなどのことを言ってるのかな?

ファイルシステムとフレームワークの組合わせによっては、
オープンするだけでもアウト。
0334login:Penguin
垢版 |
2008/07/31(木) 19:24:06ID:1XpJKIsM
>>333
>ファイルシステムとフレームワークの組合わせによっては、
>オープンするだけでもアウト。

具体的にどんな組み合わせですか?

HFS+だと、確かかなり下の方でnormalizeをしてるので結構大丈夫だと踏んでるけど...?
UFSだと、たぶんただのバイト比較だから簡単に駄目な例は作るはず。
でもUFSはUnicode以前からあるわけだし、今更どうしようもないという感じ。
しかし全然Linuxじゃないというw
0335login:Penguin
垢版 |
2008/07/31(木) 19:41:16ID:9ySiTva1
さすがに板違いだろ。HFS+まで出てきた日には。まぁ、カーネルは入ってるけどな。
0336login:Penguin
垢版 |
2008/07/31(木) 22:40:08ID:aKfSR7ZK
>>334
Linuxはiocharset=でmount時に指定できるFSが多いよな。
VFSのレイヤーでやればいいのにな。

DarwinはどのFSも決め撃ちオンリーだな。
0337login:Penguin
垢版 |
2008/07/31(木) 23:36:24ID:9ySiTva1
だから板違いだってば。
0338login:Penguin
垢版 |
2008/08/03(日) 16:34:54ID:buXIFNdC
そういえばこの前ubuntuというものを初めてインストールしてみたら
ホームディレクトリに「デスクトップ」とか作られててビビったんですがw

ext3ってエンコーディングとかの規定はどうなってるんでしたっけ?
0339login:Penguin
垢版 |
2008/08/27(水) 12:52:16ID:HfjolhVu
Unixのファイルシステムは基本的に8ビットスルーだろ
2バイト目に/が被るS-JISは事実上使えないだろうが
0340login:Penguin
垢版 |
2008/08/27(水) 16:58:21ID:iIVDIKRx
ttp://ja.wikipedia.org/wiki/Shift_JIS
> Shift_JISの2バイトコードの空間は、第1バイトが81-9FならびにE0-FC、
> 第2バイトが40-7Eならびに80-FCである。
0341login:Penguin
垢版 |
2008/08/28(木) 12:33:17ID:Iqmmut8G
昔の話だけど、jfsでUTF-8のファイル名するのになんか問題があった気がする。
0342login:Penguin
垢版 |
2008/08/29(金) 09:29:42ID:JXxabAXJ
>>339
要はファイル名の比較はバイトデータの比較ってことでいいでしょうか。

ということは上の方に書いてあるみたいにnormalizationの違うファイル名を使うと
問題が起きたりすると。
0343login:Penguin
垢版 |
2008/08/30(土) 08:46:40ID:2VCoYTof
>>342
ファイルシステム的には違うバイト列名の別ファイルだから問題は
特に起きない。が、ファイルマネージャとかアプリが表示段階で
正規化とかするとアボン。
0344login:Penguin
垢版 |
2008/08/30(土) 11:27:22ID:4z52jeuW
>>342
一番やっかいなのは、
正規化されてないファイル名がある時。
ファイル名が正規化されていることが分かっていれば、
二つのファイルが別のファイルシステムにあって、
違う正規化がされていても、一旦正規化してから、比較すれば良い。

ただこういうことを包括的に扱っているVFSはまだない。
0345login:Penguin
垢版 |
2008/08/30(土) 22:00:13ID:x9p+Pisp
ファイルシステムレベルでは問題ないかもしれませんが、例えばディレクトリをlsしたときに
同じ名前のファイルが複数表示されたらユーザーはアセるんじゃないですかね。

>>344
VFSですか。だとするととりあえず
「システムコールに渡すパス名はUTF-8ということになったので、そこんとこヨロシク」
みたいな宣言がいつか行われるとか?
0346login:Penguin
垢版 |
2008/08/30(土) 23:54:54ID:2VCoYTof
>>345
別にUnicodeに限った話じゃなくて

　touch he11o hello

が識別できない環境あるけどどうよ？とかかつてなされた
文字が「同一」とはどのレイヤ（コードマップなのか
エンコーディングなのかフォントなのかコンテンツなのか）が
定めるのか？というお定まりの侃々諤々が始まるだけだと思われ。
0347login:Penguin
垢版 |
2008/09/02(火) 08:45:08ID:phwFGNER
>>346
>　touch he11o hello

これ、単にグリフのデザインの話でしょ。ファイルシステムにもUnicodeにも関係ないし。

「同じ様に見えるファイルが複数表示される」というのは単にユーザが結果を確認する
ときの現象を書いてみただけで、
正規化の問題で本来一つのファイルが複数できてる、みたいな問題自体は文字の
見た目にかかわらず存在する。
0348login:Penguin
垢版 |
2008/10/21(火) 15:04:13ID:IoiTQ4Ul
>>342
utf-8は最短の表現以外は仕様で許さなくなったね。
複数表現があると禁止リストの回避がセキュリティ上の問題になるから。
0349login:Penguin
垢版 |
2008/10/21(火) 15:08:37ID:sbfjW96z
なるほどね(´・ω・`)
0350login:Penguin
垢版 |
2008/10/22(水) 06:46:11ID:rLYg3bwq
仕様が「許さない」といったってそれを強制できない以上は備えるしかあるまいよ。
0351login:Penguin
垢版 |
2008/10/27(月) 20:01:15ID:yiylzRYp
それはもちろんだ。きちんとエラーとして処さないといけない。
0352login:Penguin
垢版 |
2009/03/01(日) 12:12:57ID:qMTRjR4D
ぬるぽ
0355login:Penguin
垢版 |
2009/03/09(月) 21:42:00ID:jl7GQGVK
時々、文字コードを思い出したように変えるのは止めて欲しい。
既存の製品等をオブソレートにして市場から除去する為の口実ぢゃないか？
0357login:Penguin
垢版 |
2009/03/10(火) 01:10:42ID:b+3OdOvv
グリフのことを言いたいんじゃないのか？
0358login:Penguin
垢版 |
2009/03/10(火) 01:16:58ID:RpwmY4KZ
なんというか何もかも間違ってるレスだなそれ。
0359login:Penguin
垢版 |
2009/03/31(火) 02:07:47ID:aOI6y9SA
グ・グ・グリフの大爆笑
0360login:Penguin
垢版 |
2010/01/26(火) 11:12:31ID:1Oe/riv2
最近のLinuxって、LANG=ja_JP は ja_JP.UTF-8 ですか？それともja_JP.EUCですか。
0363login:Penguin
垢版 |
2010/01/30(土) 00:43:28ID:9vjcbNhb
日本語１文字が何バイトになっているのかなＵＴＦ８は？
0364login:Penguin
垢版 |
2010/01/30(土) 04:30:12ID:44NlzLAs
$ echo -n "日本語１文字" | wc -c
[Gnome] アプリケーション→アクセサリ→文字マップ
0365 忍法帖【Lv=5,xxxP】
垢版 |
2011/06/18(土) 01:27:33.87ID:OESwTLH8
ぬるぽ
0366login:Penguin
垢版 |
2012/03/05(月) 01:43:24.95ID:NArDNcNC
スレタイトルの改名が必要じゃないか？

＞Linux で ja_JP.EUC ロケールで暮らす方法についてのスレです。
いいかげんEUCは止めて欲しい。SJISを使えみたいな話と同じだ。
いまさらEUCがデフォなのってどんな鳥？
0367login:Penguin
垢版 |
2012/03/05(月) 06:25:40.58ID:OsgtQbaR
釣り針にすらなってないただのまっすぐな針金だな
0369login:Penguin
垢版 |
2012/10/18(木) 12:55:49.86ID:EPhTr28Q
Windows７のNFSサービスがEUCやShiftJISに対応してるのに
意図的なのか本気で不要と考えてるのか、UTF-8に対応してないの知ってビビった。
クソ高いUltimate買わないどNFSサービスついてないくせに。
実質WinのNFSサービスは使い物にならん。
0370login:Penguin
垢版 |
2013/04/20(土) 18:27:34.12ID:IGqqcAri
そもそもWinとNFSではロックのセマンティクスが違うし。
0371まあ日本語使うな禁止な
垢版 |
2013/06/17(月) 14:24:57.69ID:mcoRhX6s
Jconsole消滅
KON-UTF8化消滅
Utf8-kernel消滅
UNICON消滅

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

X window systemがｸﾗｲｱﾝﾄに特化できないからこそGPUﾀﾞｲﾚｸﾄで描画できない
GUI上だけがLinuxでいいじゃないかという奴とCUIがLinuxだという流れで
争っているからこそｶｰﾈﾙﾚﾍﾞﾙでUTF8が実装されない(表示できない)
0372login:Penguin
垢版 |
2013/06/18(火) 07:47:23.66ID:ZkyKpsxz
そもそもconsole自体kernelからなくそうという動きもあるしな。
0373login:Penguin
垢版 |
2013/06/18(火) 15:01:13.88ID:hs8574+Z
Unicode対応をまじめにやるのは大変。
サロゲートペアとか合成文字とか異体字セレクタとか。
どこまで実装して、どこでサボるかを見極めるのすら難しい。
0374login:Penguin
垢版 |
2013/06/27(木) 21:27:54.94ID:CnVHXcT1
EXT2、EXT3がNLS機能に対応せず。
UTF8でujis,eucJPに対応できない問題をどうすればいいの？
0375login:Penguin
垢版 |
2013/06/27(木) 23:03:09.03ID:/O/kkLoF
必要ない。> ujis,eucJP
0376login:Penguin
垢版 |
2013/06/28(金) 14:15:29.88ID:5T4jToix
>>375
おまえが人類には必要がない人間。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況