Nexus 7 にソニーの Reader をインストールしてみた & 検索がしたい2012年10月11日

ソニー、電子書籍「Reader」のAndroid/PS Vita向けアプリを公開 ということで、手持ちの Android タブレット、Nexus 7 にインストールしてみました。

インストールはGoogle play にアクセスし、「インストール」を選択するだけ。SONY 製品を購入した時に作っておいた SONY の My Sony Club ID という ID で Reader Store にログインできるようなので、それを入力してログイン。

とりあえずラノベとかコミックのお試し版をダウンロードしてみましたが、特に問題なく表示できました。操作感も少し試す限りは普通。

Reader on Nexus 7

それにしても電子書籍アプリの乱立は面倒です。せめて Android アプリ内だけででも横断検索できないかとタブレット画面の上の検索文字列入力インターフェイスに適当に入力してみましたが、ひっかかったりひっかからなかったりします。

Various book read application on Nexus 7

よくわからないので検索画面の先の設定画面を調べてみたら、 「タブレット内検索」というのがありました。Kindle や標準の電子書籍アプリだと対応してるっぽいですが、他のアプリは対応していなさそうですね。Android に詳しい人に聞いてみると、どうやら Quick Search Box というのをアプリ側で実装すると良いようです。電子書籍アプリ作ってるみなさま、ぜひ対応してください。本文も!

Search inside tablet

vCard 4.0 と「フリガナ」2012年09月09日

以下、去年9月にGoogle+ で共有した内容 の転載です。少し修正してあります。

vCard についての備忘録。

パソコンの住所録や、携帯電話やスマートフォンの電話帳のデータの交換形式として vCard というのがある。

この vCard では名前、住所、電話番号や写真などをテキストデータにすることができるのだけど、 日本人にとっておなじみの振り仮名のためのフィールドが定義されていない。

しかし、それでは不便なので各社各様に拡張されてきた。

携帯電話の場合

たとえば、携帯電話では電話帳のエントリをメールに添付して送り出すといったことができるが、 この場合でも vCard が使われている。

私の携帯の場合は vCard 2.1 (*1) の SOUND フィールドが振り仮名に使われている。

BEGIN:VCARD
VERSION:2.1
N;CHARSET=SHIFT_JIS:山田葵;;;;
SOUND;X-IRMC-N;CHARSET=SHIFT_JIS:ヤマダアオイ;;;;
ADR;HOME;CHARSET=SHIFT_JIS:;北海道札幌市清田区平岡;;;;004-0889;
TEL;VOICE:0000000000
EMAIL;HOME:yamada@example.jp
END:VCARD

携帯電話では赤外線通信による電話帳データのやりとりができるが、これを規定した IrMC という規格(*2)でもvCard が参照されているようである。なお、IrMC については IrDA のメンバー、subscriber でないと参照できないので公開されてる他の文書(*3) などからの推測である。

(*1) vCard The Electronic Business Card Version 2.1 September 18, 1996. http://www.imc.org/pdi/vcard-21.txt

(*2) Infrared Mobile Communications (IrMC) Including iMelody http://irda.affiniscape.com/displaycommon.cfm?an=1&subarticlenbr=7#IrMC

(*3) MCPC TR-010 Bluetooth Phonebook Access Profile Implementation Guideline Version 1.0 January 11, 2008. http://www.mcpc-jp.org/news/pdf/TR-010PBAP_V1.0.pdf

この vCard 2.1 では SOUND フィールドに X-IRMC-N パラメーターによって、 N フィールドと同じ形式で振り仮名情報を指定している。

Bluetooth を使ったデータ交換を記述した MCPC TR-010 では vCard 3.0(*4) で定義されている SORT-STRING フィールド(*5)についても言及されている。

(*4) vCard MIME Directory Profile September 1998. http://tools.ietf.org/html/rfc2426#section-3.6.5

(*5) vCard 3.0 の SORT-STRING の定義 http://tools.ietf.org/html/rfc2426#section-3.6.5

この定義では、vCard エントリ中の FN および N を並び替えるのに使用できる ロケール、あるいは各国語固有の文字列を設定できる。

OS X の場合

携帯電話で振り仮名に使われている SOUND フィールドであるが、vCard 3.0 の定義では 実際の音声データをバイナリ化して格納することを意図したものであり、文字列で並び替えに使うことを 意図しているものではない。音声のエンコーディングは IANA のレジストリに登録されたもので あればなんでもよい。

vCard を使った別の例ととして、OS X の「アドレスブック」がある。アドレスブックのエントリは vCard で内容を書き出すことができ、OS X Lion 付属のアドレスブックだと以下のような 形式のデータになる。

BEGIN:VCARD
VERSION:3.0
N:山田;葵;;;
FN:山田 葵
X-PHONETIC-FIRST-NAME:あおい
X-PHONETIC-LAST-NAME:やまだ
EMAIL;type=INTERNET;type=HOME;type=pref:yamada@example.jp
TEL;type=HOME;type=pref:(00) 0000 0000
item1.ADR;type=HOME;type=pref:;;平岡;札幌市清田区;北海道;004-0889;日本
END:VCARD

このように X-PHONETIC-FIRST-NAME と X-PHONETIC-LAST-NAME という フィールドを独自に定義して振り仮名情報をデータ化している。

雑談から vCard 4.0

