2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ja_JP.UTF-8

1 :login:Penguin:04/02/19 17:09 ID:EuXdEmYH
Linux で ja_JP.UTF-8 ロケールで暮らす方法についてのスレです。

2 :login:Penguin:04/02/19 17:10 ID:jzhqSI1H
2

3 :login:Penguin:04/02/19 17:14 ID:EuXdEmYH
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

以下、続々登場(予定)


4 :login:Penguin:04/02/19 17:28 ID: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 以下にロケールデータができる。


5 :login:Penguin:04/02/19 18:17 ID:xXNDJeIj
cocot ってよさげっぽいな。
これを使えば utf-8 を扱えないターミナルでも
$ cd 新規フォルダ
とかが出来るようになる?

6 :login:Penguin:04/02/19 18:28 ID:EuXdEmYH
>>5
できますが、(cocot のせいではないが) シェル自体が utf-8 にちゃんと
対応していないと表示が乱れます。
使い方⇒
cocot -p utf-8 ssh hoge.co.jp


7 :login:Penguin:04/02/19 18:35 ID:wXxKmQwW
Debian関係:UTF-8
ttp://tagoh.jp/w/wiliki.cgi?Debian%b4%d8%b7%b8%3aUTF-8&l=jp

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

9 :login:Penguin:04/02/19 21:52 ID:6evoEXG/
同上
subversion http://subversion.tigris.org/

10 :login:Penguin:04/02/19 22:18 ID: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 ってある?


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

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


12 :login:Penguin:04/02/19 22:33 ID:M3h1WS0+
GNU recode関係はこちらでよろしいのでしょうか?
興味があってこれから勉強しようと思っているのですが、、、
http://www.gnu.org/software/recode/recode.html

13 :login:Penguin:04/02/19 22:36 ID:xXNDJeIj
>>10
ちゅうか、これ cocot を使わずとも

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

とすればいいですね。

>>11
tcsh 試してみます。


14 :login:Penguin:04/02/19 22:47 ID:5Wvc5pyS
しかし、この状況ではja_JP.eucJP並にja_JP.UTF-8が使えるとは思えないのだが、
Fedoraは何で採用してんだ? 実験的ディストリったって、早過ぎないかね。

15 :login:Penguin:04/02/19 23:04 ID:5dM6BKnm
Fedora使ってますが、TeX関連とWnn7がUTFだと面倒みたいなので
EUC環境に避難中です。

16 :login:Penguin:04/02/19 23:08 ID:aWaxrpHY
bash自体(2.05b)はUTF-8に対応してるんじゃないの?
日本語の上でカーソル移動させてもちゃんと文字単位で移動する


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

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

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

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


19 :login:Penguin:04/02/20 00:46 ID: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 てすと' が、できなかったけど、常用してないので
# 詳しく調べてません。


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

21 :login:Penguin:04/02/20 01:40 ID:UfU4oXPS
と思ったらLANG=ja_JP.UTF-8とやれば現行シェルもちゃんと切り替わるな
LANG=ja_JP.UTF-8 ls とかやると(変更がその場限りなので)ダメだが

22 :login:Penguin:04/02/21 14:03 ID:+LxRviDa
Debian sid, KDE 3.2でLANG=ja_JP.UTF-8で使ってます。
ja_JP.EUC-JPから移行するときはゴミ箱に注意。
名前が化けて消しにくいファイルができて往生します。


23 :login:Penguin:04/02/23 00:15 ID: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?) へ変換できなかった文字をそのままのバイト数で
# へ変換するようだが、おかげで、カーソル位置とずれる。


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

25 :login:Penguin:04/02/23 00:30 ID:PMf+9Ivm
関係ないけど luit 面白いよ。

26 :login:Penguin:04/02/23 00:30 ID:CMqbSbol
喪前らfedorasu刷れへかいれ!

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

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


28 :login:Penguin:04/02/23 00:36 ID:cAXIkKBR
>>26
あいにく俺は Debian 使いだ。
それから http://www.routrek.co.jp/product/varaterm/
こんなものもあるらしい。


29 :login:Penguin:04/02/23 00:46 ID:cAXIkKBR
>>25
http://www.xfree86.org/current/luit.1.html
これでしょうか?cocot と同じようなソフトだと思われます。


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

31 :login:Penguin:04/02/23 01:46 ID: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
の両方が利用できる。


32 :login:Penguin:04/02/23 07:23 ID:hEHXw/KY
>14
昔から赤帽の日本語環境・デスクトップ環境はだーれも期待してなかった。
Fedoraはその伝統をしっかり受け継いでいる。

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

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

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

