Gmail + OAuth の基礎知識

概要としては

• OAuth のアクセストークンを得る
• メールアドレス (アカウント名) + アクセストークンを使って SASL XOAUTH2 フォーマットの文字列を作る
• IMAP を使い、AUTHENTICATE コマンドで上記文字列を送って認証する

という感じで、OAuth は使うけれど、WebAPI で Gmail が読めるわけではなく、最終的には普通に IMAP を喋る必要がある。

ログインまでは比較的簡単で、ドキュメントを読めばあまり問題なくできた。

日本語で検索をする

SEARCH X-GM-RAW という、Gmail のウェブ版のシンタックスでメールを検索する、という機能があるのだけれど、これを使うのにかなり難儀した。というのも、マルチバイト文字列を使う場合どうすればいいかドキュメントがなく、なんとなく適当に書いても動かない。

結論からいうと、マルチバイト文字列で検索したい場合

• IMAP の仕様上の「literal」で送る必要がある
  • literal は {bytes} をコマンド引数で指定したあと、任意のバイト列を送れる仕様 (IMAP は 7bit プロトコルだが、ここだけは 8bit が通る)
• literal の文字コードは UTF-8 でいい
• CHARSET UTF-8 をつける必要がある

でもって、最終的に該当部分の IMAP のリクエスト/レスポンスは以下のようになる

> NIC4 UID SEARCH CHARSET UTF-8 X-GM-RAW {47}
< + go ahead
> subject:アクティビティ  newer:2013/06/01
>
< * SEARCH 241354 241543 241544 242493
< NIC4 OK SEARCH completed (Success)

答えさえ知ってれば難しくはないけど、かなりハマった……

経緯

ある文字数制限のあるフィールドに、できるだけ邪魔にならないように数値を埋めこみたいと思った。任意の数字なので、特に bigint になると数字そのままでは文字数がばかにならない。そこで Unicode を使ってエンコードすることを思いついた。バイト数的には不利なのだけれど、文字数による制限であれば、Unicode 文字はたくさんあるのでもっと短くなると考えた。

使う文字セットはなんでもいいけど、ぱっと見で脳が読もうとしない、意味を理解しないものがいいと思い探していたところ、点字だと、なんと丁度 256 文字あるし、ぱっと見がかっこいいのでそれでまず Base256 というのを作った。

ちなみにこれだと '9235113611380768826' という数値 (19文字) は、'⢀⠩⢶⣦⡚⢹⣀⠺' という文字列 (8文字) にエンコードできる。

ただ、Base256 だと汎用性がなく、なおかつ Unicode の点字の文字セットを使うというのだとあまりにもニッチすぎるので、任意の文字セットを使えるようなものならまだマシかと思い BaseN を作った。

動作

初回起動時に OAuth を設定する必要がある

• 楽天カードの「売上情報」メールをパースして入力している
• 一度入力された情報は何度スクリプトを動かしても多重登録はされない
  • Zaim 上のコメントに点字符号 [⠃⢶⠒] を埋めこんで管理している (Gmail 上の UID をエンコードしたもの)
  • 同一日付内に該当メールから入力されたエントリが1件でもあれば無視するようになっている
• カテゴリ・ジャンルは自動で推測して入れてる (payment_guess.conf に定義あり)

Zaim の API のメモ

Zaim の OAuth は oob (out-of-band いわゆるクライアントアプリケーション認証) に対応していない。callback に HTTP HTTPS のURIしか受け付けないので http://oob/ とか適当に指定しておくしかない。それで認証すると http://oob/ から始まるリダクレクト先URLが画面に表示されるので、クエリパラメータを頑張ってコピペしてやる必要がある。

それと Android 版の Zaim しか使っていないと気付かないんだけど、Zaim にはアカウント(口座のほうの意味)機能があって、現金・クレカ・PASMOとかを別々に管理できる。アプリだけを使っているとアーキテクチャを理解できないのでウェブ版を設定項目を含め一通り見たほうが良い。

最初、/v2/{account,category,genre} というデフォルトのものを返すAPIを使っていたが、これらのIDだと POST /v2/home/money/payment は、成功はしつつも、バグってしまう (ウェブ版で 500 がでる)。結局、/v2/home/{account,category,genre} を使うのが正しいみたいだ。(デフォルトを返すAPIはどういうとき使うのを想定してるんだろう)

また /v2/home/money/payment に place を指定すると {"error":true,"message":"This consumer key does not have a permission for the action.","extra_message":null} が返ってきてしまう。何かが悪いっぽいけどどうしたらいいかわかってないので、ひとまず指定しないようにした。

経緯

Google Spreadsheet で家計簿をつけていたが、いかんせん意識が低くなってくるとスプレッドシートを見る気がなくなるという問題があった。また、結構頻繁に辻褄あわせをする必要があるため面倒くさい。

基本的現状の運用だと

• 現金で「消費したときに記録する」という行動の習慣化はできている
• 今月あといくら使えるか、今週あといくら使えるか、などをうまく可視化できていない

みたいな感じになっている。それらを解決するために自分でウェブアプリを書いていたんだけど、最近は Zaim の Android アプリも普通に便利に使える感じなので、自分で作るより ASP なものを使ったほうがメリットが多そうと判断した。

本当は、直接 Google App Script から Zaim に OAuth を繋ぎたかったんだけど、どうしても OAuth エラーになって進まないので、諦めて Perl で書きなおした。

Perl で書きなおす途中でGmail を読むのにハマったり、上記の通り Zaim の API で結構ハマったりした。