さて、ある時 (2010年の6月23日よりは前)、ある場所(*6)で雑談している時に vCard についての話題が出た。

(*6) 本郷の居酒屋の白糸だったかなと思ったら、上野の喫茶店ではないか、という突っ込みがあった。そうだったかも。

正確な内容は忘れたが、だいたいこんなことが話題になったと思う。

  • vCard だと振り仮名が「名前」にしか振れないので、組織名などで並びかえたい時は面倒だよね
  • バージョンによって定義混乱してる
  • そういや vCard の改訂の話がメーリングリストで展開しているよ

というものだった。会話の相手が vCard 関連のコードをいじってる人だったので最近感じてた 不便と一緒に振ってみたのだった。そのころ私は

  • GNOME の標準のメールソフト Evolution では振り仮名をそもそも振れない
  • Android と Gmail の連絡先の同期が振り仮名まわりの挙動が怪しい
  • Mac OS X のアドレスブック、Windows の Outlook などでそれぞれ独自に定義してる

といったことに不満を持ってて、ちょうどいろいろ調べていた。

そんな会話の後、vCard 改訂などの話題のための IETF のメーリングリストで議論が始まった(*7)。そして、彼も議論に加わった。

(*7) うへ http://twitter.com/tkusano/status/16820357779

そして議論は進み、時間は過ぎ、2011年の8月、vCard 4.0 が RFC 6350 として文書化された(*8)。

(*8) vCard Format Specification August 2011 http://tools.ietf.org/html/rfc6350

これによると、SORT-AS というパラメーターが定義され、このパラメーターがつけられている プロパティを並び替えるのに使える言語固有の文字列が指定できるようになった。

vCard 4.0 では、N および ORG プロパティにそれぞれ SORT-AS パラメーターが指定できる(MAY)と なっている。

"The SORT-AS parameter MAY be applied to this property."

これを使えばたぶんこう書けるのだろう。

BEGIN:VCARD
VERSION:4.0
FN:山田 葵
N;SORT-AS="やまだ,あおい":山田;葵;;;
ORG;SORT-AS="ワグナリア":和具菜利亜
END:VCARD

これにより、名前だけでなく、組織名でも振り仮名等で並び替えができるようになった。

あわせて読みたい

http://d.hatena.ne.jp/mowamowa/20110901/1314835604

openssl s_client で chat.facebook.com に STARTTLS で接続する2012年09月04日

先日書いた「facebook のチャットをパソコンの専用のクライアントで」で XMPP で facebook のチャットに接続することを書いたのですが、これをちょっと手動でやってみたくなりました。

SSL/TLS でつなぎたいので、openssl の s_client で STARTTLS するように指示してつないでみます。openssl の s_client コマンドは -starttls の後にプロトコルを指定すると、プロトコルごとの STARTTLS を実行し、SSL/TLS が開始されます。メールなら -startls smtp などとしますが、XMPP なので、-starttls xmpp とします。

$ openssl s_client -starttls xmpp -connect chat.facebook.com:5222 
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 400 bytes and written 122 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

あれ? SSL/TLS のハンドシェイクがうまくいってないようです。原因が知りたいので、TELNET で chat.facebook.com につないで確認します。

$ telnet chat.facebook.com 5222
(略)
クライアント→サーバー: <?xml version="1.0"?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' to='chat.facebook.com' version='1.0'>
サーバー→クライアント: <?xml version="1.0"?><stream:stream id="BC39B9EB" from="chat.facebook.com" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" xml:lang="en"><stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>X-FACEBOOK-PLATFORM</mechanism><mechanism>DIGEST-MD5</mechanism></mechanisms></stream:features>
クライアント→サーバー: </stream:stream>
サーバー→クライアント: </stream:stream>
Connection closed by foreign host.

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/> がサーバーからの応答にあるので、STARTTLS は使えるはずです (参考: RFC 3920 Section 5.1 等)。なぜ openssl が正常に動作しないのかわかんないので openssl のソースコードを見ます。

openssl.orgから 1.0.1c のソースコードを持ってきて apps/s_client.c を見てみます。

  1475 while (!strstr(mbuf, "<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'"))
  1476         {
  1477         if (strstr(mbuf, "/stream:features>"))
  1478                 goto shut;

えらく単純な文字列検索で判定しているようです。starttls 開始タグ内の xmlns 属性の値がシングルクォートで括られていることを前提としていますね。しかし chat.facebook.com の応答では xmlns="urn:ietf... のように、ダブルクォートで括られています。うーん、ちゃんと XML を parse しないといけんかねぇ、と思って、openssl の request tracker を見てみます。ありました。

#2565: More tolerant detection of XMPP starttls sequence

ここにあるパッチを見ると、strstrstrcasestr に置き換えられ、かつ、シングルクォートだけでなくダブルクォートの候補についても検索されるようになってます。

パッチをあてて、コンパイルし、再度実行します。

$ ./openssl s_client -starttls xmpp -connect chat.facebook.com:5222
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance CA-3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Palo Alto/O=Facebook, Inc./CN=chat.facebook.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance CA-3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGqDCCBZCgAwIBAgIQDmU69yuszbx5RbMUTPVxADANBgkqhkiG9w0BAQUFADBm
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSUwIwYDVQQDExxEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
(以下略)

処理としてはまだ甘いコードですが、今回の目的は成功です。

<< 2012/10 >>
01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31

RSS