ラベル jisx0213 の投稿を表示しています。 すべての投稿を表示
ラベル jisx0213 の投稿を表示しています。 すべての投稿を表示

2011年7月10日日曜日

kterm, jless, screen パッチ更新

kterm, jless, screen の UTF-8/JIS X 0213 パッチに対して emacs-23 の旧JIS(JIS C 6226-1978)の扱いに対応させるための互換マッピングを追加しました。合わせて jless のバグの修正と、kterm の UTF-8 によるコピー＆ペーストに対応させるためのパッチを入れておきました。

ダウンロード: kterm-6.2.0.ext06.patch.gz

ダウンロード: less-382-iso262.ext03.patch.gz

ダウンロード: screen-4.0.3.ext02.patch.gz

kterm/X11 における UTF-8 によるコピー＆ペーストは色々と互換性の問題もあって敢えて外していたのですが、最近は内部がunicodeアプリケーションが多いので、利便性も考えて実験的に対応してみました。UTF-8といっても例によって日本語にのみ対応です。
投稿者 時刻: 5 件のコメント:
ラベル: , , , , ,

2011年7月5日火曜日

emacs 23 jisx0213-2000マッピング問題

Emacs-23.3 では JIS X 0213 の 2000年版と2004年版の両方に対応しているのだが、ちょっとした問題があるようです。Emacs では JIS X 0213 の実装として以下の character-set が定義されています。

  • japanese-jisx0213-1 (2000年版の1面)
  • japanese-jisx0213-a (2004年で1面に追加された文字)
  • japanese-jisx0213.2004-1 (2004年版の1面)
  • japanese-jisx0213-2 (2000年版の2面、2004年と2面も同じ)

ということで jisx0213-1 ＋ jisx0213-a ＝ jisx0213.2004-1 という関係になっています。なっているはずです。なってないと困ります。 ....... でもなっていません(泣)。

emacs-23.3 では何故か jisx0213.1 ＝ jisx0213.2004-1 になってしまっています。japanese-jisx0213-a が何のためにあるのかわからない状態です。

