Unicode の嫌なところを触ってしまった Python

| コメント(0) | トラックバック(0)

Pythonとlibiconv, nkf, Javaのコード変換を比較した記事がありました。

ASCIIとJIS X 0201の違いに起因する円記号問題とチルダ・オーバーライン問題、それにUnicodeのFTPサイトが原因と思われる全角ダッシュの件という既知の問題が多いので目新しくないのですが (『プログラマのための文字コード技術入門』をお読みいただければわかります)、Pythonについて目新しげな話がありました。

Pythonでは他と違って、二重(白抜き)の括弧をU+FFxxの位置にあるものでなくU+29xxに割り当てているそうです。うむ。そうか、そうきたか。

JISの公式な対応表ではU+FFxxの方になっています。文字名でいうとFULLWIDTH {LEFT|RIGHT} WHITE PARENTHESISです。

ただ、ここで「なぜFULLWIDTHなのか」という疑問を持った方もいるでしょう。本来UnicodeのFULLWIDTH/HALFWIDTH云々というのは、シフトJISのように1バイトコードと2バイトコードとの間で重複符号化のある符号化方式との往復変換の救済用に設けられたものです。ところがこの括弧記号はJIS側の符号化方式(Shift_JISやEUC)で重複符号化されているものではないので、本来FULLWIDTHになるきちんとした理由はありません。にもかかわらず、UnicodeにJIS X 0213の文字を追加する作業でなぜかFULLWIDTHの方に入れてしまいました。

一般に用いられている変換表は、(多少ヘンだと思ったかもしれないにせよ)このUnicodeの作業を反映したものになっています。JIS X 0213の追補1でもそうなっています。Pythonのような判断をしたものは私はほかに見たことがありません。

Pythonがこうしたのは、強い信念のもとでの判断なのか、そうでなく何か行きがかり上そうなっただけなのか、ちょっと興味を惹かれるところではあります。

UnicodeにはのちにU+2E28, 2E29に{LEFT|RIGHT} DOUBLE PARENTHESISというのが追加されて(バージョン5.1らしい)、どうもこっちがいいんじゃないかという気もしてくるのですが、後から出してこられるのはつらい。3.2の時にあれば良かったのですが。

ちなみにこの二重の括弧は、文章や辞書において文中に入れる注記の類に用いられることのある記号です。

【追記 2017年6月7日】 JISとUnicodeの間のコード変換表はこちらから入手できます。JISの公式な定義と同等です: JIS X 0213のコード対応表

トラックバック(0)

トラックバックURL: http://yanok.net/yanok/mt-tb.cgi/633

コメントする

最近のブログ記事

Jアラート訓練メールで文字化けとのニュース
一昨日のことですが、中国・四国地方から文…
任俠の第3水準漢字
ユーモラス、と言っていいのか分かりません…
ふるさと納税で奥尻島のワインを頂きました
奥尻島は北海道の南西の方に浮かぶ島です。…
電子マネーの優先順位を考える
このブログを電子マネーとクレジットカード…
電子マネーiDの隠れたお得
iDというのはSuicaやEdyのような…

広告