34 :login:Penguin:04/02/23 20:54 ID:5ButSZYg
>>33
( ´,_ゝ`)バカジャネーノ

35 :login:Penguin:04/02/24 14:56 ID:hD++ImT9
[debian-devel:15706] ja_JP.EUC-JP + ja_JP.UTF-8 サポート
http://lists.debian.or.jp/debian-devel/200307/msg00026.html


36 :login:Penguin:04/02/24 21:47 ID:O5/fwBER
CJK統合漢字は事実上中国が決めてることも知らない人が
いるスレはここですか?
> UTF-8使う=売国、って事でOK?
はっ、結論が変わらない

37 :login:Penguin:04/02/25 02:50 ID:545ZflI/
ところで、UTFは何の略?

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

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


38 :login:Penguin:04/02/26 11:43 ID: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)
 )


39 :login:Penguin:04/02/26 11:45 ID:acWb0Ca5
必要なし、とか書いたら丁度省略されたな…

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

40 :login:Penguin:04/02/26 16:57 ID:6SrjPF7S
>>39
困りまくりw
結局euc-jpに戻して使ってる。

41 :login:Penguin:04/02/26 17:41 ID:rQy1jDD8
>>33
eucはともかく、sjisじゃ幸せになれないよ・・・

42 :login:Penguin:04/02/26 18:18 ID:rR8Lcw99
>>41
つうかSJISなlocaleは未だにサポートされてないし。
Big5はあるのに。


43 :login:Penguin:04/02/26 22:34 ID:ZY4sGg1m
ないなら作ればいい
localedefで作成できたはず
RedHat8あたりからそうやってSJISとUTF-8のロケール作っていたが
(常用していたのはUTF-8のほう)

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

44 :login:Penguin:04/02/29 18:57 ID:7HQq9AIB
http://bedroomlan.dyndns.org/~alexios/coding_ttyconv.html
cocot と同じもの。

45 :login:Penguin:04/03/03 20:33 ID:cRtRVarj
http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm


46 :login:Penguin:04/03/08 18:20 ID: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 のフォントも使えますね。こりゃいい。



47 :login:Penguin:04/03/08 18:27 ID:kN4paUAc
>>45
御本人が降臨してた。
http://pc.2ch.net/test/read.cgi/linux/1003159137/587

48 :login:Penguin:04/03/08 18:29 ID:kN4paUAc
>>46
これですかね。
http://sourceforge.net/projects/rxvt-unicode

49 :login:Penguin:04/03/08 19:42 ID:dmU+GFkA
>>47
マジかよ@3
ま た き た か ( 別に逝いけどw

50 :端末スレに書いた人:04/03/08 20:07 ID: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 を使うようなことができます。


51 :login:Penguin:04/03/08 21:28 ID:dmU+GFkA
urxvt詳細解説希望。KTermみたいな感じで日本語入力できないの?

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


52 :login:Penguin:04/03/10 16:40 ID:XYz8ACQw
>>51
--enable-ximってしてもximが聞かないなあ

53 :login:Penguin:04/03/11 16:09 ID: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 本体に取り込んでもらうつもりはないのかな…?

54 :login:Penguin:04/03/11 16:11 ID:w0ox2sq1
そうそう、emacs 上で HELLO を表示すると、さすがに化け化けになる。
文字幅を適切に反映してくれるだけで、もうちょっとマトモに見えそうなもんだが。

55 :login:Penguin:04/03/11 17:03 ID:5SXwbIF3
>>53
Brunoに送ったらしいけど、まだ取り込まれていない。理由はようわからん。
glibcの方はもう取り込まれてるんだけど。

56 :login:Penguin:04/03/11 18:04 ID:w0ox2sq1
>>54UNICODE の文字の固定幅ってどうやったらわかるのでしょう?何かそれっぽい API が存在するのかな… iconv には見当たらないが。

57 :login:Penguin:04/03/11 18:14 ID:5SXwbIF3
libc的にはwcwidth()を使えばカラム数は取得できる。
もちろんlocale依存だけど。


58 :login:Penguin:04/03/11 22:28 ID:w0ox2sq1
>>57
locale に依存しない方法がほしいですねぇ(´・ω・`)

59 :login:Penguin:04/03/11 23:31 ID:O42OfURm
>>58
East Asian Width
ttp://www.unicode.org/reports/tr11/tr11-11.html
↑これを見れ。

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

