Phone Book

連絡先データベースはスケジューラーと異なり標準の電話帳で十分な性能を持っている。よく知られているように電脳パンツの電話帳PHONE.PDBはただのGDBであり、PHONE.GDBと名称変更するとDatabaseで普通に改造できるのであった。PHONE.PDBを改造せずに使っていた日本人なんていたのかしらん。 とはいえ、時代はSyncである。自己流の改造は怪我の元。できるだけ標準的なスキーマが求められるわけだが、今のところ我々にはあの微妙な仕様のvCardしかないのだった。

vCardの何が気に入らないの?

ふりがなの定義が統一されていない。携帯電話ではおおむね

SOUND;X-IRMC-N;CHARSET=SHIFT_JIS:セイ;メイ;ミドルネーム;プレフィクス;ポストフィクス

という感じだが、Mac OS Xアドレスブックでは

X-PHONETIC-FIRST-NAME;CHARSET=UTF-8:メイ

X-PHONETIC-LAST-NAME;CHARSET=UTF-8:セイ

で、Nokia機では

SOUND;X-IRMC-N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:セイ;メイ

という具合。

※SOUNDは本来はFN(Formatted Name=正書法での名前か)の発音を表すタグで、ふりがなとは少し違う意味のように思う。たとえば姓が佐藤さんと里江さんという二人がいたとする。ふりがなは「さとう」「さとえ」で、並び順もほぼ間違いなく辞書順で「さとう」「さとえ」だろう。でも発音は「さとー/さとお」「さとえ」だ。iCalがSOUNDでなくX-PHONETIC-*を使っているのはそれはそれで見識なのかもしれない。不便だけど。

先ほど「ふりがなの定義が統一されていない」と書いたが、「統一されていない」のではない。「ない」のだ。ふりながなんぞを用いる言語は圧倒的に少数派なので無視されているようだ。

※一応vCard 3.0(RFC 2426)からはSORT-STRINGタグでふりがなが書けるらしい。しかしふりがなと整列用文字列というのもなんか違う気がする。vCard 2.1ではSOUNDにふりがなを書くのが主流らしい。ふりがなを表記するための規格拡張はここにもあるが、まあすでに死んでいる案だろう。

運用は常に無理矢理

さて、私はiSyncを使っているのだ。iSyncはふりがななどという極東の事情にはこだわらない。iSync SyncML Guideにハッキリと記載されているように、連絡先については次のvCardプロパティしか相手にしない。sが付いているのは複数のエントリを許すという意味。

N, X-NICKNAME,

TELs, ADRs, EMAILs, URLs,

ORG, TITLE, NOTE, PHOTO,

BDAY, X-ANNIVERSARYs, X-DATEs,

X-FATHERs, X-MOTHERs, X-PARENTs, X-CHILDs, X-BROTHERs, X-SISTERs,

X-FRIENDs, X-SPOUSEs, X-ASSISTANTs, X-MANAGERs, X-NAMEs

そこで、少なくともアドレスブック側ではこのうちどれかにふりがなを書いておくしかない。日本では普通に考えてX-NICKNAMEを使うのが妥当だろう。次に、X-NICKNAMEをふりがなへ変換するためのiSyncの設定。/Applications/iSync.app/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/Nokia-E61.phoneplugin/Contents/Resources/MetaClasses.plist を改造する。

*** MetaClasses.plist.orig      2007-02-04 14:20:00.000000000 +0900

--- MetaClasses.plist   2008-07-24 06:46:59.000000000 +0900

***************

*** 212,218 ****

                                        <key>PropertyNameMapping</key>

                                        <dict>

                                                <key>X-NICKNAME</key>

!                                               <string>X-EPOCSECONDNAME</string>

                                        </dict>

                                        <key>AddCRLFAfterBase64Folding</key>

                                        <true/>

--- 212,218 ----

                                        <key>PropertyNameMapping</key>

                                        <dict>

                                                <key>X-NICKNAME</key>

!                                               <string>SOUND;X-IRMC-N</string>

                                        </dict>

                                        <key>AddCRLFAfterBase64Folding</key>

                                        <true/>

これで「SOUND;X-IRMC-N:ふりがな」というデータができるようだ。姓名の区別はないから、行き先ではきっと姓ふりがなという扱いになる。ま、SORT-STRINGとしてはそれでもよい。

日本人はお家大事なんだよ!

日本人の名前は「姓 名」と表示するに決まっている。ところが馬鹿なアドレス帳(Gmailとか)を使うと「名 姓」でしか見せてくれない。彼奴らが姓名を分割できないようにしてやれば、こうした迷惑なお節介を受けなくて済む。そこで私はアドレスブックの姓の部分に氏名を(スペースを入れないで)全部ぶちこむことに決めた。姓と名を分割する手立てを失うことに不安があるだろうか? でも考えてみれば姓名を分割する用途なんてあまりない。常にフルネームで勝負すればいいだけの話だ。

ただまあ、X-NICKNAMEに入れたふりがなには、姓名分割位置を入れて少しだけ日和っておく。いやX-NICKNAMEの日和見の真骨頂はそこではない。キモは「半角カタカナで記載」。これにはよんどころない事情があるのだがここに書いてもしかたあるまい。