5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 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 で動かすといったことが可能。
実行中、他に影響を与えることなく変更することも可能。


122 :login:Penguin:04/06/05 14:46 ID:FZ7KtiyQ
で、最近はまともに生活できるようになってるんですか。

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

124 :login:Penguin:04/06/06 02:54 ID:O+pxj2S+
最近はライブラリとかツールキットで内部はUCS4とかUTF8とかが
あるから、そういう場合は逆に変換の手間がなくなるかと。

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

125 :login:Penguin:04/06/06 03:35 ID:KxbaNUGk
>翻訳とか、複数言語を同時に表示する必要があるところでは

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

126 :login:Penguin:04/06/06 08:19 ID:S/boGRmd
いわゆる先進国の言語だけ扱うんだったら、それはそれは
便利なコードだからね。

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

128 :login:Penguin:04/06/06 13:24 ID:EGqCVEuE
メールもUTF-8で出していいですか?

129 :login:Penguin:04/06/06 13:31 ID:u+wbsnxA
>>128
受ける側が読めるなら。

130 :login:Penguin:04/06/06 13:58 ID:F4MfuIYb
>>129 つまり携帯以外ですか?

131 :login:Penguin:04/06/06 15:05 ID:Gm0vxGXW
メールのために UTF-7 があるが、まず使われないだろうな…

132 :login:Penguin:04/06/06 16:45 ID:8Zpd8Gr7
お前ら勘違いしてませんか?
ここは ja_JP.UTF-8 のスレであって,Unicode のスレではない.


133 :login:Penguin:04/06/13 23:45 ID:hijPyot4
Unicodeのスレはどこにありますか?
なかったとして何板に立てるのが適切ですか?

134 :login:Penguin:04/06/14 00:47 ID:2RL5Y4Ie
>>133
http://pc5.2ch.net/test/read.cgi/linux/1003159137/


135 :login:Penguin:04/06/14 13:11 ID:Kpo/7hO+
xmmsでwinampとtagを共有するには使えない

136 :login:Penguin:04/06/15 00:19 ID:1nIdf8BO
>>134
EUC撲滅のスレッドに見えますが…
スレ違いという理由で誘導されてるのに話題が出ているというだけの理由で
スレ違いのスレッドに案内されても困ります。
それともうにこーだーはすべからくEUCの撲滅を望まなければなりませんか

137 :login:Penguin:04/06/15 07:49 ID:+9gsKEDe
>>136
スレタイはアレだけど
中身は文字コード総合スレだよ。

138 :login:Penguin:04/06/17 10:41 ID:TUtqbBWf
xpdf って、UTF-8 に対応してますか?日本語表示できる PDF ファイルと、できない PDF ファイルがあって、どうやら、MS Office で作成した PDF ファイルがダメっぽいので、UTF-8 のせいかな、なんて思ってます。

139 :login:Penguin:04/06/17 14:51 ID:Wuxldr94
>>137
文字コードスレ2つも要らんだろ。
削除依頼よろぴく。

140 :login:Penguin:04/06/19 01:35 ID:hBPlVOmh
だからここは文字コードスレじゃないと主張してるんだろ。
それとも>>134以外に文字コードスレがあるの?

141 :へりくつ星人:04/06/27 16:21 ID:o/ZzpKCM
1を見れば分かるように、ここはロケールのスレで
あって、文字コードのスレではありません。「たまたま」
utfの話題が多いだけなのです。

