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

[Takashi SHIRAI <shirai _at_ xxxxxxxxxxxxxx>]

　しらいです。

In Message-Id <20020210204552L.stanaka _at_ ya2.so-net.ne.jp>
        TANAKA Shuichi <stanaka _at_ ya2.so-net.ne.jp>さんwrites:
> > 　大きなところでは、そもそも Unicode や JIS 等の既存のコード
> > 体系に囚われない独自のコード体系を構築して対応していると聞き
> > ますね。人名用漢字なんてきりがありませんから。
> 
> 閉じた環境ではそれでもいいのですが、そのデータを院内のLAN上で web の上で
> 使いたいので、Linux で使いたいと思っている私としては是非とも何とかして欲
> しいと思っております。

　その「Linux で使いたい」の内容にもよりますよね。単に Perl
や PHP で処理したいというだけなら楽ですが、人間が読書きする
ことまで考えると font を用意する必要があります。
　その web 上での用途が、完全に client を Windows に限ってし
まっているのなら、CGI で処理する間だけ EUC-JP にして Perl 等
での文字化けを抑制し、見せる時には再度 ShiftJIS に戻すという
手法もあり得ます。但し Mac OS や UNIX が client にいると駄目
ですね。


> > 　nkf をかける前の時点の ShiftJIS 状態では二つの手法がありま
> > す。一つは IBM 拡張漢字をゲタ化してしまうこと。もう一つは同
> > じ gryph を持つ NEC 選定 IBM 拡張漢字に変換してしまうことで
> > す。
> > 　前者は楽ですね。

　と書いておいて「後者」の方法を提示するのを忘れていました。
この convert 法は「FDclone で採用している手法」とあるように、
FDclone を用いれば実現可能です。
　FDclone 2 には fdsh という shell の顔があり、この builtin
command に kconv という漢字 converter があります。

	% od -tx1 TEST.TXT
	0000000 91 90 fa 67 8d 84 0a
	0000007
	% fdsh
	$ kconv -i sjis -o euc < TEXT.TXT > CONV.TXT
	$ exit
	% od -tx1 ./CONV.TXT
	0000000 c1 f0 f9 ac b9 e4 0a
	0000007
	% 

　prompt が「$ 」になっている部分が fdsh です。元の TEST.TXT
には「草弓剪剛」という人名が書かれています。2 番目の文字はこ
こでは合字表記にしていますが IBM 拡張文字です。
　od の結果を見ると 0xfa67 という ShiftJIS code になっている
ことが確認出来ると思いますが、これを kconv で EUC-JP に変換
すると、0xf9ac になります。これは ShiftJIS で 0xed4b に相当
する文字です。
　元に戻すときには「-i」と「-o」を逆にします。この時、先の変
換とは逆に NEC 選定 IBM 拡張文字を IBM 拡張文字に置換えます
ので、完全に元と同じ文字列に変換されます。

　nkf の代わりにこの kconv を用いて変換すれば、Perl でも PHP
でも扱える普通の EUC-JP が生成されるでしょう。
　いちいち fdsh を起動するのが煩わしい場合は、-c option を用
いて一行だけ実行させる手もあります。ただの shell ですからそ
ういう用法も可能です。

	% fdsh -c 'kconv -i sjis -o euc' < TEST.TXT > CONV.TXT
	% 


> ソースまで示して下さってありがとうございました。このフィルタでチェックし
> ましたところ、65000人中60人程度で「〓」が出ました。0.1%程度なので、何と
> かしてもらうように説得しようと思います。

　拡張漢字の殆んどは異体字で、そんな見掛けの gryph に拘るの
は馬鹿げているように思えるかも知れませんが、自分の名前となる
と気になるものなんでしょうね。
　でも、それを言い出すときりがないんですよ。「篭」と「籠」は
JIS X0208-1983 と JIS C6226-1978 で逆の gryph になっています
し、同じ「辻」が PC/AT では点一つなのに PC-9801 では点二つだ
ったりもします。
　でもこれはどちらが正しいとも一概に言えない訳で、当初の漢字
コードが「意味」に重点を置いて「形」を軽視した体系であったが
ためにどうしようもない部分なのです。
　そもそも CJK 合わせて何百万もあるとされている漢字を高々 2
bytes で表そうと考えた時点で間違っているので、どこかで妥協し
ないと先には進めないでしょう。

　Unicode になって表せる漢字が増えた今でも、1 文字 7bits で
表現可能な欧米諸国からは、アジア漢字圏に対する無理解が強く残
っています。
　そんな中で、欧米が initiative を取って開発を進める OS では
なかなか漢字環境の整備は進まないことでしょう。「超漢字」が国
産 OS をベースにしているのもむべなるかなというところです。


> それから、漢字のコードについて勉強するとっかかりができました。自分なりに
> 勉強してみます。

　道は険しいと思いますが頑張って下さい。

＃　「The I18N/M17N Operation for UNIX environments」(決して
＃acronym で読んではいけません) という団体があるので、その活
＃動の一環としてまずは漢字コードの扱いに関する勉強会を企画し
＃て貰うよう働き掛けてみては？ ;-p

                                               しらい たかし