インターネットなこと: 2010年5月アーカイブ

POP3 でメールを受信し、添付で送られてきた画像データを抜き出すスクリプトを Perl で書いた。

最初は受信してきたメールを MIME::Parser で解析して添付ファイルを抽出しようと思ってたんだけど、日本語ファイル名が含まれていた時に何か問題あるという話を見つけたので、十年くらい前に自作した Parser を使うことにした。

ちゃんと RFC 見て書いたコードじゃないけど、何年か業務システムで使っていた間に、「OutlookExpress のメールは、Quoted-Printable エンコードなのかよ！」とか、「EdMax の boundary 文字列には、エスケープしないといけない特殊記号がバンバン混ざってるのね」とか、そんなメールソフト毎の微妙なフォーマットの違いや、添付ファイルが多段に展開する HTML メールとか、色々なことに実践的に対応してきたので、大概のメールは問題なく処理出来るようになってるからな・・・と思ってたんだけど・・・

iPhone のメールはまた独特じゃねえ(^^;
結局今回は iPhone 対応が必要じゃった。

iPhone メールで送られてきたメールが他のメールソフトのものと違うところ。

まず一つめ。添付ファイルのヘッダの順番が全然違う。
ほとんどのメールソフトが添付ファイルのスタートを表す boundary 文字列のあと、Content-Type ヘッダが来るんだけど、iPhone（つーか、Apple 製のメールソフトは皆そうなん？）の場合は Content-Disposition ヘッダが来るんだな。

次に、Content-Disposition ヘッダの filename の記述が独特じゃねえ。
普通は（日本語ファイル名なら）
filename="=?ISO-2022-JP?B?GyRCJF4kJCReJCQbKEIxLmpwZw==?="
という形なんだけど、iPhone メールは
filename*=iso-2022-jp''%1B%24B%3CL%3F%3F%1B%28B.jpg
てな形で来るな。
MIME B エンコードじゃなく、URL エンコードしたファイル名が来るんだな。
filename と = の間に * があるのも謎だし。

いや、どっちも致命的な問題じゃなくて、添付ファイルの抜き出しそのものには影響ないんだけど、Content-Type ヘッダをヘッダ情報をログに吐き出す開始トリガーにしてたり、オリジナルのファイル名がセットされているかどうかを正常にヘッダ情報が抜き出せたかの判断材料にしてたりしたので（filename の後ろに * が付いている形は想定してなかったので、オリジナルのファイル名が抜けなかったのだ）、ちょっと変な動きをしてしまった。

まあ、生のメールデータを見れば問題点はすぐわかるので、ささっと対応したが。

こんなこと書くと、「RFC ちゃんと読んでコード書けば問題ないじゃろ」と知ったかぶりに指摘する人がいるんだが、例えば日本のケータイのメールアドレスなんて（天下の NTT DoCoMo からして）RFC なんか無視してるし、実際のデータを解析して対応しないとどうしようもない部分があるんだぜ。

まあ、興味がある人は、色々なメールソフトから送った生のメールデータを見てみると色々楽しいよ。
全てのソフトのデータを問題なく抽出するにはどんな正規表現を書けばいいかとか、パズルみたいで楽しいよお。（笑）

livedoor の「お天気Webサービス」の XML データを元に、天気と気温を表示させる AIR アプリを作っているのだが、時々気温データが来なくなっちゃうんだね。

例えば、気温データは下記のような XML で取得出来る。
（この例は、最高気温のみセットされているパターン）

  <temperature>
    <max>
      <celsius>21</celsius>
      <fahrenheit>69.8</fahrenheit>
    </max>
    <min>
      <celsius />
      <fahrenheit />
    </min>
  </temperature>

これが、場合によっては最高気温も最低気温もセットされていない、

 <temperature>
   <max>
     <celsius />
     <fahrenheit />
   </max>
   <min>
     <celsius />
     <fahrenheit />
   </min>
 </temperature>

こんな感じで来たりする。（もちろん、両方の気温がセットされている場合もある）

もちろん、フィードしている XML データに載せていないってだけではなく、livedoor 自身の天気予報ページでもこの XML どおりの内容になっているので、本当にセット出来ない事情があるのだろう。

（例）
http://weather.livedoor.com/area/34/90.html

んで、livedoor はこのサービスの仕様に関する個別の問い合わせは受け付けていないので、その辺の正確な仕様や事情はよくわからん。

まあ、来ないものは仕方ないので、そういうもんだということで使うしかないんだけど、もう少し状況がわかると安心なんだけどな。
早朝は両方入ってて、途中で最低気温がなくなり、やがて両方の気温データが来なくなる・・・という感じかなあとは思うのだが、まだ調査しきれていない。

なんかご存じの識者の方がいらっしゃれば、是非ご教示ください。:-)

ほんと、まいっちゃうなあ。

去年の秋に製造が終わってるのに、未だにエンドユーザが検収やってる（検収終わらないと金払わないとか言いながら、バグ報告と一緒に要望上げてくる質の悪さ(--;）という最悪の Web システムがあるのだが(^^;、今日になってまた「この間までちゃんと表示されていた画面が崩れて表示されるようになった。そっちで何かやっただろう！？」と言いがかりが。(^^;

調べてみると、<td></td>タグ間で</form>を打ってるところで表示が崩れてる。

う～む。</form>タグを外に出せば簡単に直るけど、「このプログラム及びHTMLテンプレートの最終更新日は 2009/9 である（つまり、うちでは何もやってない）」「Firefox3.6 では正常に表示され、崩れているのは InternetExplorer8 のみである」「スタイルシートは元請けの会社で作ってて、俺の与り知らない部分である」ということで、「そっちでスタイルシートを修正してください」と元請けに返したのだが、結局関連するスタイル指定がどの部分かよくわからないということもあって、今回はHTMLテンプレートを修正した。

やれやれ。(^^;

何か、InternetExplorer の CSS の適用って独特・・・つーか、変！だよなあ。
</form>タグなんてどこに打ってあろうが本来表示には「まったく影響ない」ものでしょうが。つーか、「影響しちゃいかん」でしょうが。
何か、スタイルシートを適用したら、改行ひとつで表示が乱れたりするようになったり・・・

今回、ついこの間まで表示の乱れはなかったらしいので、IE8 の update で追加/修正された処理がヘッポコだったんだろうな。

ま、それより、早く検収終わらせんかい！こんなの（ブラウザの仕様変更による障害）、本来なら有償対応やで！とめらめらと今も怒りの炎を燃やしているところであります。