142 :login:Penguin:04/06/28 00:15 ID:Tve7N2OE
最近はみんな満足してるのかな?
俺は tcsh に utf-8 パッチをあてたものを使ってるんだが、
ロシア語とか■とか、そういう端末上での文字幅があいまいな文字が
のきなみ半角扱いになってしまって、
ずれるんだよな。
emacs + mule-ucs でも同様なのでずれるんだよな。
どうしたもんかしら(´・ω・`)


143 :login:Penguin:04/06/28 06:24 ID:fWk93VUD
>>123
UNICODEの文字セットを日本語2バイトで扱う符号UTFCP2がある:
ttp://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
特徴は2バイトのコードポイント数が非常に大きいこと、状態非依存であること、
正確にテキストを逆戻り可能なこと。

144 :login:Penguin:04/06/28 06:37 ID:LgxqrPnR
LightCone乙

145 :login:Penguin:04/07/28 04:36 ID:lpc0mwrw
test

146 :login:Penguin:04/08/10 16:05 ID:jpxCYepz
てst

147 :login:Penguin:04/08/24 23:47 ID:+PM77uqo
>>143
UTFCP2
これただのネタじゃん

148 :login:Penguin:04/08/25 00:16 ID:SpZWXCwV
何を今更

149 :login:Penguin:04/11/06 05:16:52 ID:zrKtV3hP
http://www.ganaware.jp/archives/000060.html

150 :login:Penguin:04/11/08 10:07:11 ID:lMXPbsp8
何を今更


151 :login:Penguin:04/12/04 21:05:30 ID:6+KTXyp/
>>142
ずれないようにするにはターミナルエミュレータ(xtemとか)とエディタ (emacs
とか)の両方で全角半角判定が共通である必要がある。で、上の方で
1. 判定には何を使うべきか? wcwidth()/wcswidth()? その他?
2. 判定結果はどうあるべきか
... という話があったわけだが、結論は (ry
せめて 1. がこの世のすべての CUI なプログラムで統一されればずれなくなるん
だけどねー。

最近自分もこの問題に巻き込まれてしまった... orz

152 :login:Penguin:04/12/04 21:24:29 ID:Ac1hFSyz
>>151
最近は端末エミュレータに ck を使っているのですが、
ck (や xterm) は半角/全角があいまいな文字を
半角で表示するか全角で表示するか選択可能なので、
すこしマシになりました。


153 :login:Penguin:04/12/04 21:25:47 ID:5ZS2CgHD
>>151
統一できないから問題があるというか、統一できないような文字を
同一の文字として統合してしまった仕様に問題があるというか。

154 :login:Penguin:04/12/04 21:33:56 ID:ziFkWoAh
サロゲートペア考えたやつは死刑

155 :login:Penguin:04/12/04 21:39:06 ID:uTy9W2B7
>>154 うむ。あんな変なことするくらいなら、
素直に UCS4 で良かったのにな。

156 :中の人:04/12/04 22:01:59 ID:b+GZcVVR
だって16bitで十分だと思ったんだもん…

157 :login:Penguin:04/12/04 22:16:44 ID:6+KTXyp/
>>152
へーそうなんですか。曖昧な文字をすべて全角か半角か一方にすればとりあえず
困らないって感じですか?
実装をチェックしてみねば... どのみち、既存の wcswidth() を使ったら OK、という
ような単純なものではなさそうで。

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

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

やっぱ Unicode がイカン、ということで。

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

mozillaのxmltermどうよ?

159 :login:Penguin:04/12/04 22:40:54 ID: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 をベースに考えるからで、では既存のエンコーディング
をベースに考えると、こういうことになるのではないかと思いますが。。。
どのみち旧来の全角半角というのがあまり明快な考え方ではないので、決め方自体はすっきりしませんが、上のようにすれば、文字幅は地域コードのみに依存してエンコーディングに
は依存しないかなと。

160 :login:Penguin:04/12/04 22:47:51 ID:RHj7f47U
EUC-JPの半角カナは2バイトだよ・・・??

161 :login:Penguin:04/12/04 22:48:37 ID:6+KTXyp/
>>158
>mozillaのxmltermどうよ?
う、使ったことないけど、もしかして表示の整列とかを賢くやってくれちゃうのかな?
いろいろ疑問がわくけど (ry とりあえず後で使ってみます。

眠くなったきたので休憩...

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

>>160
3バイトじゃなかったっけ?

163 :login:Penguin:04/12/04 22:57:36 ID:b+GZcVVR
>>162
> 3バイトじゃなかったっけ?

そりゃ補助漢字でしょ。半角かなはSI/SO + 文字で2byte。

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

ところで、「字形-コードの対応表」って専門用語ではなんて言うの?

165 :login:Penguin:04/12/05 11:35:33 ID:U+jxCrh2
Coded Character Set

166 :login:Penguin:04/12/05 12:27:30 ID:3PBNWURc
>>165 符号化文字集合…か。

167 :login:Penguin:04/12/05 22:36:47 ID:U+jxCrh2
>Coded Character Set(CCS)
説明不足だった。これは文字毎に一意の番号を振ってある文字集合。
JIS X 0208とか、UCS-2とかがそれ。

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

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

AdobeのCIDは字形に番号が振ってあるな。

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

こうなったら、ウェブブラウザもファイルブラウザもターミナルも
全部統合した UI を目指す事にします。ってどこかで見た気が...

169 :login:Penguin:04/12/15 20:35:16 ID:AiVgzkM7
餅は餅屋ということわざを教えてあげたい

170 :login:Penguin:04/12/15 23:06:31 ID:pwu6u1JE
和菓子屋の餅も旨いよ。

171 :login:Penguin:04/12/15 23:18:48 ID:v6Owr1lz
佐藤の切り餅って超まずいね。というか餅じゃない。
あんな餅を餅だと思って食べている人がいるかと思うと
かわいそうだ。

172 :login:Penguin:04/12/29 01:17:45 ID:3YiZNVoJ


173 :login:Penguin:05/01/18 15:41:07 ID:Wb3X1dyN
>>171

十分うまいよ。

174 :login:Penguin:05/02/26 04:56:11 ID: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に変換する方法をご存知の方はいらっしゃいますか?

175 :login:Penguin:05/03/07 02:10:29 ID:233WSAJL
なんで UTF-8 の変換にエンディアンが関係するんdayo!
って一瞬思ったけど、iconv の内部的には一旦 UTF-16 とかにしてるのかな?
Apple のハックのせいなんなら普通の libiconv と比較してみたらいいんじゃねーの?
それか普通の libiconv にその UTF-8-MAC を追加する方向で修正してみるとか
...ってのができないわけね。
Mac OS X が使えるなら Mac OS X 上で変換してから他のプラットフォームに持って
いくんじゃ駄目なのか?

176 :login:Penguin:05/03/07 12:53:14 ID:v/gznSFy
>>174
> configureもmakeも問題なくできるのだけれども、
> iconv -f UTF-8-MAC -t UTF-8 等としてもどうもうまく動かないんです。

How?


177 :login:Penguin:05/03/08 12:02:39 ID:FpUM9LjU
ja_JP.UTF-8 ロケールでeuc-jpのnfs鯖をマウントするときみんなどうやってるの?
(sambaや、webdav使えばできるんだけどネ、nfsでの解決策を教えてね)

178 :175:05/03/08 12:30:30 ID:p+KoiNpg
問題が本当にエンディアンのせいなら、utf8mac_mbtowc() が呼んでいる
utf8_decodestr() の引数に UTF_REVERSE_ENDIAN をセットしてみたらいいかも。
ハードコーディングになっちゃうけど。
それで駄目だったら >>176 の回答待ちか。

179 :174:05/03/10 00:01:21 ID: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が全くわからないので意味はわからないのですが…

180 :login:Penguin:2005/06/06(月) 13:22:58 ID:1kxaCCcu
>>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__

という変更でいけるみたい。

181 :naruse:2005/07/07(木) 20:26:04 ID:Ajp7X6MQ
nkfの最新のCVS版で、
nkf -w --utf8mac-input hoge.txt
などとすればUTF-8-MACをUTF-8に変換できる・・・はずです。
うまくいかない場合は教えてください。

182 :login:Penguin:2005/07/13(水) 03:15:25 ID:GiU0rXXK
  

183 :login:Penguin:2006/01/10(火) 14:40:21 ID:s0uQ10WF
あけおめage

184 :login:Penguin:2006/01/18(水) 17:33:51 ID:1b8YR8q0
フェどらって、OSの仕様をかえればすぐにソフトの仕様もかわると思ったのかな?

185 :login:Penguin:2006/01/21(土) 16:33:52 ID:e7e/lB8H
「すぐに」とは思ってないんじゃない。

186 :login:Penguin:2006/02/01(水) 08:31:41 ID: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スレ立て公開中


187 :login:Penguin:2006/02/01(水) 10:57:17 ID:5OoK6VSB
age
OS が UTF-8 ってのは
UTF-8 対応のロケールが入っているかどうか?という意味なんでしょうかね。


188 :login:Penguin:2006/02/01(水) 11:00:41 ID:fQfoX2Vz
>>187
だね。kernelはutf-8対応なんかしちゃいないよ。

189 :login:Penguin:2006/02/01(水) 13:51:37 ID:IyxnkmjE
>>188
ん?VFATとかsmbfsなどのNLSにUTF-8が入ってるけど?
他のUTF-8/16なOSとファイルレベルで互換とらないといけないFilesystemはカーネルレベルでNLSサポートしてますよん。

190 :login:Penguin:2006/02/01(水) 15:11:08 ID:fQfoX2Vz
それドライバの話でしょ。カーネルからはNUL端の文字列にすぎないよ。

191 :login:Penguin:2006/02/01(水) 16:05:56 ID:qAxvh4Kn
ドライバがカーネルかどうかなんでどうでもいいから

192 :login:Penguin:2006/02/01(水) 18:36:18 ID:/PUwsy/N
カーネルをソースからコンパイルするときに
ファイルシステムのエンコーディングを
UTF-8だのSJISだのEUCだの指定できるのはなんなんだろうね。

193 :login:Penguin:2006/02/01(水) 21:30:09 ID:/ik9G5r3
>>192
ファイルシステムドライバへの指定だから、どのみち>>191だとおもわれ

194 :login:Penguin:2006/02/01(水) 22:51:36 ID:axKot8bp
EUCで書かれたシェルスクリプトをUTF-8でごちゃごちゃいじって、
おなじファイルなのに容量が増えることに愕然としたりして、
それでもいじってとりあえず動くものができたんですが、

日本語の文字化け以外にはやう゛ぁイことって何も無いですよね?

195 :login:Penguin:2006/02/02(木) 09:08:46 ID:Gkp5Be+f
おまえ

196 :186:2006/02/02(木) 21:37:38 ID:I2B8ecnQ
とりあえず、LOCALEの設定箇所を調べて
そこを確認すればわかるってことでいいようですね。

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

ともかく、ありがとうございました。


197 :login:Penguin:2006/03/09(木) 13:51:20 ID:Bujq6YPa
はじめてRedHatES4いれてみた。

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

ってな出力がUTF-8ででてるっぽいんだけど
これってEUC-JPに変更できないのかなあ。
ES3まではEUC-JPだったのに。

198 :login:Penguin:2006/03/09(木) 13:53:14 ID:kx4zcmdN
>>197
Red Hat Enterprise Linux スレッド part 24
http://pc8.2ch.net/test/read.cgi/linux/1136544255/

199 :login:Penguin:2006/03/09(木) 15:10:08 ID:LBUAWqfA
玄箱を Debian 化して、locale を utf8 にして、日本語manを入れたら、
euc-jp で書いてあって文字化け。orz


200 :login:Penguin:2006/03/09(木) 18:00:07 ID: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

201 :login:Penguin:2006/03/12(日) 01:04:13 ID:fe5y18+Z
>>192
ファイルシステムにエンコーディングは関係ない
ファイル名を決めるのはカーネルじゃないってわからない?


202 :login:Penguin:2006/03/12(日) 01:34:49 ID:zOXA93u/
ファイルシステムにエンコーディングは関係あるし。

203 :login:Penguin:2006/03/12(日) 02:24:44 ID:/fczP50N
>>202
どういう意味だろう?
とあるロケールで使用する文字コードが
ファイル名として使える文字コードの範囲内に入ってれば
何の問題も無いと思うんだが

例えばUTF-8のディストリでも、シコシコ設定書き直せば
システム全体の文字コードをEUCにもSJISにもできるわけで

204 :login:Penguin:2006/03/12(日) 02:51:32 ID:Qy+1QTbg
>>203
CONFIG_NLS_*
mount iocharset=*
を調べるか、黙って。

205 :login:Penguin:2006/03/12(日) 03:56:15 ID:K2J5B9uh
>>204
NLSやcharsetはエンコードと関係あるが
カーネルがエンコードしている事の証明にはならないわけで^^;
「黙って」ほしいなら
「お願いですからこれ以上つっこまないでください」と懇願した上で
お前が黙れw

206 :login:Penguin:2006/03/12(日) 04:11:48 ID:Qy+1QTbg
つfs/nls/*.c, fs/*fs/*.c

207 :login:Penguin:2006/03/12(日) 04:38:25 ID:zOXA93u/
>>205
んじゃ NLS や charset は何がつかってるの?
ファイルシステムはドライバでカーネルじゃないとか言うつもりかw

208 :login:Penguin:2006/03/12(日) 12:48:03 ID:/fczP50N
>>204
エンコードはしないが関係無くは無いって事か?
トンチが効いているが言い訳っぽいな…

209 :login:Penguin:2006/03/12(日) 15:19:01 ID:Oc3RTicA
たとえば'/'をディレクトリの区切りと見なしてるのは、ファイルシステム
だけじゃないと思うんだな。(思うだけでソース見て回ったわけじゃないが。)
とすると、8ビットクリーンな環境ならばファイル名がutf-8やeuc-jpは問題
ないが、iso-2022(-jp)やShift_JISを使うのには困る。

210 :login:Penguin:2006/03/12(日) 18:10:19 ID:MT19Gksr
>>209
禿同。

211 :login:Penguin:2006/03/12(日) 20:27:33 ID:ydqBlaR7
>>208
ん? iso-2022-jpを使ってファイルを取扱うシステムなんてあんの

212 :login:Penguin:2006/03/13(月) 00:57:05 ID:8cnv7aJ6
あらら極論を持ち出して・・・

213 :login:Penguin:2006/03/14(火) 15:01:37 ID:ZJm9Ix4t
File system 自身が '/' という「文字」を抱え込んでるってのか?

214 :login:Penguin:2006/03/14(火) 16:59:18 ID:XVd9AXqN
macでは':'
winでは'\'

215 :login:Penguin:2006/03/14(火) 23:40:20 ID:SOaD9AK3
まあ、/とか考えるまでもなく、ファイルシステムに文字エンコードは影響するし。

216 :login:Penguin:2006/03/15(水) 00:06:00 ID:FTGcTosr
>>214
Windowsも内部的には'/'だよ

217 :login:Penguin:2006/03/15(水) 00:20:57 ID:T9FwIHLt
あほ

218 :login:Penguin:2006/03/18(土) 14:10:06 ID:007Os0Uq
>>216
あ、そなの?知らなかった。

219 :login:Penguin:2006/03/18(土) 16:17:10 ID:akdUDpD2
>>216
ソース

220 :login:Penguin:2006/03/18(土) 17:46:45 ID:KLdgQbg+
NT系列では'\'が本則みたいだねえ。システムコールはもちろんどちらでも
受け付けるけど。
>>219
この一連の議論参照

221 :login:Penguin:2006/03/18(土) 19:56:18 ID:TivuVR12
システムコールがどちらも受け付けるからといって、
内部の扱いかどうかなんてわからんだろ。
ソースかバイナリを追った結果でもどこかにでてるんなら別だけど。

222 :login:Penguin:2006/03/18(土) 20:07:38 ID:KLdgQbg+
おっと失礼。この一連の議論ね。
http://mail.python.org/pipermail/python-list/2003-September/185195.html

>>221
DOS2.11は/だったが、(ソースは見た)、今は全く違っていても不思議はないね。

223 :login:Penguin:2006/03/18(土) 20:10:35 ID:rRI0eBQC
>>222
もしかして、脳晦の容量不足している?

224 :login:Penguin:2006/03/19(日) 00:37:05 ID:wDljjOw3
JFSのunicodeってなに?
UCS4?

225 :login:Penguin:2006/03/19(日) 03:30:27 ID:cmjBOE+n
無意味に煽ってる奴のほうがよっぽど顔悪く見える

226 :login:Penguin:2006/03/19(日) 13:45:56 ID:zdRlaDhI
>>225
そうやって無意味に煽るのはやめなさい。

227 :login:Penguin:2006/03/19(日) 13:52:08 ID:UpbZdusV
>>224
UCS2かUTF-16だとおもわれ。

228 :login:Penguin:2006/03/21(火) 01:13:28 ID:M+2sG4Eb
>>222
DOSは switcher を変えると / *も* 使えるようになるだけだ

229 :login:Penguin:2006/03/23(木) 17:04:49 ID:YW27Dazl
日本語はさ、1カラム文字と2カラム文字しかないけど
他の言語には3カラム文字とか4カラム文字とかあるの?
端末上で半角3文字分とか4文字分の文字。

230 :login:Penguin:2006/03/23(木) 19:27:17 ID:tr7Z4cN+
>>229
画面に出る時の幅のことを言っているの? プロポーショナルフォントは
W と i で幅が何倍も違うな。


231 :login:Penguin:2006/03/23(木) 19:28:31 ID:tr7Z4cN+
はっ。しまった。あからさまな釣りか。

232 :login:Penguin:2006/03/23(木) 20:01:27 ID:YW27Dazl
>>230
固定幅のフォントでの話です。
普通の日本語対応の端末エミュレータの場合そうでしょう?
端的に言って日本語以外だとwcswidthで3や4が返る可能性があるのかないのかなんですけど。

233 :login:Penguin:2006/03/23(木) 22:40:43 ID:KIoq1Iks
unicode とそうでないので混じってるみたいだけど、
emacs の HELLO ファイルみると
(debian だと /usr/share/emacs/22.0.50/etc/HELLO)
Hindi とか Malayalam とか Kannada とかの
フォントセットのところに3とか4の文字がある。

234 :login:Penguin:2006/03/23(木) 22:57:17 ID:YW27Dazl
>>233
ああ、やっぱあるのか。カラム数4ってどんな文字だorz
ありがとー。ちょっと対応を考えないといけないな。

235 :login:Penguin:2006/03/24(金) 01:34:23 ID:JGNnmuyn
unicodeって、リガチャがあるから面倒くさい。死ね。

236 :login:Penguin:2006/03/24(金) 17:08:59 ID:u8A96IKS
>>234
アラビア文字みたいに横に伸びる文字なんじゃないかな。
日本語も実際には伸びる時がある(「おーーーーい」という
時の「ーーー」の部分とか)が、それを普通の文語体の文章
ではあまり使わないから困らないだけだ。


237 :login:Penguin:2006/03/25(土) 00:18:32 ID:J9uW1TTI
>>236
なるほど。日本語も縦書きだと3カラム分消費する奴がありますよね。
おーーーいの「−−−」をしの長いようなので書く奴。

>>235
確かにUnicodeって色々面倒だとは思うけど
Unicodeに対応するだけで各国語に対応できるのは確かに便利だと思う。

238 :login:Penguin:2006/03/25(土) 00:21:28 ID:FjiAaDQS
各国語には対応できるけど多国語が微妙なんだよね。

239 :login:Penguin:2006/03/25(土) 03:07:23 ID:IICSJlaQ
多国語でなくて多言語って言ってほしいかな。

240 :login:Penguin:2006/03/25(土) 10:25:48 ID:7yPfObXQ
むはぁ

241 :login:Penguin:2006/04/29(土) 11:21:21 ID:3FCe/A1k
>>237
くの字点のことかな。繰り返しに使う。
普通は2文字分の長さではないかと。


242 :login:Penguin:2006/04/29(土) 21:33:35 ID:N4s8B/kn
でさ、ファイルシステムにエンコーディングは関係あるの?

243 :login:Penguin:2006/05/07(日) 13:49:44 ID:9szlYmVt
実運用上は、そんなエンコーディングの都合よりもftpdの文字化けで困るんだよね。
こればっかりはクライアント側の問題だからサーバ側ではどうにもならないし。

将来的にutf-8に統一されるなら今更eucJP使いたくないけど、
上記の理由で1台はeucJP確実なので、他も統一しないと使い勝手が悪い。
→全てeucjpで稼動。

244 :login:Penguin:2006/05/08(月) 12:07:10 ID:EWKIbwjX
>>243
ftpdが漢字を返すの? あ、もしや漢字ファイル名のこと?


245 :login:Penguin:2006/05/08(月) 15:11:47 ID:0ATCNism
>>243
ああ、あれで困ってEUC-JPに戻さざるを得なかった。(FTPサーバー立ててるから)
だって、UPされたファイルかたっぱしから文字化けして(LINUX上で)
何がなんだか分からんし。

そりゃ「日本語ファイルUPすんな!」って言えばいいんだけど、実際UPする人いるしな。
UP元のWindows機のファイルを全部英数字にリネームしろ! っていうのも横暴だし。


246 :login:Penguin:2006/05/10(水) 12:05:03 ID:PqdFQ5lv
eucjpなディレクトリツリーをsambaでローカルにのみ共有して
smbmountでiocharset=utf8でマウントして特定場所のみeucjpで
メインはutf8を共存みたいな

247 :login:Penguin:2006/05/10(水) 13:05:10 ID:loEZm4Y3
そういや自宅では玄箱を utf8 にしてるな。
たまに Windows マシンから samba でアクセスするが、それは
ちゃんと設定してあってファイル名は玄箱側に utf8 で書かれる
ようになっている。通常は utf8 になっている Linux マシン
から nfs (autofs) で一部をマウントして使っている。

ftp ねえ。でも ftp を使ったとしても ftp クライアントが
utf8 のファイル名に対応してさえいればいいんだよね。
そういうのってまだないのかな?


248 :login:Penguin:2006/05/10(水) 14:54:55 ID:gPG0recc
8bitスルーなら問題ないでしょ。
readline使ったヤツとか。

249 :login:Penguin:2006/05/11(木) 04:59:01 ID:iZnowODo
利用者側にftpクライアントを指定する時点で不合格じゃない?

250 :login:Penguin:2006/05/11(木) 14:17:34 ID:tz1hDbmm
>>249
んなこたねえと思うが。


251 :login:Penguin:2006/05/11(木) 21:20:12 ID:MPosGOlv
素朴な疑問なんだけど、ある文字が何カラムになるかがロケールで決定できる
と考えるのがそもそもの間違いであって、TerminfoとかTermcapみたいな物に
そこら辺を全部面倒みて貰う方がすっきりするんじゃないの?
ここで言ってる文字幅って結局端末に依存する情報でしょ?

できるかどうかは知らんけど

252 :login:Penguin:2006/05/11(木) 21:38:34 ID:tz1hDbmm
文字幅? 一応 Unicode には Halfwidth と名前の付いた文字はあるけどな。
まあ、端末やプリンタで等幅の時に半分で出ることが期待された文字という
ことなんだろうが、こんな半角文字は早く消えて欲しいものだ。

253 :login:Penguin:2006/05/11(木) 22:08:50 ID:MPosGOlv
別にいわゆる半角文字に限らなくてもいいんでない?
端末によっては表示できない文字だってあるだろうし、それをどう扱うかは
端末が勝手に決めればいいんじゃないの?
結果として端末によっては、?で表示されたり、〓で表示されたり、\uXXXXで
エスケープして表示されたりするかもしれないけど、それって端末の勝手だよね?
最終的に端末で表示した時にズレなきゃそれでいいんだし、ロケールで面倒
みる必要はないと思うんだけどな。
まあ、代替文字として何が表示されてるか分からないと困る場合はあるかも
しれないから、そういう時は代替文字を端末データベースに問い合わせて
教えて貰えればそれで済むんじゃない?
なんかおかしな事言ってる?

254 :login:Penguin:2006/05/11(木) 22:26:09 ID:gx3umMVs
Unicode Standard Annex #11
East Asian Width
http://www.unicode.org/unicode/reports/tr11/

Draft Unicode Technical Report #30
Character Foldings
http://unicode.org/reports/tr30/



255 :login:Penguin:2006/05/11(木) 23:03:46 ID:bYbMBCWq
合字があるから、面倒くさいんだよ。

256 :login:Penguin:2006/05/13(土) 03:27:14 ID:0C6WASA7
>>216-222
内部を覗いて見ないと分からないけど、
Win32 API では、"\" が本則っぽいな。

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


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

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

UNICODE も弱点は多いけど他の良い手段が思い当たらないので、
UNICODE 自身の改良に期待するしかないと思っている。


257 :login:Penguin:2006/05/13(土) 21:44:08 ID:S4JpwaCr
>>256 馬鹿発見

258 :login:Penguin:2006/05/17(水) 22:28:14 ID:FZX45EoA
バックスラッシュと\が同じ文字コードだったとか
聞いた気がしたんだが…

勘違い?

259 :login:Penguin:2006/05/17(水) 23:36:58 ID:a4MJ+Tci
で?

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


261 :login:Penguin:2006/05/19(金) 08:05:17 ID:GW8la2YX
>>260
> バックスラシュと\は同じコードだけど、

ムチャ言うなよ。


262 :login:Penguin:2006/05/19(金) 08:29:13 ID:Kplndbt6
>>260
http://ja.wikipedia.org/wiki/Unicode#.E6.97.A5.E6.9C.AC.E8.AA.9E.E7.92.B0.E5.A2.83.E3.81.A7.E3.81.AEUnicode.E3.81.AE.E8.AB.B8.E5.95.8F.E9.A1.8C

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

その状態で読むとみんなして変な文章書いているように見える。w


264 :login:Penguin:2006/05/22(月) 13:43:15 ID:GrV5T77x
俺、今、英語版Windows からIEでこのスレ見ているんだけど、
\ はバックスラッシュとして表示されます(円マークではない)。

その状態で読むとみんなして変な文章書いているように見える。w

265 :login:Penguin:2006/05/22(月) 23:15:37 ID:PaXuCUI2
俺、今、(かん高い声で!)、navi2ch!

266 :login:Penguin:2006/05/23(火) 00:38:55 ID:MNyc16BX
>>262
僕もそこを見た上でレスした。
UNICODEでは本来は 半角の\ と 半角の¥ が区別されるのは知っているよ。
しかし、

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

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

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

WAVE DASH - FULLWIDTH TILDE問題
は、海外のCDDBを利用する僕も影響を受けている。


267 :login:Penguin:2006/05/23(火) 02:56:03 ID:+D3NsWKB
>>266
区別していない?バックスラッシュとバックスラッシュは同じ文字なのに、どう区別するんだよ?

268 :login:Penguin:2006/05/23(火) 07:50:38 ID:YpTnBhhN
何がどういう風に問題なのかわからん。


269 :login:Penguin:2006/05/23(火) 08:14:43 ID:sMe4PIZ0
SJISはともかく、EUC-JPも使い分けられないんだっけ?
ISO-2022-JPは問題ないよね。

270 :login:Penguin:2006/05/23(火) 09:31:32 ID:YpTnBhhN
iso-2022-jp の半角部分は jis x 0201 だから、
\ は円マークだよ。
euc-jp は半角カナ以外の半角部分は ascii らしいので
\ はバックスラッシュだと思う。

271 :login:Penguin:2006/05/23(火) 10:13:01 ID:s/6PQypJ
>>270
前半は嘘というかミスリーディングというか……、
ISO-2022-JPがASCIIを書けないとでも思ってんのかいな。
生半可な聞きかじりを垂れ流す前に考えるなり調べるなりしような。

Emacsで新しいファイルを作って、次の一行を入れて保存し開き直してみ。
\^[(J\^[(B
(^[はESCなのでEmacsだとC-q ESCで入力)
一つめはバックスラッシュに、二つめは円記号になるから。


272 :login:Penguin:2006/05/23(火) 10:36:31 ID:YpTnBhhN
すまん。
http://ja.wikipedia.org/wiki/ISO-2022-JP
ここに書いてなかったから勘違いしたよ。
http://www.ietf.org/rfc/rfc1468.txt
こっちみたらちゃんと ascii 入ってるわ。

273 :login:Penguin:2006/05/23(火) 17:21:02 ID:6e4Xj433
http://www.iana.org/assignments/character-sets

274 :login:Penguin:2006/05/23(火) 22:41:11 ID:+D3NsWKB
>>272
「ISO646の国際基準版図形文字」って ASCII のことだろ?

275 :login:Penguin:2006/05/23(火) 22:57:04 ID:n3hVKX4N
ASCIIは、ISO646-USじゃん。
http://www.asahi-net.or.jp/~yw3t-trns/code/iso646.html

276 :login:Penguin:2006/05/24(水) 00:56:43 ID:5BECIijG
>>275
irv と比べてどこが違うの?

277 :login:Penguin:2006/06/04(日) 15:42:45 ID:jkHVDhT6
UTF-8な環境を結構長く使っているけど、いまだに
解決できないのがEmacsでギリシャ文字を使おうとすると
なぜか「全角」の文字上のカーソル移動が「半角」単位に
なって、編集ができなくなってしまうこと。

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



278 :login:Penguin:2006/06/05(月) 09:29:08 ID:bL9pWPFE
>>277
それ emacs だけでなることではないのでは?
wcswidth()が返す値が既におかしいとか端末の問題なのでは?


279 :login:Penguin:2006/06/05(月) 10:00:19 ID:8Lg4CNuP
-nwなの?

280 :login:Penguin:2006/06/06(火) 01:46:26 ID:kAFvi9EP
あ、たしかにコマンドラインでもなるね。
いままで文書書く時とか emacs -nw な中でしかそういった文字
使おうとしたことがなかったから気づいてなかった。

Debian GNU/Linux (sid) な環境で Putty(UTF-8-CJK) 経由で
使ってるんだけど、これはしょうがないのかな?


281 :login:Penguin:2006/06/06(火) 07:42:13 ID:jrnahNgL
端末エミュレータの問題なので、そっちを直してください。
putty使い続けたいなら、puttyスレかな。

282 :login:Penguin:2006/06/06(火) 22:46:29 ID:kAFvi9EP
そだね、炒ってきます

283 :login:Penguin:2006/07/10(月) 20:50:34 ID:nmNyvjRy
ttp://diary.imou.to/~AoiMoe/2006.07/early.html#2006.07.10_s01

すばらしい!



284 :login:Penguin:2006/08/05(土) 16:04:26 ID:QVT4c80E
Unicode の〜 Unicodeの〜 旗の〜もと〜♪

285 :login:Penguin:2006/09/06(水) 01:51:11 ID:IrLQmI4G
ageてみる。
ttp://nijino.homelinux.net/diary/200605.shtml
経由で、
ttp://www.mhsin.org/~mhsin/patches/screen/patch-cjkwidth
を当ててみた。ちょっと幸せ。
でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz

286 :login:Penguin:2006/09/06(水) 20:31:28 ID:WxxjRdHU
>>285
>でもαβγがwcswidth()や(string-width)で3だったりするので、やっぱりorz
wcswidth() って、glibc のやつ? それって誰(どのプログラム)が使ってるの?

文字幅という概念をこのまま使い続けるなら、各文字の文字幅の値(おそらくロケール依存)
をちゃんと定義して、各プログラム/ライブラリで共通の値を使うになってもらわないと
困る訳だが...
Unicode が提唱している East Asian Width (上の PuTTY のパッチもそれを参照している
模様)で、いいのかねえ?

287 :login:Penguin:2006/09/10(日) 17:39:46 ID:EBW7Z88N
UTFって英字(0x00-0x7f)は2バイト目以降には使ってないんでしょうか?

288 :login:Penguin:2006/09/10(日) 17:43:19 ID:QArT0E9g
すべてはMicrosoftの都合のままに...

289 :login:Penguin:2006/09/10(日) 17:47:58 ID:EBW7Z88N
仕様書に載ってました。
ttp://www.asahi-net.or.jp/~CI5M-NMR/w3/utf-8.html
2バイト以降は、常に最上位 2ビットが 10 になる。

良い仕様ですね。

290 :login:Penguin:2006/09/14(木) 08:14:51 ID:E62ZpEDu
UCS4ベタでいいよ。

291 :お茶碗:2006/10/04(水) 23:56:15 ID:h1r5LKWn
fedora5使ってますemacs でutf8のファイルは見られるんですが
日本語入力できません
mule-ucsというのをいれればいいのでしょうか?


292 :login:Penguin:2006/10/05(木) 00:03:30 ID:Rwz1aiUe
試してから書けよ、な?

293 :お茶碗:2006/10/05(木) 14:32:54 ID:wqpoHcXI
試しました
でも 日本語入力モードになってくれません

294 :login:Penguin:2006/10/05(木) 16:25:48 ID:PqMrisKX
>>291=293
何を使って日本語入力したいの? そもそもutf8云々ではないのではないの?

295 :お茶碗:2006/10/07(土) 11:31:44 ID:i+qvpb1B
>>294 さん
localeが utf-8のまま日本語入力したいだけです
手段は 何でもいいんです
utf8 のファイルを扱うのに mule-ucs が 必要みたいなことを
目にしたので。。 

296 :login:Penguin:2006/10/07(土) 11:42:18 ID: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)
もかな。

297 :お茶碗:2006/10/07(土) 15:29:32 ID:i+qvpb1B
>>296
さん  utf-8 >> utf-8-unix
と 変えてみました
なんとかいけそうです ありがとうございました。

298 :login:Penguin:2006/11/10(金) 22:58:35 ID:1rMy0pb+
utf8

299 :login:Penguin:2006/11/12(日) 03:26:08 ID:RBYyZwrm
みなさん日本語辞書には何を使われていますか?

300 :login:Penguin:2006/11/12(日) 13:50:03 ID:T2JS+fdN
新明さん

301 :299:2006/11/13(月) 04:53:51 ID:DjtpFn1c
すいません。日本語入力ソフトで単語登録するための辞書のことです。
kasumiがeucなので、みなさんは何を使われているのかなと思って。

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

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

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)