[linux-users:91109] Re: 外字の扱い

[Takashi SHIRAI <shirai _at_ xxxxxxxxxxxxxx>]

　しらいです。

In Message-Id <20020205195524V.stanaka _at_ ya2.so-net.ne.jp>
        TANAKA Shuichi <stanaka _at_ ya2.so-net.ne.jp>さんwrites:
> 田中＠いいだしっぺ です

> 今までのデータを修正してもらって、この手の機種依存文字をなくしてもらおう
> かと思うのですが、こういうのは一般的に妥当な要求でしょうか？図書館とか公
> 的な機関なんかではどういう取り決めになっているのでしょうか？

　大きなところでは、そもそも Unicode や JIS 等の既存のコード
体系に囚われない独自のコード体系を構築して対応していると聞き
ますね。人名用漢字なんてきりがありませんから。

　そこまでの労力が避けない場合は、既存のコード体系の中でもな
るべく対応漢字数の多いものを選ぶことになるんだと思います。
　MS-Office のように Unicode 対応のソフトを用いれば JIS より
はまだましですし、「今昔文字鏡」なんていう代物だと更に充実し
ています。
　OS level で扱いたければ、「超漢字」という選択肢でしょうか。
「超漢字 2」では「今昔文字鏡」ベースのコード体系を用いていま
したが、「超漢字 3」では独自のコード体系にして更に対応漢字を
増やしたようです。トンパ文字まで扱えるとか。
	http://www.mojikyo.gr.jp/
	http://www.chokanji.com/

＃　知合いに仏教僧がいるんだけど、お寺で使う漢字は大変らしい。
＃最近の仏教学校では授業で PC を使うこともあるそうなんだけど、
＃経典なんかは全然駄目だとか。


> しかし、何とか Linux の環境でコードをチェックしたいです

　まず、nkf をかける前に何とかする必要があります。nkf はどう
あがいても IBM 拡張漢字を何か別のものに変換してしまうので、
EUC-JP や ISO-2022-JP に変換された後では手が出せません。
　nkf をかける前の時点の ShiftJIS 状態では二つの手法がありま
す。一つは IBM 拡張漢字をゲタ化してしまうこと。もう一つは同
じ gryph を持つ NEC 選定 IBM 拡張漢字に変換してしまうことで
す。
　前者は楽ですね。

---- Cut Here ----
#include <stdio.h>

#define is_shift_jis1(c)	(((c) >= 0x81 && (c) <= 0x9f) \
				|| ((c) >= 0xe0 && (c) <= 0xfc))
#define is_shift_jis2(c)	((c) >= 0x40 && (c) <= 0xfc && (c) != 0x7f)

main()
{
	int c, r;

	r = -1;
	while ((c = fgetc(stdin)) != EOF) {
		if (r >= 0) {
			if (is_shift_jis2(c) && r < 0xf0) {
				fputc(r, stdout);
				fputc(c, stdout);
			}
			else {
				fputc(0x81, stdout);
				fputc(0xac, stdout);
			}
			r = -1;
		}
		else if (is_shift_jis1(c)) r = c;
		else {
			r = -1;
			fputc(c, stdout);
		}
	}
}
---- Cut Here ----

　後者は FDclone や Samba 日本語版で採用している手法で、たま
たま同じ gryph のコードが別の領域に存在することを利用した仕
組みです。
　IBM 拡張漢字領域は 0xfa40-0xfc4b ですが、この範囲に含まれ
る漢字と全く同じ gryph を持つ漢字が、NEC 選定 IBM 拡張漢字領
域 0xed40-0xeefc に含まれているんです。
　元々 NEC が IBM 機との互換性のために用意したものですから、
同じ gryph を持っているのは当然なんですが、こっちの領域だと
JIS X 0208 の定義域に含まれる部分しか使っていないんですね。
　なので JIS X 0208 をベースにしている EUC-JP や ISO-2022-JP
にも変換可能になります。
　尤も、コード変換出来るというだけで、そのコード用の font が
用意されているか否かは別の話です。TeraTerm 辺りで Windows か
ら見ると読めますけどね。

＃　JIS コードで見てみると、JIS X 0208 及び JIS X 0213 の 1
＃面の定義域は 0x2121-0x7e7e です。JIS X 0213 は 2 面まであ
＃るので領域は倍ですが。
＃　このうち実際に漢字が割当てられているのは、JIS X 0208 で
＃は 0x7424 (1978 では 0x737e) まで、JIS X 0213 の 1 面では
＃0x7e79 までです。
＃　NEC 選定 IBM 拡張漢字領域は 0x7921-0x7c7e に相当しますが、
＃実際にこの部分に割当てられている漢字は JIS X 0213 とも JIS
＃X 0212 とも異なります。

　因みに、正式に JIS X 0212 なり JIS X 0213 なりを EUC-JP で
表そうとすると、頭に 0x8f を冠した 3bytes コードになります。
　ShiftJIS は JIS X 0213 の subset になっているので、nkf が
この 3bytes コードに対応していれば、table を用いた変換にはな
りますが EUC-JP にすんなり変換出来る筈です。
　但し、私の知る限り EUC-JP を扱うソフトの中でこの 3bytes の
EUC-JP に対応したものは殆んどありませんので、この 3 つ目の選
択肢は余り実用的ではないでしょうね。
　一応 Samba 日本語版がこの 3bytes EUC-JP にも対応しています。

＃　更に余談になりますが、正式に JIS X 0213 を ShiftJIS で表
＃そうとすると、Shift_JISX0213 というコード体系を使うことに
＃なる筈ですが、これは MS-DOS でも MS-Windows でも Mac OS で
＃も使われていません。
＃　Shift_JISX0213 では 0x8140-0xeffc の領域に JIS X 0213 の
＃1 面を、0xf040-0xfcfc の領域に JIS X 0213 の 2 面を割当て
＃ることになっていますが、この JIS X 0213 の追加分の領域に、
＃全然関係のない NEC 選定 IBM 拡張漢字と IBM 拡張漢字とが割
＃当てられたものが、MS-Windows で使われている ShiftJIS です。


> この tr と sed を使ったスクリプトですが、文字が化けてしまいます。2バイト
> 目に0xf0〜0xfcがくるとマッチすると思います。

　あぁそうですね。余り真面目に考えていませんでした。


> Perl で shift-jis で読み込んで、この手の文字を検出するにはどうすればいい
> でしょうか？かなり大変な正規表現が必要でしょうか？

　そもそも正規表現で表そうという時点で無茶な話なんじゃないか
と思います。正規表現も万能ではありませんから、intelligent な
ものになると表現不能なこともありますよね。
　ちょっと探してみた限りでは、Jcode.pm なんて使えるんじゃな
いかと思うんですがどうでしょう？
	http://openlab.ring.gr.jp/Jcode/index-j.html

                                               しらい たかし