ブログトップ 記事一覧 ログイン 無料ブログ開設

Mac OS Xの文字コード問題に関するメモ このページをアンテナに追加 RSSフィード

2011-06-30

なぜ右矢印はiPhoneで絵文字にならないのか


  • もうすぐMacでカラー絵文字が使えるようになる。そうすると当然、Macで入力した絵文字(Unicode絵文字)をiPhoneiPadで目にすることになるだろう。というわけで、その状況を先取りし、Unicode絵文字(私用領域ではない符号位置で表現したもの)をiPad*1表示してみた結果が、前回のエントリの最後の図。iPhone/iPadでは絵文字として表示されないものが、いくつかあった。たとえば「⬆⬇➡⬅」のなかでは「➡」が、iPhoneでは絵文字にならない(下図)。

f:id:NAOI:20110630192345p:image

  • このような「絵文字として表示されない文字」は、おそらくiPhone/iPadフォント・フォールバック機構において、絵文字フォントよりも優先順位が高いフォントのグリフが表示されているのだと思われる。そこで、すべてのフォントのレパートリを調べてみた。下図では、より上に位置するフォントほど、表示の優先順位が上位となる*2

f:id:NAOI:20110630192400p:image

  • 上図において絵文字フォントは、Helvetica NeueにU+00A9を、.PhoneFallbackにU+27A1を、HKGPW3UIにU+303Dを“食われて”しまっている。かといって絵文字フォントを最優先にすると、普通の(Basic Latinの)数字(0123456789)まで絵文字として表示されてしまうので、Helvetica Neueのような欧文フォントが絵文字フォントの上位に置かれているのは、当然。不思議なのは、.PhoneFallbackとHKGPW3UIが絵文字フォントより上位に置かれていることで、ちょっと理由が思いつかない*3

*1iPhoneでも同じ。

*2:この優先順位は、「こう仮定すれば説明がつく」というだけのものであって、正しい保証はない。

*3:.PhoneFallbackなんて、すごく優先順位の低そうな名前のフォントだし。

2011-06-28

iPhone絵文字についてUnicodeの視点からまとめてみた


  • LionのAppleカラー絵文字を目前にして、その基礎となるであろうiPhone絵文字のことを知っておこうというのが、今回のテーマ。
  • いまの段階では、iPhone絵文字は主にSMS/MMSなどシフトJISの世界で使われるものだが、Unicodeで表現することもできる。iPhoneでは、文字化けを防ぐために、絵文字キーボードは絵文字が使えるシーン(シフトJISの世界)でしか出てこないようになっている。しかし、たとえばSMS/MMSで絵文字を入力した上でクリップボードにコピーし、Unicodeの世界に連れてくることは可能である。
  • Unicodeでは、iPhone絵文字は基本的に私用領域(PUA)の符号位置で表現される。それに加え、日本のケータイ絵文字がUnicodeに収録されたことを受けて、iOSはこちらの(PUAではない)符号位置もサポートしている。おそらくiOS 5では、PUAではない符号位置のほうがデフォルトになるものと思われる。
  • ほとんどのiPhone絵文字は通常の符号位置で表現できるが、1文字だけ例外がある。「109」は、Unicodeに収録されなかったため、PUAでしか表現することができない*1

f:id:NAOI:20110628140747p:image

  • iPhone絵文字はSoftBank絵文字と互換性を持っている。ただし、SoftBank絵文字には動くものが含まれるのに対して、iPhone絵文字は動かない。このため、動きによってのみ区別されるSoftBank絵文字のペアに対しては、iPhone絵文字は同じものが割り当てられている。

f:id:NAOI:20110628140813p:image

  • たとえばSoftBank絵文字には動く疑問符と動かない疑問符があるが、それらをiPhoneに送信すると、いずれも動かない疑問符となる。逆にiPhoneから動かない疑問符を送信した場合、SoftBank絵文字では「動く」疑問符となるのがおもしろい。同様にiPhoneから送信した動かない感嘆符はSoftBank絵文字では動く感嘆符となり、星はまたたく星となる*2
  • iPhoneではもちろんPUAの絵文字は絵文字として表示されるが、通常の符号位置を用いるUnicode絵文字には、iPhone絵文字以外の文字として表示されるものがある。下図は、横に並んだ文字のうち左がPUA、右がUnicode絵文字の符号位置で表現したもの*3

f:id:NAOI:20110628140932p:image

*1:豆知識な。

*2:uakiraさん(日本語練習中)にご協力いただいてテストしました。ありがとうございます!

*3Unicode絵文字による「電話のボタン」と「国旗」が正しく表示されていないのは、結合シーケンスによる絵文字がまだサポートされていないため。ただし、アプリケーションによっては表示できることもあるようだ。

2011-06-23

PRI 183についてのメモ


  • PRI 183を、ざっとチェックしたので、その内容についてメモ。PRI 183は、Adobe-Japan1のグリフを表現するための、32のIVSの追加提案(の公開レビュー)であり、IVDのUnicode 6.0対応を図るアップデートだ。
  • 下図は、新たにIVSで表現することが可能となる20文字(白地)。符号位置の右は、その字を追加したUnicodeのバージョン。括弧内はソース。UTCソースはAdobe-Japan1そのもの。CID+13763は、一度はU+5DE5には包摂されない(IVSにおいてU+5DE5を基底文字とすることはできない)と見なされた経緯があるが、結局以前の提案(PRI 98)通りの形に戻ったようだ。

