2006-10-27

Encode::EUCJPMSのバージョンが上がってるじゃん。

　メーリングリストを見ていたら、ミラクルリナックスの森山さんからレガシーエンコーディングプロジェクトの報告が。ざっとながめると

※ Encode::EUCJPMS で CP50220 と CP50221 が利用できるため、ISO-2022-JP-MS ではなく、そちらの方を使用するのが望ましいと思われます。

――という記述がある。

　あれ？　と思ってCPANのEncode::EUCJPMSを見ると、８月にCP5022x対応版が上がってるじゃないですか。知らなかった……。

　というわけで前に書いた

　Encode::CP5022x相当が実装されれば、Classic部分を削除してCPANに登録しよう……。Jcode::CP932 - 0.04

――が、実装可能になったのでぼちぼち作業しようかと思うのですが、何かご意見がありましたらよろしくお願いいたします*1。

　それはそれとして。

　僕がレガシーエンコーディングプロジェクトに期待していたのは主に

　森山さんは「JIS系とCP932系の相互変換は出来ないと考えておいた方が無難」と書かれていますが、問題が生じる可能性があることを認識のうえで――例えば「相互変換」ではなくどちらかに寄せる対応になると認識したうえで正規化する変換はあったほうが良いと思うのです。

　なぜならUTF-8（Unicode）で流通しているテキストをレガシーエンコーディングに変換する必要がまだあって、そのUnicodeなテキストがCP932系なのかJIS系なのかは判別することができないからです。そういう時はなんらかのポリシー（CP932系にするかJIS系にするか）で正規化するようにしないと困ったことになるような気がします。

　確かAmazonのデータはCP932系らしく「～」はU+FF5Eで送られてきたと思うのですが*1、本当にCP932系なのであればそれをJIS系のエンコードに変換すると問題が生じたりするはずですし。そういう時に変換できないと困るんじゃないかと思うのです。とりあえずレガシーエンコーディングプロジェクトの成果待ち

――だったのですが、これへの対策は特にないんですね。うーん、どうしたものか。

　とりあえず

   文字　SJIS     EUC      JIS       Unicode   Unicode での
         コード値 コード値 コード値  コード値  文字の名前
   ----- -------- -------- --------- --------  ----------------------
    ―    0x815C   0xA1BD   0x213D    U+2015    HORIZONTAL BAR
    ～    0x8160   0xA1C1   0x2141    U+FF5E    FULLWIDTH TILDE
    ∥    0x8161   0xA1C2   0x2142    U+2225    PARALLELE TO
    －    0x817C   0xA1DD   0x215D    U+FF0D    FULLWIDTH HYPHEN-MINUS
    ￠    0x8191   0xA1F1   0x2171    U+FFE0    FULLWIDTH CENT SIGN
    ￡    0x8192   0xA1F2   0x2172    U+FFE1    FULLWIDTH POUND SIGN
    ￢    0x81CA   0xA2CC   0x224C    U+FFE2    FULLWIDTH NOT SIGN

だけ正規化すれば問題なし？

はてなグループのファイル共有って、有料オプションを外したら消えちゃうorアクセスできなくなっちゃうの？

　もしそうなのならちゃんと書いておいてくださいよ……＞g:hatena:id:hatenagroup

　ファイルのアップはできなくてもダウンロードは継続されるものだとずっと思ってました。

　さて、どうしたものか。

*1：たとえばJcode.pmで対応しちゃうよ、とか。ハードコーディングされてる部分を触らないといけないのがちょっと嫌なので……。