DirectX/OpenGLプログラミングとサーバー設定なプログラマ日記
Androidアプリで、キーボード表示時には、対象とする部分を表示させたまま、全体をスクロールさせたり移動させたりという挙動させているものがある。
これには、AndroidManifest.xml で adustResize と設定だけすればいいと思っていたが、実はそれだけではないようだ。
AndroidManifest.xmlのactivityタグの属性として、「android:windowSoftInputMode=”adjustResize” 」と追加してやって、さらに、キーボード表示にはどの部分を縮小するか、という部分も必要の模様。
レイアウト設定時に、余白をこのコントロールに割り当てる、といった設定をしていると思うけど、この設定こそが、縮小されるべき点を示しているという感じだろうか。
だから、android:layout_weightの設定が存在しないと、adjustResizeの効果も出せず、うまく再レイアウトできない。
この結論に行き着くまで結構かかったので、こうしてメモってみました。
IMAPでのフォルダ名が見たこともないエンコードで返ってきたので調べてみました。
その結果このエンコード方式は、修正UTF-7というものらしいです。IMAP-UTF7とも表現するみたいです。
当然ながら、Javaなどの言語で標準的な解釈器が用意されているわけでもないので、自分でデコード処理を行わないと、本来の文字列を得ることはできません。
この修正UTF-7は、次のようなデータとなっています。
・ “&”以外の文字列はそのまま格納されている。
・ “&”を表現したい場合には、”&-“として格納される。
・ “&”と”-“で挟まれているデータは変則的なBase64としてエンコードされている。
・ この変則的なBase64は通常のBase64と比べ、”/” と “,” が置き換わっている点と、Base64のパディング”=”は含めない点が異なる。
さて、このような特徴があるので、”&”の出現でASCII処理モードとBASE64処理モードを切り替えて実装することで、割と楽なデコーダーを作ることができそうです。BASE64の処理モードでは、”,”を”/”に置き換えてからすでにあるBase64のデコーダーに処理させます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
public static String decodeModifiedUTF7( byte[] encodeBuf ) { if( encodeBuf == null ) { return null; } StringBuffer result = new StringBuffer(); int count = encodeBuf.length; for( int i = 0; i < count; ++i ) { if( encodeBuf[i] != '&' ) { result.append( (char) encodeBuf[i] ); continue; } ++i; if( encodeBuf[i] == '-' ) { // "&-"が出現したということで "&"を格納. result.append( "&" ); continue; } // "&"から始まるデータブロック. // ここから "-"が出るまでは変則なBase64で格納されている. StringBuilder buf = new StringBuilder(); boolean isBlockEnd = false; do { if( encodeBuf[i] == '-' ) { isBlockEnd = true; } else { buf.append( (char) encodeBuf[i++] ); } } while( isBlockEnd == false ); byte[] decodeBase64 = decodeModifiedUTF7asBase64( buf.toString() ); try { result.append( new String( decodeBase64, "UTF-16") ); } catch( UnsupportedEncodingException e ) { } } return result.toString(); } private static byte[] decodeModifiedUTF7asBase64( String str ) { // 修正UTF-7では ","が使われてるので戻す. String buf = str.replace( ',', '/' ); byte[] ret = null; try { int paddingCount = 4 - str.length() & 0x03; if( paddingCount == 4 ) { // 詰め物なしでデコードできる. ret = Base64.decode( buf.getBytes( "ASCII" ), Base64.DEFAULT ); } else { StringBuilder sb = new StringBuilder(buf); for( int i = 0; i < paddingCount; ++i ) { sb.append( "=" ); } ret = Base64.decode( sb.toString().getBytes( "ASCII" ), Base64.DEFAULT ); } } catch( UnsupportedEncodingException e ) { } return ret; } |
初めてUTF-7なんてものを知りました。いいきっかけだったと思います。
エイプリルフール時のネタで作られたRFCで、UTF-9なんてものがあったのは知っていたのですが…。
まだまだ知らないことで一杯ですが、このようなチャレンジを通して知識を広げていけたらいいなと思います。
WebViewを用いるとテキストと画像を同時に表示することが簡単にできます。
この際、画像データはすでにファイルとして端末内のどこかやURLによってどこかにすでにあることが多いです。
今回は、データはすでにメモリ上に展開されていて画像ファイルとして存在していない状況で、Android端末で表示する際のテクニックになります。
すでに画像データはバイト配列で用意できているとします。
これをBase64でエンコードし、HTMLのimgタグ内にセットします。
このとき、imgタグ内にセットする文字列は次のような形になります。
|
1 |
<img src="data:image/gif;base64,[ここにBASE64化されたバイナリ列] > |
|
1 2 3 4 |
byte[] imageBin; String base64 = new String( Base64.encode( imageBin, Base64.DEFAULT ) ); String html = String.format( "<img src=\"data:image/gif;base64,%s\">", base64 ); webview.loadDataWithBaseURL( "", html, "text/html", "UTF-8", "" ); |
これで文章中に画像データが含まれ、WebViewで表示できるようになります。
WebViewで画像表示の利点は、このようにメモリ内に作った画像を表示できることと、TextViewに画像を表示するよりも手軽なことと、アニメーションGIFを使えることでしょうか。
「isherの日記 – WebViewで動的に画像を設定する方法」を参考にさせていただきました。
前回に引き続いて第2回目。今回も調べていて、驚いた点をメモしておきます。
アドレス表現の自由度が高すぎて、自分でメールデータの解析器をJavaで書いていたらたまにマッチできないケースがありました。
FromやToに記述されるアドレス表現を調べてみると、次のような形式があることがわかりました。
で、実際にいくつかのメールを覗いてみるとこれだけではなく以下の形式もあることがわかりました。
ダブルクォートで囲まれずに送受信者の名前が記入されているケース、”<“や”>” でメールアドレスを囲んでいないケース、があります。
これだけ種類があるので、正規表現１つでなんとか～というのを諦めました。
もっとも、厳密な電子メールアドレスの正規表現はかなり複雑になります。今回電子メールアドレスとしては正しいということを想定し、単に抜き出すことをメインとするので、それなりに処理することにしました。
もう1点厄介なことがあります。
上記の記述が、複数宛先になった場合でも同様という点です。アドレスは、カンマ区切りで列挙されるという原則はそのまま適用できますが、カンマ区切りされている中で上記のケースに対応できないと駄目そうです。
またフレーズ中にカンマが出現することも考えられるので、単純なsplitという訳にもいきません。
複数宛先の時にさらに大変そうなのが、グループという概念です。コロン（：）で区切られる表示名と、セミコロン”；”までのアドレス群を処理できないとまずそうな点です。 さらに、カンマ区切りでなくセミコロン区切りで複数アドレスを列挙してくるケースもあるそうです。
上記のフレーズの部分では、アドレスの所有者の名前が記入されますが、これがエンコードされているケースもあります。これまでの処理分岐を考えると、シンプルにかけないもんだなぁと感じます。
今年最初の調査として、電子メールの解析していました。
オープンなものなので、解析と言うよりは勉強という感じですが。何しろ知識自体は数年前のものだったので、今回調べ直してみて新しい発見がいっぱいでした。
ここでは、その自分的新発見について記録しておきたいと思います。
当たり前と言えば当たり前のことですが、SMTPサーバがデータの配送に使う情報と、電子メールクライアントで表示するときの宛先情報が異なるということを改めて知りました。
SMTPサーバーが参照する部分は エンベロープのヘッダ部分で、電子メールクライアントが参照して表示に使っている部分はエンベロープが持っている中身のデータのうちのメールヘッダと呼ばれる部分でした。
telnet使って、mail from や rcpt to でアドレス入力した覚えが確かにあります。これって配送用の情報だったのかと今更納得しました。
メール自身は7bitで送る必要があるためJIS(ISO-2022-JP)に変換して送らないと駄目だと考えていました。
しかし実際のところは、Content-Transfer-Encodingで 8bitを指定できたりして、Shift-JISをそのまま送ってしまうケースもあるみたいです。
また、本文自体をBASE64エンコードしてしまって、Content-Transfer-Encoding: base64 として送ってしまえたりするみたいです。
この自由度が上がった感じはすごいなと思います。知識の古さを実感してしまいました。
メールヘッダの部分でも必要に応じてエンコードできるため、文字コードJISに縛られる必要はないみたいです。
=?UTF-8?B?44GK?= などというように =? ?= ではさんで好きな日本語でいけるようです。
さらには、このデータバイナリ部分はBASE64というきまりでもなく、Qエンコード(Quoted-printable)もサポートしています。
データを取り出すにはバイナリ部分をデコード して純バイナリデータ列を取得します。この際、真ん中のエンコード種別で Qエンコードなのか BASE64なのかを判定できます。この後得られたデータは先頭の文字の符号化が何であるかの識別に従ってデコードすれば、目的とする文字列が復元できます。
うまくできてるなぁと思いました。
あけましておめでとうございます。
いろいろとあった2011年も終わり、2012年がやってきました。
今年もいろいろなことを勉強＆実験して自分の力にしていけたらと思います。