アカウント名:
パスワード:
このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、 行の折り返しがおかしくなります。 いま、Debian unstable (Sid) の bash 3.0-1 を使ってみましたが、 なおっていません。 すでに1年以上も放置されているバグ [debian.org]らしいです。
EUC-JP ロケールでは、(ASCII と JIS X 0208 に限れば) 文字幅とバイト数が一致するので、この問題は起こりません。
ちなみに、Debian において、debconf を readline インタフェースで ja_JP.UTF-8 ロケールで使うと画面がおかしくなるのは、これが原因です。
つーか、shellで日本語なんか使うなよ...
仕方ないので「project_ほげほげ」とかにして、「$ cd project*」や「$ cd p(tab-key)」で対応。それなりに使えますよ。周りも真似してくれるのは良いのだけど、半角にしている目的を知らない奴は全角で「project_ほげ」にしちゃうんだよな・・・。
vi使える人には「set -o vi」を教えてあげよう。案外知らない人が多いっす。
バイト数 == Half width の数 な関係ならば問題ないのだろうけど、 EUC-JP の JISX0201とか 3byte の部分とかならば問題出るとかそういう話なら、「Unicodeダケの問題」とはいえないのでしょう。 イロイロな意味で バイト数 != 文字列の幅 っていうことを言っていかないと。
問題になってるのは、ビット表現の話みたいなので、 関係してくるのは文字コード、正確には文字エンコーディング法(character encoding)でしょう。 JIS X 0208 の文字でも、Shift JIS、ISO-2022-JP、EUC-JP などの方法で表現できます。 Unicode でも、UTF-8、UTF-16、UTF-16BE、UTF-16LEなどなど。
二バイト系を毎日使ってる日本人でさえこのへんを良く分かってない人が多いわけで。「アホですか?」とか言ってるし。
参考リンク
まあ、ja.po ファイルを UTF-8 で書くと、EUC-JP に変換不可能な文字が紛れ込んでしまい、EUC-JP 環境では文字化けするという可能性が生じますけど。
ついでに言えば、UTF-8 ←→ EUC-JP 変換テーブルがシステムというかベンダーごとに異なるので、たとえば Windows 用の UTF-8 対応エディタで ja.po を編集すると、EUC-JP (というか JIS X 0208) の範囲に入っている文字を使った場合でさえ、Linux 上で文字化けするなんてことが起こりえますが。たとえば「~」とか「-」とか。そういう面倒にかかわり合いたくなければ、po ファイルを EUC-JP で書くことをおすすめします。
なければ Markus Kuhn's UTF-8 and Unicode FAQ [cam.ac.uk] にソースがあります。
こんな英語でいいのかな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
known bug (スコア:3, 参考になる)
このため、UTF-8 ロケールでプロンプトにロシア文字や漢字などを設定すると、 行の折り返しがおかしくなります。 いま、Debian unstable (Sid) の bash 3.0-1 を使ってみましたが、 なおっていません。 すでに1年以上も放置されているバグ [debian.org]らしいです。
EUC-JP ロケールでは、(ASCII と JIS X 0208 に限れば) 文字幅とバイト数が一致するので、この問題は起こりません。
ちなみに、Debian において、debconf を readline インタフェースで ja_JP.UTF-8 ロケールで使うと画面がおかしくなるのは、これが原因です。
Re:known bug (スコア:1, 興味深い)
なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
ものすごく無駄な感じがしてしょうがないんですけど。
Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
Re:known bug (スコア:1, おもしろおかしい)
ナイ。マッタクナイ。
どうして、ここで Unicode ダケが問題にされてるのか分からん。
日本語を使えるようにすることによるバグ情報ってどうにか整理できないんですかね。
なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状は
ものすごく無駄な感じがしてしょうがないんですけど。
日本人は死力を尽くして啓蒙活動する義務があるんじゃないか?
Re:known bug (スコア:0)
Re:known bug (スコア:1)
仕方ないので「project_ほげほげ」とかにして、「$ cd project*」や「$ cd p(tab-key)」で対応。それなりに使えますよ。周りも真似してくれるのは良いのだけど、半角にしている目的を知らない奴は全角で「project_ほげ」にしちゃうんだよな・・・。
vi使える人には「set -o vi」を教えてあげよう。案外知らない人が多いっす。
Re:known bug (スコア:1)
/home/s-tomo/projects
$ ls
project_????????/ project_????????/
$ echo *
project_ふがふが project_ほげほげ
$ cd project*
$ pwd
/home/s-tomo/projects/project_ふがふが
「ほげほげ」の方を指定するにはどうすれば.........
Re:known bug (スコア:2, 参考になる)
2370528 project_ふがふが
2370525 project_ほげほげ
> cd `find . -inum 2370528`
Re:known bug (スコア:1)
project_???????????? project_????????????
$ echo *
project_ふがふが project_ほげほげ
$ cd `echo * | awk '{ print $1 }'`
$ pwd
/home/ueyama/hoge/project_ふがふが
# UNIX系OSなら、色々なパターンがありそう。
Re:known bug (スコア:1)
Re:known bug (スコア:0)
マウントする際は、iocharset=euc-jpってオプションを指定しておく
と日本語のファイル名も問題無く表示できますよ。ファイル名の補完
も出来ます。
以前は私もそう思いましたが (スコア:1, おもしろおかしい)
Re:known bug (スコア:0, 余計なもの)
あんたの好みを押しつけられても困る
つーか、コンピュータで日本語なんか使うなよ...
Re:known bug (スコア:1)
#使ったことない(笑)けどIDで
Re:known bug (スコア:0)
アホですか?
JIS X0208 では問題が起こらないからでしょ。
Re:known bug (スコア:2, 興味深い)
バイト数 == Half width の数 な関係ならば問題ないのだろうけど、 EUC-JP の JISX0201とか 3byte の部分とかならば問題出るとかそういう話なら、「Unicodeダケの問題」とはいえないのでしょう。 イロイロな意味で バイト数 != 文字列の幅 っていうことを言っていかないと。
Re:known bug (スコア:0)
これに文字数も含めて『バイト数と文字数と文字列の幅は一致すると考えちゃいかん!』と掲げれば,#598295 [srad.jp]のACの方が言ってた『なんか毎度毎度同じようなバグがあっちこっちのアプリで出てくる現状』もかなり改善できるでしょう。
国際化プログラミングする上での心得ですので,
JIS X0208 (スコア:1)
> JIS X0208 では問題が起こらないからでしょ。
JIS X 0208 は文字セット(character set)で、文字の一つひとつに値は与えられていますが、最終的なビット表現は規定しません。Unicode も同様。
問題になってるのは、ビット表現の話みたいなので、 関係してくるのは文字コード、正確には文字エンコーディング法(character encoding)でしょう。 JIS X 0208 の文字でも、Shift JIS、ISO-2022-JP、EUC-JP などの方法で表現できます。
Unicode でも、UTF-8、UTF-16、UTF-16BE、UTF-16LEなどなど。
二バイト系を毎日使ってる日本人でさえこのへんを良く分かってない人が多いわけで。「アホですか?」とか言ってるし。
参考リンク
Re:known bug (スコア:0)
encoding 方式が書いてないんだけど、SJISだと \(0x5c) で問題あるよ。
あ、上のほうで EUC-JP って言ってたっけ? JISX0201 はどうするの?
あぁ、JIS roman/kana は使うなって?じゃぁ、JISX0212 は?
日本語以外で言うなら、 EUC-TW とかどうすんの? EUCから逸脱してるから外す?
BIG5 も 0x5c 二バイト目に入るね。どうすんの? GBKは? GB18030は?
Re:known bug (スコア:0)
問題っていうか、未来は Unicode の中にあるってことになってるし、
実際多くのOS/アプリがそっち向かっている中で、同じような問題があちこち
で起きているからじゃないの?
# 「日本語」の話を持ち出す方がよほど奇異に見えるが
Re:known bug (スコア:0)
>>国際化に伴うバグ情報ってどうにか整理できないんですかね。
から
>>Unicode の中の人は死力を尽くして啓蒙活動する義務があるんじゃないか?
国際化の話をしてるのになんで Unicode の中の人だけが死力を尽くす必要がある?ないでしょ?
> # 「日本語」の話を持ち出す方がよほど奇異に見
Re:known bug (スコア:1)
debconf の ja.po を UTF-8 にしないのか?とmaintainerから突っ込まれていたので、
それに対する返事の参考にします。やっぱり問題あるんですね。
ありがとう、ありがとう、ありがとう。
Re:known bug (スコア:2, 参考になる)
まあ、ja.po ファイルを UTF-8 で書くと、EUC-JP に変換不可能な文字が紛れ込んでしまい、EUC-JP 環境では文字化けするという可能性が生じますけど。
ついでに言えば、UTF-8 ←→ EUC-JP 変換テーブルがシステムというかベンダーごとに異なるので、たとえば Windows 用の UTF-8 対応エディタで ja.po を編集すると、EUC-JP (というか JIS X 0208) の範囲に入っている文字を使った場合でさえ、Linux 上で文字化けするなんてことが起こりえますが。たとえば「~」とか「-」とか。そういう面倒にかかわり合いたくなければ、po ファイルを EUC-JP で書くことをおすすめします。
Re:known bug (スコア:0)
EUC-JPを置換するものにはなりえないということ?
俺的にはEUC-JPの世界でのんきに暮らしたいのだが
WindowsとかGNOMEとかUTF-8が攻めて(?)きて
またーり出来んのだが。
Re:known bug (スコア:1)
UTF-8にしたければ、すべてを一斉にUTF-8にしないと不都合がでる。それを
Unicodeの欠点とみなすかどうかは、立場の違い。
#私の場合、未だにmltermとか、mozilla、emacsを立ち上げる時だけ、
#ja_JP.eucJPに設定して、それ以外はすべてCロケールですが。やっぱり、
#いずれenロケールに移行しないといけないのだろうか。
Re:known bug (スコア:0)
> #いずれenロケールに移行しないといけないのだろうか。
そうなの? C は廃止で en に移行する流れなの?
Re:known bug (スコア:0)
ISO Cのlocaleの仕組みからして廃止はありえないし、またする必要もない。けど、UTF-8を取り扱おうとするならen_US.UTF-8とかen_GB.UTF-8といったlocaleが必要になる。
Re:known bug (スコア:0)
Re:known bug (スコア:1)
Re:known bug (スコア:0)
C locale の由来はそうなの? 詳しく教えてほしいんだけど、
「コンパイラに依存」ってどういう意味?
できればポインタを教えてください。
Re:known bug (スコア:0)
んー,そんなに曖昧でもないんじゃないですか。
Single UNIX Specification [opengroup.org] を見ると,結構かっちり決まっていると思います。
Re:known bug (スコア:1, 興味深い)
Re:known bug (スコア:2, 参考になる)
なければ Markus Kuhn's UTF-8 and Unicode FAQ [cam.ac.uk] にソースがあります。
Re:known bug (スコア:0)
貴殿にこのやっつけパッチを進呈しよう。
--- bash-3.0/lib/readline/display.c.org 2004-05-28 11:57:51.000000000 +0900
+++ bash-3.0/lib/readline/display.c 2004-07-30 22:51:06.392651768 +0900
@@ -342,6 +342,7 @@
&prompt_invis_chars_first_line,
&prompt_physical_chars);
これでどうだ、UTF-8対応コラム幅パッチ (スコア:0)
もう少しきちんと仕上げてみました。暇で親切な人は
検証してみてよさそうなら、本家に送って欲しい。
私は英語だめなんでね。
--- bash-3.0/lib/readline/display.c.org 2004-05-28 11:57:51.000000000 +0900
+++ bash-3.0/lib/readline/display.c 2004-08-01 14:05:23.807209824 +0900
@@ -253,6 +253,9 @@
else
ninvis += ind - pind;
Re:これでどうだ、UTF-8対応コラム幅パッチ (スコア:1)
こんな英語でいいのかな
Re:これでどうだ、UTF-8対応コラム幅パッチ (スコア:0)
Re:これでどうだ、UTF-8対応コラム幅パッチ (スコア:0)
>ためしてみました。うまくいっているようです。ただし、プロンプト自身が80カラムを超える場合はだめなようです。
一応対処してみましたが、手抜きで無駄に効率が悪いし、ソースを読みきれてないので副作用があるかも。
パッチのままだと書き込めないので、見れば分かるけど、BASE64でエンコードしてます。
begin-base64 644 rl2.patch.gz
H4sICJ/PD0EAA3JsMi5wYXRjaAB9VMtu2zAQPEdfMUc7shzJjeNX4rhtWrQF
mntRFAItURYRiRQoOopR5N+71MNPoDzYIrkzOzu7kud5iEVZZGw3jIZKb65G
vn/r+WNvNEUQzMeT+TgY+t2C689833Fd94BqEVPPv4U/mge38/Hd8G4y
Re:これでどうだ、UTF-8対応コラム幅パッチ (スコア:0)
begin-base64 644 rl_utf8.patch.gz
H4sICLGlEEEAA3JsX3V0ZjgucGF0Y2gAlVVNb9NAED07v2JQL0lsJ3ZSpzSm
kBaKQIKe4IAQsvyxjlddey170xAQ/52Z3TjkAwrsIbbXO2/evHkTu64LSdwW
7nTkjQVPxg2LM8ErNs54W4t4M0pHsllaE887d73AnTwF358HF/PAH3ndAtu7
9Lyebdt/w9riPHW9c/ARJJh7/mga+LPpLPAnW5zFAtzJ+aVzATZdfA8Wix5Y
oNe64IJBX7juYLcHMGww9xUMa9sOd9s8h/4Tvqxkw6vloOdaViPAvgJeZeBC
jZewZ1vWd/oB+O07gLrYtGkRNy29jRoRpVJEa56pol+XytFHHQob6IAfu+xM
tAwfrIpXD7w9xu5O1a4bWpY1HkIqy5pVbawY5LIBgTcNhq
Re:これでどうだ、UTF-8対応コラム幅パッチ (スコア:0)
begin-base64 644 rl_utf8-2.patch.gz
H4sIAP7vEEEAA5VVTXObSBA9o1/RqVxAgIQ+sC0RO3ISp5KqxKfkkNraovgY
xJSBoQBZUVL+7+meESxCG2d3DgJ6pl93v349sm0bwqBO7cXEmWY8nFYsiDNe
sGnM6zILDpNoIqqtNnecpe249vwKZrO1e7l2ZxOnXWA6K8cZmab5J6wjzpXt
LGG+WDtXa/dislwtlu7SRZPC2WzAni9X1iWY9Jg5sNmMQAO59inPGOiZbRud
DWBcYexrGJem6XVmnoD+gm8LUfFia4xsTasyMK+BFzHYUOLDG5ma9pN+AP51
D6BMD3WUBlVNu36V+ZHI/D2Pm1Qv88aSRy1yM6TDUxedZTXDD63gxSOvh9jt
qdK2PU3TpmOIRF6yog4aBomoIMOXCl2iiuWsaG