f:id:NAOI:20110623171420p:image

  • 追加される32のIVSから上図の20文字を引いた残りの12のケースでは、登録済みのグリフに対して、別の(2つ目の)IVSを割り当てることになる。一度登録したIVSは変更または削除することができないので、より適切な基底文字が出てきた場合、そちらにも新たにIVSを振るしかない。
  • 下図は、より適切な基底文字(青字の符号位置)がUnicode 6.0で追加された例。JHソースは汎用電子。グレー字の符号位置は、以前からIVSの基底文字として登録されているもの。

f:id:NAOI:20110623171442p:image

  • CID+13723(上図右上の赤枠)の基底文字としては、U+2363AよりもU+2B78Eのほうが適切だと思われるが、「できるだけIVSの重複を増やさない」という方針により、U+2B78Eを基底文字としたIVSが追加されるのは、U+2B78Eの例示とドンピシャで一致するCID+13724のみとなっているようだ*2。CID+14065(上図左下の赤枠)も同様の事情。
  • 下図は、より適切な基底文字(青字の符号位置)がUnicode 5.2で追加された例。JARIBソースは、ARIB(社団法人電波産業会)外字。

f:id:NAOI:20110623171501p:image

  • 下図は、より適切な基底文字(青字の符号位置)が既存の漢字(CJK統合漢字拡張B)の中から発見された例。CID+20152は、(IVSの基底文字だけでなく)直接のマッピングもU+6AF8(櫸)だったので、小塚明朝だけではU+6AF8とU+237F1の違いがわからない。左側に大きな字でUnicode Standardの例示字形を示した。CID+20152については、今後Adobe-Japan1フォントのcmapも変更されることになるのだろうか。

f:id:NAOI:20110623171541p:image

*1:ただし、CID+20156の基底文字であるU+9FCCは、Unicode 6.1で追加される予定の(まだUnicodeに入っていない)文字。

*2Ken Lundeさん、情報ありがとうございます! http://twitter.com/#!/ken_lunde/status/83755962040721408

2011-06-17

Hanyo-Denshiのハイフン


  • UTS #37とその改訂版のドラフトは、IVDのコレクション識別子とシーケンス識別子に使用できる文字を、次のように規定している。

The identifiers for collections and sequences are character strings starting with one of 'A'..'Z', 'a'..'z', and continuing with one of 'A'..'Z', 'a'..'z', '0'..'9', '_'.

  • つまり、コレクション識別子である「Adobe-Japan1」や「Hanyo-Denshi」に含まれるハイフン(-)、Adobe-Japan1のシーケンス識別子である「CID+XXXX」に含まれるプラス記号(+)は、実はルール違反らしい。
  • Adobe-Japan1」と「CID+XXXX」については、次のバージョンでは「AdobeJapan1」「cidXXXX」に変更される予定とのこと*1。Hanyo-Denshiは、どうなのだろう。

汎用電子の正規表現


[A-Z][A-Z][0-9A-F]+S*

  • この正規表現だと、汎用電子のシーケンス識別子のうち「KS369240s」と「KS382970s」の最後の小文字のsにマッチしないのだが、これでいいのだろうか*2

*1Ken Lundeさん、情報ありがとうございます! http://twitter.com/#!/ken_lunde/status/81349166600683521 http://twitter.com/#!/ken_lunde/status/81419976807944192

*2:ところで、汎用電子のシーケンス識別子(グリフ名)における大文字のSと小文字のsの意味の違いって何だっけ?

2011-06-13

Adobe-Japan1と汎用電子のIVSは統合できるのか


  • Adobe-Japan1と汎用電子に同じグリフがある場合、IVSを共有したほうがよいのではないかという議論がある。もちろんそうすることによるメリットもあるのだが、同時にやっかいな問題も存在する。
  • 見た目や出自の点で「同じグリフ」であっても、Adobe-Japan1と汎用電子では、その包摂範囲が同じであるとは限らない。このため、一方のIVSに正規化すると、グリフの同一性が損われるおそれがある。
  • たとえば「次」のE0100(Adobe-Japan1)とE0103(汎用電子)は、いずれもJIS X 0208:1990の例示字形を参照しており、明らかに同じ字であると考えられる。しかし、Adobe-Japan1にはE0100とE0102の区別があるのに対して、汎用電子ではどちらの形もE0103に包摂されている(下図)。

f:id:NAOI:20110613152004p:image

  • このため、水色地のグリフであることを明示的に表現するための(Adobe-Japan1の)6B21 E0100というIVSに対して、「汎用電子側への正規化」を行い、6B21 E0103に変換すると、(Adobe-Japan1ではE0102で表現されるはずの)ピンク地のグリフに「化けて」表示される可能性がある。
  • 逆のケースもある。たとえば「冢」が水色地のグリフであることを明示的に表現するための(汎用電子の)51A2 E0101というIVSに対して、「Adobe-Japan1側への正規化」を行い、51A2 E0100に変換すると、(汎用電子ではE0103で表現されるはずの)ピンク地のグリフに「化けて」表示される可能性がある。

f:id:NAOI:20110613152046p:image