60 :login:Penguin:04/03/12 04:06 ID:r4gmyMD+
>>59
あ、そうではなくて、
プログラム自身は A というlocaleで動いているが、
B という locale での幅を知りたい場合とか。
int wcwidth(wchar_t c, locale_t locale)
みたいな感じにしておかないと困らないかね…?

61 :login:Penguin:04/03/12 23:05 ID:J5ryzPu3
>>60
CとC++の話がごっちゃになってない?


62 :login:Penguin:04/03/12 23:18 ID:r4gmyMD+
>>61
誤爆?API関数の話だから言語は関係ないと思うけど。

63 :login:Penguin:04/03/13 00:38 ID:WWQ2I/Yq
>>62
Cのlocaleはglobal、C++のlocaleはnon-globalなobjectという
非常に大きな違いがあるが。


64 :login:Penguin:04/03/13 01:34 ID:Olzrdh4Q
>>63
Σ(゜д゜|||)マジスカ
ぜんぜん知らなかった。良かったらその辺の話へのポインタを教えてくださいませ。

65 :login:Penguin:04/03/13 13:00 ID:WWQ2I/Yq
>>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


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


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

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

69 :login:Penguin:04/03/17 01:51 ID:8JDKSyga
というか、mltermもiconvもglibcもその他もろもろのソフトウェア作成者のみなさん!

JISの1区29点は、U+2015じゃありません!U+2014です!

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

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

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

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

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

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

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


71 :login:Penguin:04/03/17 09:36 ID:v1NfxXgC
ここに書いても伝わらないだろう...


72 :login:Penguin:04/03/17 19:28 ID:/v+B0EmE
>>67
しかも、その日本語のページよりも上位のサイトは
どれも韓国語で書かれてない(w

73 :login:Penguin:04/03/17 22:19 ID:OPdte4Z/
下世話なことですが、
ウンコードには笑いました。


74 :login:Penguin:04/03/18 19:16 ID:O+ze/rOc
Uncode
確かにワロタ




75 :login:Penguin:04/03/19 16:32 ID:WDcHt9kU
愛が足りないとうんこになっちゃうってことか。一つ勉強になりますたよ(藁

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

77 :login:Penguin:04/03/25 09:01 ID:aLdLDvmf
>>70
「正しい」のはU+2014 (EM DASH)だよ。JISで規定されてるからね。

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

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

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


78 :login:Penguin:04/03/25 11:34 ID:n6uaZHdd
X 0213:2000にもバグがありましたね。
0221 名前
---- ----
2015 EM DASH
ってどっちやねん(正誤表で2014に訂正されたけど)

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

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

80 :login:Penguin:04/03/25 13:06 ID:AqIEMmRl
>>77
JISの世界の話としては同意。
CP932の世界ではU+2015が「正しい」というのも前提とするとして、

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

81 :login:Penguin:04/03/28 01:30 ID:XvF+To5+
cp932なりGNUな環境でjis規格ベッタリな変換したら化ける罠。
対象となる環境にあわせてベンダ固有のに従うのが吉かと。

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

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

83 :login:Penguin:04/03/30 10:23 ID:2+ZkdaEN
文字幅って半角何文字分かということ?
亜がAの2文字分っていう前提からしてフォント依存なのに、
なるべくポータブルの意味がわからん。
「これこれのフォントを使っている」という前提がどこかに必要。

84 :login:Penguin:04/03/30 10:44 ID:D5b8R0dA
>>82
ここよりpfaeditとかいじってるやつがいるところで聞いた方がいいんじゃないかな?

85 :login:Penguin:04/03/30 11:27 ID:+N0HhOX2
>>83
フォントのメトリックを含めて取得したいという意味では?

86 :login:Penguin:04/03/30 11:30 ID:ApCTMVrY
>>23 を読むと rxvt でなんとかしたい模様。

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


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


89 :login:Penguin:04/03/30 18:12 ID:8/uyDw3m
wcwidth, wcswidth じゃダメかね

90 :login:Penguin:04/03/30 19:34 ID:6qOQKc6W
フォントの幅ならX{mb,wc}TextEscapement。

91 :login:Penguin:04/03/30 21:19 ID:cj3Zi+AV
tcsh スレに utf-8 パッチが投稿されていた。
でも 2 バイトまでの utf-8 までしか扱えないという不完全なもの。
>>68 のほうがまだマシだよ。


92 :66:04/03/31 02:45 ID:f7K9ZfXB
>>89
cygwinのはまだi18n化がまっとーじゃなかったよーな……。
# 試してみよーかとは思うけど、1しか返ってこなかったら悲しい。

93 :login:Penguin:04/03/31 09:49 ID:6/tPX99p
> tcsh スレ
ってどこ? tcshで検索しても出てこない
> 2 バイトまでの utf-8
それってCJKはぜんぜん対応してないってことじゃん…

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


95 :login:Penguin:04/03/31 12:55 ID:aNoBOFKp
>>93 すまん。tcsh-ml の間違いだった。


96 :login:Penguin:04/03/31 15:40 ID:BTqfWFS5
>>93
> > 2 バイトまでの utf-8
> それってCJKはぜんぜん対応してないってことじゃん…

なかなか笑わせてくれるなw>cygwin

97 :login:Penguin:04/03/31 16:49 ID:aNoBOFKp
>>96 tcsh の話と cygwin の話はぜんぜん関係ないぞ

98 :66=92=94:04/03/31 17:10 ID: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;
}
はっはっはっはっ……。

99 :login:Penguin:04/03/31 17:58 ID:o1W2fgfD
>>98
IBMのICUでできそうな。おおげさかね?
こんなかんじ。

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

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

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


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

それとも漏れ何か勘違いしてる?>識者

102 :login:Penguin:04/03/31 21:35 ID:ZB8ltdIE
うむ、等幅フォントというくらいだから本来はすべて同じ幅のはずなのだ。
CJKのほうがある意味特殊。

103 :66:04/03/31 22:00 ID: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)ってターミナルエミュレータではどー
扱うことになってんの、とか、他にも気付いてない謎仕様があるんだろーなぁ、
とか……。


