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
以下、続々登場(予定)
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 以下にロケールデータができる。
これを使えば utf-8 を扱えないターミナルでも
$ cd 新規フォルダ
とかが出来るようになる？
できますが、(cocot のせいではないが) シェル自体が utf-8 にちゃんと
対応していないと表示が乱れます。
使い方⇒
cocot -p utf-8 ssh hoge.co.jp
ttp://tagoh.jp/w/wiliki.cgi?Debian%b4%d8%b7%b8%3aUTF-8&l=jp
Gtk+2/GNOME2 アプリ http://www.gnome.org/
Qt(2|3)/KDE3 アプリ http://www.kde.org/
OpenOffice http://www.openoffice.org/
subversion http://subversion.tigris.org/
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 ってある？
tcsh は対応してることになっているけど、
マルチバイトの utf-8 文字がちゃんとずれずに表示されるかどうかは不明。
emacs + mule-ucs + M-x shell で、
process-coding-system を utf-8 にしたらうまくいくかも…
興味があってこれから勉強しようと思っているのですが、、、
http://www.gnu.org/software/recode/recode.html
ちゅうか、これ cocot を使わずとも
$ ssh hoge 'ls utf-8-folder' | iconv -f utf-8 -t euc-jp -
とすればいいですね。
>>11
tcsh 試してみます。
Fedoraは何で採用してんだ？ 実験的ディストリったって、早過ぎないかね。
EUC環境に避難中です。
日本語の上でカーソル移動させてもちゃんと文字単位で移動する
関係ないけど自分的に問題なのはターミナルで一部の全角文字が
半角扱いになること。gnome-terminalで★とか−とか。
全角判定をwcswidthなんかでやっていると思うのだが。
プロポーショナル文字フォントを有効にできれば
(そのうえで固定幅文字フォントを指定すれば)解決しそう
(mltermではできる)が、gnome-terminalではそんな設定はない。
man page自体には言語情報は含まれていないっぽくて
man pageのエンコードのまま出力されてしまう。
gettextみたく文字コード変換機能がついていればいいんだが。
その例自体はそうですが、
cocot の利点は仮想端末を提供してくれるというところですね。
あと >>4 にあるように iconv には色々問題があったり…
(cocot も libiconv を使うだけなので同じ問題を内包してますが)
>>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 てすと' が、できなかったけど、常用してないので
# 詳しく調べてません。
cd てすと
はうまく動くけど、あとからヒストリ編集するとぐちゃぐちゃになる。
LANG=ja_JP.UTF-8 ls とかやると(変更がその場限りなので)ダメだが
ja_JP.EUC-JPから移行するときはゴミ箱に注意。
名前が化けて消しにくいファイルができて往生します。
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?) へ変換できなかった文字をそのままのバイト数で
# へ変換するようだが、おかげで、カーソル位置とずれる。
開こうと思った。表示がくずれてわけわかりません。
set-filename-coding-system みたいなものってあるのでしょうか？
どうもファイル名などが euc だと思われてしまっているようです。
移動してみた。
set dspmbyte=utf8
という指定をしておけば、cd UTF8フォルダ、など補完もきく。
ls-F でも UTF8 ファイル名は一応表示できる。
だがしかし、tcsh は日本語の UTF8 文字を半角 3 文字分の
幅だと認識しているようで、カーソル位置が激しくずれる。
あいにく俺は Debian 使いだ。
それから http://www.routrek.co.jp/product/varaterm/
こんなものもあるらしい。
http://www.xfree86.org/current/luit.1.html
これでしょうか？cocot と同じようなソフトだと思われます。
luit は utf-8 さえ表示できればいろんなロケールの表示が可能になるやつです。
むしろ cocot の逆ですかね?
X の標準に入ってて、
XFree86 4.3 からは xterm で自動起動されるようになってます。
フォントさえ設定してあれば、
LANG=ja_JP.eucJP 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
の両方が利用できる。
昔から赤帽の日本語環境・デスクトップ環境はだーれも期待してなかった。
Fedoraはその伝統をしっかり受け継いでいる。
決まってるぢゃん。
JISやらGBといった漢字文化を潰し、欠陥unicodeをCJKの人々にも
強要して西洋人が楽するために決まってるでしょ。
彼らはCJK環境を「CJKのユーザのため」を第一に改善しようとは決して思っていない。
自分らが楽をする事は考えてるけどな。
unicodeとJISとのコード対応関係が日本で混乱してるのは彼らも知ってるはず。
それでも、EUCとSJISで平和に暮らしてるところに、こうやって新たな混乱を強要
してくるってのは、相当利己的だと思う。
UTF-8使う=売国、って事でOK?
( ´,_ゝ`)バカジャネーノ
http://lists.debian.or.jp/debian-devel/200307/msg00026.html
いるスレはここですか?
> UTF-8使う=売国、って事でOK?
はっ、結論が変わらない
Unicode Text Format
UCS (Universal multi-octet coded Character Set) Transformation Format
などの説明がみつかる。８は８ビット。
こうすれば見える。最後の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)
)
ところで、Fedora の人は utf-8 環境でもあまり困ってないのかしら。
端末エミュレータも最初からutf-8に対応してるみたいだし…
困りまくりw
結局euc-jpに戻して使ってる。
ｅｕｃはともかく、sjisじゃ幸せになれないよ・・・
つうかSJISなlocaleは未だにサポートされてないし。
Big5はあるのに。
localedefで作成できたはず
RedHat8あたりからそうやってSJISとUTF-8のロケール作っていたが
(常用していたのはUTF-8のほう)
いまEUC-JPでないと困るソフトってどれくらいあるかな
lynxとかそうだけど使わないし。tcshはビミョーに使えないな。
Xのソフトはフォント設定で何とかなることが多い。
RedHat9時代はEmacsも使えなかったがFedoraで使えるようになった。
cocot と同じもの。
…
端末エミュレータスレより
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 のフォントも使えますね。こりゃいい。
御本人が降臨してた。
http://pc.2ch.net/test/read.cgi/linux/1003159137/587
これですかね。
http://sourceforge.net/projects/rxvt-unicode
マジかよ@3
ま た き た か ( 別にいけどw
そうです。
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 を使うようなことができます。
# KTermのUTF-8パッチないのぉ?
# UXTermはフォント設定がよくわからん。-alias-fixed使いたいyo
--enable-ximってしてもximが聞かないなあ
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 本体に取り込んでもらうつもりはないのかな…？
文字幅を適切に反映してくれるだけで、もうちょっとマトモに見えそうなもんだが。
Brunoに送ったらしいけど、まだ取り込まれていない。理由はようわからん。
glibcの方はもう取り込まれてるんだけど。
もちろんlocale依存だけど。
locale に依存しない方法がほしいですねぇ(´･ω･｀)
East Asian Width
ttp://www.unicode.org/reports/tr11/tr11-11.html
↑これを見れ。
ED6. East Asian Ambiguous (A)
のおかげで、どうがむばってもlocale依存だすよ。(´･ω･｀)
あ、そうではなくて、
プログラム自身は A というlocaleで動いているが、
B という locale での幅を知りたい場合とか。
int wcwidth(wchar_t c, locale_t locale)
みたいな感じにしておかないと困らないかね…？
CとC++の話がごっちゃになってない？
誤爆？API関数の話だから言語は関係ないと思うけど。
Cのlocaleはglobal、C++のlocaleはnon-globalなobjectという
非常に大きな違いがあるが。
Σ(゜д゜|||)ﾏｼﾞｽｶ
ぜんぜん知らなかった。良かったらその辺の話へのポインタを教えてくださいませ。
この辺かな。
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
UTF-8のときは桁数を考慮するよー修正を検討してみまつ。
しばしお待ちください。(GANAさんとこのパッチも取り込んでおかんと……)
# wcwidth()は使えなさそうだなぁ。>>59を見て考えるか。
何故か日本語のページが出て来ますね。それにそこもutf-8で書かれているぽ
3バイトの文字が来たり、補完したりすると化け化けになります。
http://www.tech-arts.co.jp/macosx/macosx-jp/htdocs/15300/15330.html
このパッチ当ててみたりしましたが、上手く動いてるとはいいがたいような。
誰か解決方法しりません？
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/
JDK1.4 互換と CP932 互換の両方の変換テーブルを揃って用意してもらわないと、
困ります。
Unicode ソフトを書こうと考えているみなさんも、おねがいします。
U+2015 と U+2014 のどちらか「だけ」サポートして事足れりと考えないでください。
しかも、その日本語のページよりも上位のサイトは
どれも韓国語で書かれてない（ｗ
ードには笑いました。
確かにﾜﾛﾀ
ふと思いついて、set rprompt='%B%n@%m%b' していたのをやめてみました。
かなりマトモに表示さえるようになりました。
ls-F の表示カラムがずれてしまうのはあいかわらずですが、
それ以外はかなりマトモ。
C-a や C-e でカーソルを移動したときに変な位置へ飛ぶとか、
細かいところで色々怪しいですが、C-l でマトモな位置へ移動します。
あと一歩足りないところを修正して tcsh 本体へパッチ投げてくれないかなぁ
「正しい」のはU+2014 (EM DASH)だよ。JISで規定されてるからね。
ただ、Unicode Consortiumのサイトに置いてある変換表(今はobsolete)に
バグがあって、U+2015 (HORIZONTAL BAR)になっていたのが尾をひいて、
いまだにこちらを使い続けている実装があるというのが現状。
今後は、出力は必ず U+2014にして、入力にはU+2015も許す(JIS 1-29に変換)
というのが妥当かと。
CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。
0221 名前
---- ----
2015 EM DASH
ってどっちやねん(正誤表で2014に訂正されたけど)
> CP932はベンダ固有なので、限定された環境下以外では使わないのが吉。
IANAの登録簿でもWindows-31Jは
> but it is of limited or specialized use (see RFC2278).
と明記されてますね。
Webアプリケーションでは規格票に100%忠実なShift_JISの実装は
事実上不可能ですけど。
JDK 1.4の実装も0x5CはREVERSE SOLIDUSにマップしてますね。
JISの世界の話としては同意。
CP932の世界ではU+2015が「正しい」というのも前提とするとして、
「限定された環境下」であるところのWindowsが採用するCP932の世界が
unicode-日本語系コード変換の実装としては量的に圧倒的に多い、
というのを無視できるアプリケーションならともかく、
エディタなりウェブアプリなり、CP932の世界が絡む可能性があるなら、
ユーザーにJISとCP932の選択権があるべきじゃないかな？
対象となる環境にあわせてベンダ固有のに従うのが吉かと。
ていうか、変換テーブル大杉。
ttp://www.debian.or.jp/~kubota/unicode-symbols-map2.html
が知りたいのですが、mltermやw3m-m17nあたりからパク^H^H^H^Hを参考にする
くらいしか手はないでつか?
# ひたすらぐぐってみたんですが、どーにもよさげな情報が……。
亜がAの2文字分っていう前提からしてフォント依存なのに、
なるべくポータブルの意味がわからん。
「これこれのフォントを使っている」という前提がどこかに必要。
ここよりpfaeditとかいじってるやつがいるところで聞いた方がいいんじゃないかな？
フォントのメトリックを含めて取得したいという意味では?
> 文字幅って半角何文字分かということ？
うぃ。
> 亜がAの2文字分っていう前提からしてフォント依存なのに、
あー、とりあえずターミナルエミュレータとゆーか固定ピッチフォントのみの
世界限定の話です。目的はcocotで変換不能文字を適切なカラム数でスキップす
ることなんで……。(とは言え、ここでがんばったとしてもEast Asian Width
でambiguousになる文字についてはどーにもこーにもcocotのよーなレイヤでは
整合性なんか取りよーがなさそげなので、これはこれで鬱)
>>84
フォントエディタですか。うーん、ちょっと関心のある部分が違うよーな。気
にしているのはUnicode文字列をターミナルエミュレータ上でどうハンドリン
グするかなので。
に)はまった泥沼に足突っ込んでるオカ〜ン。最新の情報はどっかにまとまっ
てないもんか……。
# 調査すべきもの: 最近のxterm、luit、mlterm、w3m(0.5にはlibwcが入って
# るみたいなので、w3m-m17n相当?)、emacs、他に何かあるかなぁ。
でも 2 バイトまでの utf-8 までしか扱えないという不完全なもの。
>>68 のほうがまだマシだよ。
cygwinのはまだi18n化がまっとーじゃなかったよーな……。
# 試してみよーかとは思うけど、1しか返ってこなかったら悲しい。
ってどこ? tcshで検索しても出てこない
> 2 バイトまでの utf-8
それってCJKはぜんぜん対応してないってことじゃん…
ttp://www.okisoft.co.jp/esc/cygwin-5.html#5.3
だめぢゃん＿|￣|○
# wide character系の関数はことごとく期待できないとゆーことで
# ファイナルアンサー?(;_;)＞cygwin
> > 2 バイトまでの utf-8
> それってCJKはぜんぜん対応してないってことじゃん…
なかなか笑わせてくれるなｗ＞cygwin
しつこくて済みませんが、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;
}
はっはっはっはっ……。
IBMのICUでできそうな。おおげさかね？
こんなかんじ。
#include <icu/uchar.h>
UEastAsianWidth ea = (UEastAsianWidth)u_getIntPropertyValue(c, UCHAR_EAST_ASIAN_WIDTH);
厳密には幅そのものじゃないけど。まぁ使えそう。
TOP カテ一覧 スレ一覧 削除依頼 ▲
・ 次のスレ
DocBook総合
LinuxでVPNルーターは作れるのか？
コマンド忘れたら上げるスレ(雑談可)
効率的なLinuxの学習方法