実際問題としては2004年で追加された文字はった11文字だし、EUC-JIS-2004 や Shift_JIS-2004 や UTF-8 で扱う時に差ははないので普通に使っていて問題になることは少ないと思いますが、、ISO-2022系の文字コードを使用した時に2004年版にしかないはずの文字が2000年版用のシケーンス ESC $ ( O で出力されてしまうという問題があって気付きました。

elisp の部分の実装は良い感じなのでバイナリに問題があるのだろうということで、ソースを確認したところ2000年版の変換表(JISX2131.map)に2004年の追加文字が誤って紛れ込んでいるようなので、取り除くことにしました。以下そのパッチです。

diff -urN emacs-23.3.orig/etc/charsets/JISX2131.map emacs-23.3/etc/charsets/JISX2131.map
--- emacs-23.3.orig/etc/charsets/JISX2131.map 2010-10-13 07:43:12.000000000 +0900
+++ emacs-23.3/etc/charsets/JISX2131.map 2011-06-14 10:19:22.143109803 +0900
@@ -1157,7 +1157,6 @@
 0x2d79 0x22BF
 0x2d7d 0x2756
 0x2d7e 0x261E
-0x2e21 0x4FF1
 0x2e22 0x0002000B
 0x2e23 0x3402
 0x2e24 0x4E28
@@ -1344,7 +1343,6 @@
 0x2f7b 0x000218BD
 0x2f7c 0x5B19
 0x2f7d 0x5B25
-0x2f7e 0x525D
 0x3021 0x4E9C
 0x3022 0x5516
 0x3023 0x5A03
@@ -4310,7 +4308,6 @@
 0x4f51 0x6E7E
 0x4f52 0x7897
 0x4f53 0x8155
-0x4f54 0x00020B9F
 0x4f55 0x5B41
 0x4f56 0x5B56
 0x4f57 0x5B7D
@@ -4352,7 +4349,6 @@
 0x4f7b 0x5DA7
 0x4f7c 0x5DB8
 0x4f7d 0x5DCB
-0x4f7e 0x541E
 0x5021 0x5F0C
 0x5022 0x4E10
 0x5023 0x4E15
@@ -7743,7 +7739,6 @@
 0x7424 0x7464
 0x7425 0x51DC
 0x7426 0x7199
-0x7427 0x5653
 0x7428 0x5DE2
 0x7429 0x5E14
 0x742a 0x5E18
@@ -8766,8 +8761,3 @@
 0x7e77 0x9F94
 0x7e78 0x9F97
 0x7e79 0x9FA2
-0x7e7a 0x59F8
-0x7e7b 0x5C5B
-0x7e7c 0x5E77
-0x7e7d 0x7626
-0x7e7e 0x7E6B
投稿者 時刻: 2 件のコメント:
ラベル: , ,

2011年7月4日月曜日

emacs 23.3 shift-jis-2004 自動認識問題

文字コードの設定はこれで完璧とか言いながら使っていたのだが、どうも shift-jis-2004 で第四水準の漢字を使用していると文字コードの自動認識に失敗する。elisp的には問題なさそうなので C のソースコードを追いかけてみました。

その結果、Cの文字コード認識の部分のバグらしいことが判明しました。SJISの文字認識の部分へ必要なコーディング・システム情報が渡されていない模様。

とりあえず簡単な一行パッチだけどこれで治ります。

diff -urN emacs-23.3.orig/src/coding.c emacs-23.3/src/coding.c
--- emacs-23.3.orig/src/coding.c 2011-01-09 02:45:14.000000000 +0900
+++ emacs-23.3/src/coding.c 2011-06-14 10:04:41.998645428 +0900
@@ -6501,6 +6501,7 @@
   {
     category = coding_priorities[i];
     this = coding_categories + category;
+    coding->id = this->id;
     if (this->id < 0)
       {
         /* No coding system of this category is defined.  */
投稿者 時刻: 1 件のコメント:
ラベル: ,

2011年7月1日金曜日

emacs 23 (ja-compatible.el)

これまでの Emacs-23 用の日本語設定を一つにまとめて以下のファイルにしています。良ければダウンロードして試してみてください。

ダウンロード: ja-compatible.el

使い方ですが、このファイルを load-path の通った場所に置いて、UTF-8 メインの場合は ~/.emacs.el に以下のように書いてみてください。
;;      for japanese
(toggle-enable-multibyte-characters 1)
(set-language-environment "Japanese")
(load "ja-compatible")

;; set default coding system
(setq default-buffer-file-coding-system 'utf-8-ja)
(set-default-coding-systems 'utf-8-ja-unix)
(set-terminal-coding-system 'utf-8-ja-unix)
(set-keyboard-coding-system 'utf-8-ja-unix)
(set-file-name-coding-system 'utf-8-ja-unix)
(set-selection-coding-system 'ctext)
(setq sendmail-coding-system 'iso-2022-jp)
EUC-JP系をメインに使用している場合には、上記の utf-8-ja-unix の所を euc-jp-compatible-unix に変更します。
投稿者 時刻: 0 件のコメント:
ラベル: , , , ,

2011年6月30日木曜日

emacs 23 (その6)

次は Emacs-23 で UTF-8 を使う場合や、文字コードの変換をする場合のマッピングの問題について考えます。マッピング問題は主に Microsoft の CP932 環境と、それ以外の環境で Unicode と JIS の間のマッピングが異なることが原因になっています。(他にも OS ごとに細々とした違いがあるのですが)。

Emacs-23 にはこの問題に対応するために japanese-ucs-jis-to-cp932-map, japanese-ucs-cp932-to-jis-map という二つの変換テーブルが定義されています。これをうまく使えば CP932 との変換表の違いを吸収することができます。

ただこの表はあくまで JIS X 0208 と Microsoft CP932 の違い定義しているようで、JIS X 0213 については考慮されておらず、そのまま使用してしまうと、JIS 第三水準にある「チルダ」が第1水準の「波ダッシュ」に変換されてしまうなど、いくつかの文字で不具合がでます。

ということで、この表も自分用に再定義することにします。ついでに GNU libc や Apple MacOS などで(過去に？)使用されていた変換表の差分も吸収しておきます。

続きを読む »
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2011年6月29日水曜日

emacs 23 (その5)

前回に unicode の合字を全部 OFF としましたが。JIS X 0213 には合字を用いないと unicode で表現できない文字が25文字ほどあります。今回はこれについての対応を考えます。

emacs 23.3 のデフォルトでは、これらの文字については JIS X 0213 から unicode(内部コード)への変換は行われていないようです。EUC-JIS-2004 などにより、これらの文字を読み込んだ場合には、unicode に変換されず外字的な扱いでそのまま内部に保管されます。逆に unicode でこれらの文字に相当する文字組み合わせがあった場合も EUC-JIS-2004 に変換することはできずセーブ不能な文字が含まれているとしてエラーにます。

これに対応するために Emacs の日本語環境には jisx0213-to-unicode, unicode-to-jisx0213 という変換テーブルがデフォルトで定義されいます。これを使えばうまくいくはず....

だったのですが....... この変換表 translate-region などでは、きちんと使用できるのですが、なぜか文字コードの translation-table に設定しても正常に動かないという問題があります。バグか仕様の変更に対応できていないか何かだと思われます。

ということで、このテーブルは個人環境で再定義してしまうことにしました。続きのところに書いておきます。

続きを読む »
投稿者 時刻: 1 件のコメント:
ラベル: , ,

2011年6月22日水曜日

emacs 23 (その1)

次は Emacs の話にしよう。

emacs-23 から内部コードが基本的にユニコードになりました。実際にはユニコードと従来の文字集合の両方を内部コードとして持って扱うことができる設計になっているようです。文字の幅も柔軟な設計になっているみたい。

さすが Emacs と言いたいところですが、少しは問題が出ます。その内容と私が取った対策などを順次説明してみようかと思います。

まずは基本通り日本語環境を設定してみる。私はほとんど ssh でログインして端末エミュレータの中で emacs -nw で使用しているので、X のフォントの設定とかは特に気にしなくても大丈夫。UTF-8 を使うとしたら基本はこんな感じかな？ 

(toggle-enable-multibyte-characters 1)
(set-language-environment "Japanese")
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-file-name-coding-system 'utf-8)
(set-selection-coding-system 'ctext)
(setq sendmail-coding-system 'iso-2022-jp)
JIS X 0213 を使うのならば 'utf-8 の所を 'euc-jis-2004 にすれば良いはず。

結果これだけでも、それなりに使えるのだけど、デフォルトでは文字幅がやっぱり変だな。他にも、いくつか気になる所がある。

ということで続く。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2011年6月19日日曜日

screen JIS X 0213/UTF-8拡張パッチの使い方

文字コードに eucjp を指定した場合には EUC-JP, EUC-JISX0213, EUC-JIS-2004 から自動判別されます。

文字コードに sjis を指定した場合には Shift_JIS, Shift_JISX0213, Shift-JIS-2004 から自動判別されます。

文字コードに iso7 を指定すると ISO-2022 7bit 方式で JIS X 0213 が使えます。

もちろん今まで通り文字コード utf8 も使えますが、基本面(BMP)以外の文字も使えるように拡張しています。utfwidth コマンドで文字幅を指定可能してください。

utfwidth normal …… Unicode の基本文字幅。
utfwidth cjk …… Unicode の CJK 文字幅。
utfwidth ja …… 日本語互換文字幅(eucjp や sjis と同じ幅になる)。

おまけで cp932 という文字コードも指定できるようにしました。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

GNU screen JIS X 0213 /UTF-8 拡張パッチ

GNU screen に JIS X 0213 の対応を追加するパッチです。その絡みで UTF-8 で基本面以外の文字も使えるように拡張しています。ついでに CP932 にも対応してみました。

何というか場当たり的な修正を繰り返してきた結果の、ぐちゃぐちゃパッチなので公開しようかどうか悩んだのですが、ついでなので公開してしまいます。(読んでて気持ちが悪くなっても責任は持てません。)

ダウンロード: screen-4.0.3.ext01.patch.gz

注意: いろいろバグが残っている気がします。ベータ版とかそんな気分で使用してください。
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2011年6月18日土曜日

jless utf-8 パッチ 使い方

特に使い方を説明する必要もないかもしれませんが、今まで通り環境変数で

JLESSCHARSET=japanese-euc

として使用すれば、入力が UTF-8 の場合も自動判別して EUC-JP に変換して表示します。同様な感じで

JLESSCHARSET=japanese-utf8

とかすれば入力の日本語文字コードを自動判別して UTF-8 に変換して表示します。
他に環境変数 JLESSUTFWIDTH という機能を追加してユニコードの文字幅を変更できるようにしました。

JLESSUTFWIDTH=normal …… ユニコードの通常文字幅
JLESSUTFWIDTH=cjk …… ユニコードのCJK字幅
JLESSUTFWIDTH=ja …… 日本語の互換文字幅(EUCやSJIと同じ幅)

mlterm や xterm で使用する場合は設定によって normal や cjk を、先の kterm パッチと併用する場合には ja を指定しておくと良いでしょう。
その他の細かい点が気になる人は README.ext.jp を読んでください。

このパッチを作成した理由ですが、UTF-8 とその他の日本語文字コードを同時に使いたい時は PAGER として lv とかを使っている人が多いのかと思います。
私はもう手が less の多機能に慣れてしまっているので、less と jless を状況によって使い分けたりしていたのですが面倒になったのでパッチを作成しました。
あと前に書いユニコードの文字幅問題があって、オリジナルの less は UTF-8 の文字幅として、ユニコードの通常文字幅のみを前提にしていという問題に対応したいといのもありました。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

jless utf-8 パッチ

jless の UTF-8 対応パッチです。jam-less とか less ISO パッチとか呼ばれているものに UTF-8 (で日本語)を処理する機能を追加するためのパッチです。less-382-iso262 パッチを当てた後に適用してください。

本家の less の方で UTF-8 対応が進んでいるので、jless の方もそのうち対応されるだろうと思って期待して待っていたのですが、しばらく更新が止まっているようなので個人用のものを公開します。これは個人的に利用する目的で作成したクイック・ハック・パッチの寄せ集めなので、あんまり綺麗な実装にはなっていませんが当面の実用には便利だと思います。

おまけで Microsoft CP932 にも簡易対応させています。

ダウンロード: less-382-iso262.ext02.patch.gz
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

kterm JIS X 0213/UTF-8 パッチ、使い方(2)

タイトルは「使い方」とか大袈裟ですが、実際は説明しなくても使い方はわかるかと思います。-km オプションもしくは Xresource や Ctrlキー＋マウス中ボタンの VT Options メニューから文字コードが選択できます。

主な特徴としては
  • euc を選択した場合は EUC-JP, EUC-JISX0213, EUC-JIS-2004 から自動判別を行います。
  • sjis を選択した場合は Shift_JIS, Shift_JISX0213, Shift_JIS-2004 から自動判別します。
  • utf-8 を選択した場合には UTF-8 に簡易対応します。対応している文字は日本語(JIS)と ISO-8859 の文字のみです。(注意: ISO-8859 の文字は多くが全角扱いされます。)
  • Unicodeとの変換表は iconv 等のものではなく内部に持っている独自のものを使用します。他の環境(特にCP932)との互換性やJISとUnicodeの unify 規準の違いを吸収するために多対一対応になっています。
  • Unicodeの文字合成には原則として対応していませんが、アイヌ語表記用の半濁点付きカナなどの合成でしか表現できない一部の JIS X 0213 の文字についてのみ合成可能になっています。
  • 今のところユニコードの文字のコピー＆ペーストには対応していません。
  • 今のとこ中国(GB)、韓国(CNS)、台湾(KSC)の文字や欧米の文字コードには未対応です。
以上、ktermについてはこんなものかな。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

kterm JIS X 0213/UTF-8 パッチ、使い方(1)

ということで前置きが随分と長くなりましたが、ユニコードの表示文字幅として
  1. normal: ユニコードの標準文字幅
  2. cjk: ユニコードのCJK文字幅
  3. ja: 日本語の過去互換文字幅
の三種類が使えると良さそうという判断のもとに、1) と 2)については xterm や mlterm などの各種端末エミュレータが使用できるので 3)を実現することを考えました。

実現したい点を整理すると
  1. 最低限日本語(JIS)の文字 と ISO-8859 がUTF8で表現できればOK、別にユニコード完全対応したいわけではない。
  2. JIS X 0213 をサポートするためにユニコードの拡張漢字面の対応も必要。
  3. 文字符号は EUC-JIS-2004, Shift_JIS-2004, ISO-2022-7bit, UTF-8 を使いたい。
  4. 日本語(JIS X 0208, 0212, 0213)の文字は全て全角幅として扱う、フォントも今のまま使いたい、文字コードごとにフォントが変るのはいや。
  5. ユニコードの文字合成とか右書きとかの機能は不要。というかプレーンテキストに変な機能はあっちゃ駄目。
  6. でも JIS X 0203 のアイヌ用のカナなどを表現するための最低限の文字合成の対応が必要。(←この辺がかなりワガママ)
であっさり kterm で SJIS を扱っているような感じで UTF-8 文字符号に簡易対応させれば実現できることに気付きました。内部表現をユニコードに変更したりせず今のま ISO-2022形式で持つことにより、文字幅やフォントをそのまま使えます。

パッチを作成して個人的にバグを取りながら使用していました。作成してから大分たちますが、他にも使いたい人がいるかもと思いたち公開することにしました。

利用文字コードを EUC/SJIS/UTF8 の間で変更しても文字幅が変化しないので、それらを併用している人には便利だと思いますので使ってみてください。
投稿者 時刻: 0 件のコメント:
ラベル: , ,

2011年6月10日金曜日

kterm JIS X 0213/UTF-8 パッチ

kterm に EUC-JIS-2004, Shift-JIS-2004, UTF-8 の対応を追加するパッチです。
今さら kterm の利用者は少ないかもしれませんが、個人的な需要があって作成しました。
詳細は別エントリーにします。

置き場所に悩んだのだけど、パッチは試しに Google Docs に置いて公開。

ダウンロード: kterm-6.2.0.ext05.patch.gz
投稿者 時刻: 0 件のコメント:
ラベル: , , ,
登録: 投稿 (Atom)