104 :login:Penguin:04/04/01 06:08 ID:4WIXUreh
Bidiはmltermをデファクトスタンダードとして広めてしまえ。
他に対応している端末エミュレータなんて無いだろ?

105 :login:Penguin:04/04/02 13:55 ID:Q4WUuZrw
>>91
よく見たらちゃんと 3 バイトにも対応してた。
けど日本語のファイル名補完できない(´・ω・`)


106 :login:Penguin:04/04/03 02:15 ID:8rtp/FCG
ja_JPなのになんでBidiが関係あるの?

107 :login:Penguin:04/04/03 22:05 ID:m8RgfiGD
>>106
そのためのUTF-8なんじゃない?

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


108 :login:Penguin:04/04/05 08:38 ID:Yy2AZo4/
>>107
それだと Mao Ze-dong や Мао Цзе-Дун を
検索することができないよ。

109 :login:Penguin:04/04/05 15:42 ID:fVLXvA3l
つーか
繁体字中国語では「毛澤東」
簡体字中国語では「毛?x6CFD;?x4E1C;」だから
Unicodeでもgrep '毛沢東'に意味がないのは明白なんだが。
誰が広めた都市伝説なんだろうか。

110 :login:Penguin:04/04/05 15:43 ID:fVLXvA3l
う、UNIX板は文字参照が使えないのか

111 :login:Penguin:04/04/05 16:57 ID:rNILKf1h
そこで Han unification ですよw

112 :login:Penguin:04/04/05 17:32 ID:fVLXvA3l
だから毛沢東は統合されてへんねん
つーか>>106からどんどん話がそれていくんだが

113 :login:Penguin:04/04/06 17:43 ID:zyebb/QV
Debian:i18nキタ━━━━━━(゜∀゜)━━━━━━!!
http://ukai.org/wiliki/wiliki.cgi?Debian:i18n&l=jp


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

115 :login:Penguin:04/04/08 07:32 ID:XquLn+B2
Mac OS X ということは NFD ですか

116 :login:Penguin:04/04/09 07:36 ID:7V6eqqUK
ワイド版ncursesを使ったり、libtextwrapを使ったり、fribidiを使ったり
ということでしょうか


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

118 :login:Penguin:04/04/11 21:25 ID:gbdBsXOA
Apacheつかって表示するファイル一覧もなー(サイズの位置とかがずれる)

119 :login:Penguin:04/04/12 17:27 ID:bOAxqETY
cygwin 専用 utf-8 対応端末エミュレータ
http://www.geocities.co.jp/SiliconValley-PaloAlto/8946/


120 :login:Penguin:04/04/19 16:27 ID:wtI4wXfK
>>114TAじゃないよん。ちなみに学部生ばっかりなので期待しない方がいいかもしれない。

121 :login:Penguin:04/04/21 10:49 ID: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 で動かすといったことが可能。
実行中、他に影響を与えることなく変更することも可能。


35 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)