[Jcode5 568] Re: [kansaipm] IBM拡張文字をEUCに変換したいのですが・・・

[MORIYAMA Masayuki]

森山です。

At Thu, 15 May 2003 09:38:13 +0900,
M.Takimoto さん:
> > At Wed, 14 May 2003 18:42:34 +0900,
> > 瀧本さんが EUC とおしっゃているのは、次のどれでしょうか?
> >   
> > (0) EUC-JP   (code set 1 = JIS X 0208 / code set 3 = JIS X 0212)
> > (1) EUC-JISX0213 (code set 1/3 = JIS X 0213)
> > (2) eucJP-open  (TOG日本ベンダ協議会 (TOG / JVC) 策定)
> > (3) Windows コードページ 51932 (マイクロソフト独自の EUC)
> > 
> > ※(1)〜(3) はローマ数字を含んでいます。
> 
> うぅ・・・ (汗;
> すみません どれかわかりません。
> 自分の無知をさらけ出してますね(大汗;;;

この辺の事は、あまり良く知られていないようですね。

上記のように細かく分類したのは、Unicode 経由の文字コード変換では、
1 文字毎に変換表で変換するという事をするため、どのような文字集合
なのかという事が明確になっていないと変換できないという理由により
ます。また、自分が、どれを使っているのかという事を把握していない
と、他とのデータのやり取りで不都合が生じてしまう事になるでしょう。

> OSとしてはLinux(redhat7.2)を使ってますが、これをインストールした
> あとPerlを5.6.1にアップデートした状態。
> そこでPerlを使って 
>    Jcode::convert( \$_, 'euc' );

横道にそれますが、入力の文字コードがシフトJISと決まっているので
あれば、Jcode::convert( \$_, 'euc', 'sjis' ); というように、入力
文字コードを指定して文字コード変換するようにしましょう。

> とかやってるだけなので上の(0)〜(3)のどれに変換されているのかは、
> ちょっと理解できていません。

Jcode.pm は、1区〜94区を単純計算で、EUC に変換しているだけですか
ら、どの EUC に変換されるかは、元のエンコーディングで使用されて
いる文字集合に依存します。

瀧本さんのやりたい事は (3) の Windows コードページ 51932 へ変換
をしたいという事のようですね。

最初、IBM拡張文字を EUC へ変換したいという事でしたので、なるだけ
JIS X 0212 補助漢字や JIS X 0213 の第3水準、第4水準などの JIS の
文字のコードポイントを使うようにしたいという事かと思いましたが、
そういう事ではなかったのですね。

eucJP-open は、JIS X 0212 補助漢字にある文字は、そちらのコードポ
イントを用い、それでも対応付けできない文字は JIS X 0212 の空き領
域にマッピングするようになっていて、ユーザー定義外字にも EUC
code set 1/3 の 85区〜94区を使って対応しています。

[TOG/JVC　CDE/Motif 技術検討 WG]
http://www.opengroup.or.jp/jvc/cde/cde.html
・日本語 EUC とシフト JIS との間のコード変換規則 
・Unicodeとユーザ定義文字・ベンダ定義文字に関する問題点と解決策

> すみません あまり深く考えないで使っています。(汗

あまり深く考えないで使っていると後で痛い目に会うという事になるか
もしれませんよ。もし使うのであれば、よ〜く調べてから使うようにし
てください。
いわゆる機種依存文字の取り扱いに関しては、教科書があるとか、信頼
できる情報がきちんと整理されているという訳ではないので、それなり
に苦労すると思いますけど…

特に気をつけなればならない点としては、正式(公的)な規格と照らし合
わせてどこがどう違うのかという事を把握しておく必要があるという点
ですね。

> > Jcode.pm は、シフトJISの 95区〜120区(F040〜FCFC) を考慮されてい
> > なかったように思いますので、シフトJISの文字セットを Windows-31J
> > (Windows 標準キャラクタセット) と仮定して事前に 1区〜94区中の同
> > じ文字のコードに置き換えてから、Jcode.pm で EUC に変換したいとい
> > う事でしょうか?
> 
> ええ そういうことでいいと思います。
> 変換元はWindows上の文字ですからWindows 標準キャラクタセットですね。
> １区〜９４区で対応する文字がある文字はそれに変換して、
> １区〜９４区で対応する文字が無い文字はこの際仕方が無い、として何
> かPostgreSQLでエラーの起きないコードに変換できれば良いのです。
> ということで、単におかしなコードに変換されてしまうことを回避する
> だけではなしに、代用でいける文字はできるだけ元の情報を生かせるよ
> うに代用したいのです。

そう簡単に代用したいといいますが、それがどのよような影響を及ぼす
か把握されていますか? Notes の方で自分が出力したのと同じコードで
なければ受け付けない、もしくは受け付けても問題が起きるケースが出
てくるという事があったりしませんか?
もしそうだとすると、コードページ932 の115区〜119区を、コードペー
ジ 51932 (EUC) の (2区、)13区、89区〜92区のコードに置換したとし
て、それをコードページ932 に再変換する場合に、115区〜119区に再置
換してやらないとけいなという事になりはしませんか?

PostgreSQL は、Windows コードページ 51932 な EUC を受け付けます
か? 内部 Unicode 処理をしていたりすると、受け付けない可能性が大
です。現状で、EUC-JP でJIS の文字が定義されていないコードポイン
ト (いわゆる機種依存文字が定義されているコードポイント) も扱える
ようになっていたとしても、将来的に内部 Unicode 処理に変更になる
可能性は有りませんか? もしそうなってしまうと、コードページ 51932 
なデータを全て変換し直す必要が出てくるかもしれません。

PostgreSQL の文字コードとして Unicode を使う事が出来るのであれば、
Unicode とした方が、今後、Unicode で国際化されたソフトウェアとの
親和性が高くなるものと思われます。

また、Perl 5.8.0 の Encode モジュール等で、cp932→Unicode→
EUC-JP のような多段階の文字コード変換を行う事は、それだけでトラ
ブルの元となりますので、cp932→Unicode という一回の文字コード変
換だけで済ませることができるのなら、そのようにした方が良いでしょ
う。

cp932→Unicode→EUC-JP という変換がトラブルの元である理由は後述
します。(Encode に限らない Unicode 経由の文字コード変換一般の問
題です。)

> しかし、Windows というか Notes はよ〜わからんです。

よくわからないまま対処療法で対応していると余計に混乱する事にな
りはしませんか?

> 聞くところによるとNotesの中ではNotes独自の文字コードでデータを扱っ
> ていて、外へ（別のシステムとかへ）出す際にWindows標準キャラクタセッ
> トとかとかに変換して出しているようです。
> その際になぜかローマ数字などは拡張文字のほうに変換されてしまうら
> しいのです。

最近の国際化されているソフトウェアは大抵が内部処理の文字コード
は Unicode になっていたりします。
内部処理の文字コードが Unicode の場合、シフトJIS側で重複符号化
されている文字を元のコードポイントに戻すという事は基本的に出来ま
せんので、どれか 1 つのコードポイントを選択するという事が行われ
ています。
IBM と マイクロソフトでは、この辺の処理が違っていて、Notes は、
IBM の流儀に従っているのかもしれません。

> Notes屋には「こっちのシステムに送るときは９４区までの文字に変換し
> てちょうだい」ってお願いしてますが・・・

クライアントは Windowsでデータベース等の処理は、Linux、文字コー
ドは EUC というイバラの道を選択をするという場合は、Windows だけ
でシステムを組む場合には必要の無かった知識というものが多く要求さ
れる事になるでしょう。タダほど高いものはないという事になるかもし
れません。

Windows の流儀は次のような優先順位で文字をコードポイントを使用す
るようになっています。(内部 Unicode 処理の場合。Windows2000 では
文字列のカットアンドペーストでも、この処理が行われているようです。)

  (1) JIS にある文字は JIS のコードポイントを使う
  (2) NEC特殊文字 (13区) にある文字は 13区を使う
  (3) IBM拡張文字 (115区〜119区) にある文字は 115区〜119区を使う

  マイクロソフト サポート技術情報 - JP170559
  [PRB] SHIFT - JIS と Unicode 間の変換問題 
  http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559

で、EUC に変換する理由が、Perl 5.6.1 で、処理する際にシフトJISの
ままだと不都合があるからという理由であれば、Dan Kogai さんが強力
にプッシュしているように、Perl 5.8.0 + 最新版 Encode モジュール
という組み合わせで、EUC を使用せずに Unicode を使用する事をオス
スメいたします。

ちなみに、マイクロソフト解釈の Unicode は、一部の記号で他と互換
性の無いコードポイントを用いている為、cp932 → Unicode → EUC-JP 
という変換は、そのまま実行すべきではありませんのでご注意ください。

具体的には次の文字です。

      区-点        MS      Unicode.org  JIS/Java
  ―  01-29      U+2015      U+2015      U+2014
  〜  01-33      U+FF5E      U+301C      U+301C
  ‖  01-34      U+2225      U+2016      U+2016
  −  01-61      U+FF0D      U+2212      U+2212
  ¢  01-81      U+FFE0      U+00A2      U+00A2
  £  01-82      U+2225      U+00A3      U+00A3
  ¬  02-44      U+FFE2      U+00AC      U+00AC

  ※Java とあるのは、Java の EUC_JP,SJIS,ISO2022JP の事
    Encode の euc-jp,shiftjis,iso-2022-jp 等は、Unicode.org の解
    釈を採用 Encode の cp932 は、MS の解釈と同一

Java で、“〜” を MS932 → Unicode → EUC_JP という変換をすると、
補助漢字の TILDE に変換されてしまいます。Java のプログラマの方々
の間では、この辺の処理のノウハウがあるようですので、いろいろと調
べてみると参考になるでしょう。

ダラダラと書いてしまい、また、PostgreSQL や Notes がどのようなも
のかわかりませんが、個人的には次のような事が出来ないか考えると思
います。

・クライアントは Windows に限定する。
・PostgreSQL の文字コードを Unicode とする。
・Perl 5.8.0 + 最新の Encode を使い、Perl では Unicode で処理し、
  Unicode のまま、PostgreSQL とデータのやり取りをする。
・Notes との入出力はシフトJIS とし、Encode の cp932 で Unicode 
  との相互変換を行う。

※Unicode は、マイクロソフト解釈のものとなるので要注意。(クライ
  アントを Windows に限定するのは、この為)
※Notes に 13区のローマ数字等を渡しても大丈夫かどうか要調査
  Notes が内部 Unicode 処理していれば、13区のローマ数字を入力し
  て、出力は115区のローマ数字という事になるかもしれませんが、
  Notes の動作に支障は無いかもしれません。Notes と接続するソフト
  がシフトJIS のまま処理していたりすると、文字列比較等で問題が起
  き原因を特定するのが困難という事になりかねませんが、Notes と接
  続するソフトも内部 Unicode 処理すれば、一応整合性は保たれるも
  のと思われます。

実際に、こういう事が可能かどうかまでは調べていませんので、あらか
じめご了承ください。

で、ここまで書いて、PostgreSQL 7.3 をダウロードして、
README.mb.jp を読んでみたのですが、どうも PostgreSQL の EUC_JP 
は、eucJP-open にしている感じがしますね。PostgreSQL の EUC_JP が 
eucJP-open を前提にしていると、そこに Windows コードページ 51932 
を入力したりすると、意図しない変換が起こる危険性がありマズイです
ね。

> Notes屋には「こっちのシステムに送るときは９４区までの文字に変換し
> てちょうだい」ってお願いしてますが・・・

そのように特殊な置換をしたものを、Jcode.pm で EUC に変換すると、
Windows コードページ 51932 になってしまうでしょうから、トラブル
の元になってしまうでしょう。具体的には、eucJP-open では、EUC
code set 1 の 85区〜94区は、Windows コードページ 932 の 95区〜
104区と対応付けされています。よって、Windows コードページ 51932 
の NEC選定IBM拡張文字 (EUC code set 1 89区〜92区) がユーザー定義
外字に化けるという事が起きる可能性があります。大文字のローマ数字
等を 13区の NEC特殊文字のコードポイントに置換するという事に留め
ておけば、問題は起きないかもしれませんが…

すでに、PostgreSQL の方では、Windows 標準キャラクタセットに関し
ては、eucJP-open を使う事で対応をしているようですから、PostgreSQL 
関連の Webページやメーリングリストの過去ログをあたるなど、そちら
を調べるようにした方が良いでしょう。

しかし、eucJP-open だと、EUC code set 1 の 13区のローマ数字と、
EUC code set 3 の 83区, 84区のローマ数字の 2 種類が存在してしま
う事になのだけれども… 使用するコードポイントを統一しておかない
と文字列比較とかで問題になりそう…
Unicode で処理してしまえば、そういった問題は気にする必要が無くな
りますね。

‖ 森山 将之 (MORIYAMA, Masayuki) 
‖ E-Mail: msyk at mtg.biglobe.ne.jp