「 2012年01月 」一覧

ソフトキーボード出現時のリサイズ


Androidアプリで、キーボード表示時には、対象とする部分を表示させたまま、全体をスクロールさせたり移動させたりという挙動させているものがある。
これには、AndroidManifest.xml で  adustResize と設定だけすればいいと思っていたが、実はそれだけではないようだ。

AndroidManifest.xmlのactivityタグの属性として、「android:windowSoftInputMode=”adjustResize” 」と追加してやって、さらに、キーボード表示にはどの部分を縮小するか、という部分も必要の模様。
レイアウト設定時に、余白をこのコントロールに割り当てる、といった設定をしていると思うけど、この設定こそが、縮小されるべき点を示しているという感じだろうか。

だから、android:layout_weightの設定が存在しないと、adjustResizeの効果も出せず、うまく再レイアウトできない。
この結論に行き着くまで結構かかったので、こうしてメモってみました。


Modified UTF-7について


IMAPでのフォルダ名が見たこともないエンコードで返ってきたので調べてみました。
その結果このエンコード方式は、修正UTF-7というものらしいです。IMAP-UTF7とも表現するみたいです。

当然ながら、Javaなどの言語で標準的な解釈器が用意されているわけでもないので、自分でデコード処理を行わないと、本来の文字列を得ることはできません。

この修正UTF-7は、次のようなデータとなっています。
・ “&”以外の文字列はそのまま格納されている。
・ “&”を表現したい場合には、”&-“として格納される。
・ “&”と”-“で挟まれているデータは変則的なBase64としてエンコードされている。
・ この変則的なBase64は通常のBase64と比べ、”/” と “,” が置き換わっている点と、Base64のパディング”=”は含めない点が異なる。

さて、このような特徴があるので、”&”の出現でASCII処理モードとBASE64処理モードを切り替えて実装することで、割と楽なデコーダーを作ることができそうです。BASE64の処理モードでは、”,”を”/”に置き換えてからすでにあるBase64のデコーダーに処理させます。

感想

初めてUTF-7なんてものを知りました。いいきっかけだったと思います。
エイプリルフール時のネタで作られたRFCで、UTF-9なんてものがあったのは知っていたのですが…。
まだまだ知らないことで一杯ですが、このようなチャレンジを通して知識を広げていけたらいいなと思います。


メモリ内画像の表示(WebView)


WebViewを用いるとテキストと画像を同時に表示することが簡単にできます。
この際、画像データはすでにファイルとして端末内のどこかやURLによってどこかにすでにあることが多いです。

今回は、データはすでにメモリ上に展開されていて画像ファイルとして存在していない状況で、Android端末で表示する際のテクニックになります。

やり方

すでに画像データはバイト配列で用意できているとします。
これをBase64でエンコードし、HTMLのimgタグ内にセットします。
このとき、imgタグ内にセットする文字列は次のような形になります。

プログラム例

これで文章中に画像データが含まれ、WebViewで表示できるようになります。
WebViewで画像表示の利点は、このようにメモリ内に作った画像を表示できることと、TextViewに画像を表示するよりも手軽なことと、アニメーションGIFを使えることでしょうか。

参考

isherの日記 – WebViewで動的に画像を設定する方法」を参考にさせていただきました。


電子メールの解析 その2


前回に引き続いて第2回目。今回も調べていて、驚いた点をメモしておきます。

電子メールのアドレスの表記法の自由度

アドレス表現の自由度が高すぎて、自分でメールデータの解析器をJavaで書いていたらたまにマッチできないケースがありました。
FromやToに記述されるアドレス表現を調べてみると、次のような形式があることがわかりました。

  • “フレーズ” <ユーザー名@サーバー名>
  • ユーザー名@サーバー名(コメント)

で、実際にいくつかのメールを覗いてみるとこれだけではなく以下の形式もあることがわかりました。

  • フレーズ <ユーザー名@サーバー名>
  • <ユーザー名@サーバー名>
  • ユーザー名@サーバー名

ダブルクォートで囲まれずに送受信者の名前が記入されているケース、”<“や”>” でメールアドレスを囲んでいないケース、があります。
これだけ種類があるので、正規表現1つでなんとか~というのを諦めました。
もっとも、厳密な電子メールアドレスの正規表現はかなり複雑になります。今回電子メールアドレスとしては正しいということを想定し、単に抜き出すことをメインとするので、それなりに処理することにしました。

もう1点厄介なことがあります。
上記の記述が、複数宛先になった場合でも同様という点です。アドレスは、カンマ区切りで列挙されるという原則はそのまま適用できますが、カンマ区切りされている中で上記のケースに対応できないと駄目そうです。
またフレーズ中にカンマが出現することも考えられるので、単純なsplitという訳にもいきません。
複数宛先の時にさらに大変そうなのが、グループという概念です。コロン(:)で区切られる表示名と、セミコロン”;”までのアドレス群を処理できないとまずそうな点です。 さらに、カンマ区切りでなくセミコロン区切りで複数アドレスを列挙してくるケースもあるそうです。

上記のフレーズの部分では、アドレスの所有者の名前が記入されますが、これがエンコードされているケースもあります。これまでの処理分岐を考えると、シンプルにかけないもんだなぁと感じます。


電子メールの解析


今年最初の調査として、電子メールの解析していました。
オープンなものなので、解析と言うよりは勉強という感じですが。何しろ知識自体は数年前のものだったので、今回調べ直してみて新しい発見がいっぱいでした。
ここでは、その自分的新発見について記録しておきたいと思います。

配送情報と表示情報は実は違う

当たり前と言えば当たり前のことですが、SMTPサーバがデータの配送に使う情報と、電子メールクライアントで表示するときの宛先情報が異なるということを改めて知りました。
SMTPサーバーが参照する部分は エンベロープのヘッダ部分で、電子メールクライアントが参照して表示に使っている部分はエンベロープが持っている中身のデータのうちのメールヘッダと呼ばれる部分でした。

telnet使って、mail from や rcpt to でアドレス入力した覚えが確かにあります。これって配送用の情報だったのかと今更納得しました。

メール本文はJIS ・・・ではない

メール自身は7bitで送る必要があるためJIS(ISO-2022-JP)に変換して送らないと駄目だと考えていました。
しかし実際のところは、Content-Transfer-Encodingで 8bitを指定できたりして、Shift-JISをそのまま送ってしまうケースもあるみたいです。
また、本文自体をBASE64エンコードしてしまって、Content-Transfer-Encoding: base64 として送ってしまえたりするみたいです。
この自由度が上がった感じはすごいなと思います。知識の古さを実感してしまいました。

メールの件名も JISではない

メールヘッダの部分でも必要に応じてエンコードできるため、文字コードJISに縛られる必要はないみたいです。
=?UTF-8?B?44GK?= などというように =? ?= ではさんで好きな日本語でいけるようです。
さらには、このデータバイナリ部分はBASE64というきまりでもなく、Qエンコード(Quoted-printable)もサポートしています。
データを取り出すにはバイナリ部分をデコード して純バイナリデータ列を取得します。この際、真ん中のエンコード種別で Qエンコードなのか BASE64なのかを判定できます。この後得られたデータは先頭の文字の符号化が何であるかの識別に従ってデコードすれば、目的とする文字列が復元できます。

うまくできてるなぁと思いました。