インターネットなことの最近のブログ記事

今度、デジタルサイネージシステムを AIR アプリケーションで実装する話があるのだが、それに関連してユーザより

・AIR アプリ上で複数の Web 画面を同時に表示できるか？
・ローカルファイルも問題なく表示出来るか？

という二点について確認の依頼があったので試してみた。

結論から言えばどちらも問題無し。

3つの HTML コンポーネント（HTML レンダリングエンジンは WebKit）を AIR アプリ上に配置し、それぞれ、

・http://www.yahoo.co.jp/
・http://www.excite.co.jp/
・D:\X\hogehoge\test\test1.html（ローカルファイル）

にアクセスしてみたが、問題なく表示された。

ローカルファイルについては、Mac OS X 10.6 上でもテストしてみたが、

・file:///Users/hogehoge/Documents/TEST/test.html（ローカルファイル）

へのアクセスも問題なく表示された。

ま、当然の結果だが、最近はセキュリティ関係のからみで、ローカルファイルへのアクセスが凄く制限される（ややこしい手順を踏まないとアクセス出来ない）ケースが多いので、そこがちょっと心配だったのだ。

InternetExplorer での挙動なのだが、

1.CGI 経由で出力された FORM 入力画面を表示
2.値を入力して Submit
3.確認画面の表示
4.ブラウザの戻るボタンで前画面に戻る
5.FORM に入力していた値はそのまま保持されている

というのが、まあ、普通の動きだよな。

<input type="button" value="入力ページに戻る" onClick="history.go(-1)">
とか、JavaScriptで前ページに戻る場合も一緒ね。

で、この 3 と 4 の処理の間に、別のページを別タブや別ウィンドウで開いちゃうと、なんとキャッシュがクリアされて 5 の「FORM に入力していた値はそのまま保持されている」が「FORM がリセットされ何も入力されていない状態になる」のだ。

これは、InternetExplorer でだけ発生する問題で、Firefox 等では発生しない。

完全に InternetExplorer のバグだよな。他のタブやウィンドウでWebページを開いたとかどうとか、そういうことがキャッシュの保持に影響しちゃあいかんじゃろう。
別タブとか別ウィンドウでページを開いてる意味がないじゃん。

システム的に考えて、これはバグ以外の何者でもない。:-P

しかし、Microsoft やその信者達は、これは仕様と言い張るのである。馬鹿どもが。

で、この問題は、のほほんのほほんさんが「生涯一マークアップエンジニアだっ！！」というブログで書かれているように、取りあえずは出力する HTML に、

<meta content="86400" http-equiv="Expires"/>

という「明示的にキャッシュを残すようにする」meta ダグを加えてやれば解決する。

俺がわざわざ挙動の説明で「CGI 経由で出力された FORM 入力画面」と書いているのには意味があって、実は、（Apache でしか実験していないが）固定コンテンツの FORM 入力画面ではこのような問題は発生しない。
CGI や PHP で出力した画面で良く発生するのだ。

多分、HTTP ヘッダの違いによる挙動の違いなんだと思うんだな。

ということで、固定コンテンツと CGI の出力の場合でヘッダを比べてみると、

＜CGI から出力したコンテンツの場合＞
HTTP/1.1 200 OK
Date: Mon, 23 Aug 2010 01:08:16 GMT
Server: Apache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

＜固定コンテンツの場合＞
HTTP/1.1 200 OK
Date: Mon, 23 Aug 2010 01:08:52 GMT
Server: Apache
Last-Modified: Thu, 29 Jul 2010 03:53:09 GMT
Etag: "14939d-1d5b-48c7eac295340"
Accept-Ranges: bytes
Content-Length: 7515
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

むむむ？何か、それっぽい違いはねえなあ。(^^;
固定コンテンツの場合は Cache-Control ヘッダが飛んでるのかと思ったけど、そういうわけでもないような・・・

また分かんなくなっちゃった。

今回、俺は時間がなくてテスト出来なかったんだけど、CGI/PHP 経由で出力した画面の FORM の内容がクリアされてしまうという現象に遭った人は、HTML を吐く時に、

print "Content-type: text/html;charset=UTF-8\n\n";

ってしているところで、

print "Content-type: text/html;charset=UTF-8\n";
print "Cache-Control: max-age=163512\n";
print "Expires: Tue, 24 Aug 2010 22:34:03 GMT\n\n";

とか変えてみて、キャッシュのクリアがおこなわれてしまうか試してみてちょうだい。
（Tue, 24 Aug 2010 22:34:03 のところは、現在時刻に変更してね）

では、結果を待つ。（俺も機会があれば試してみるので。わざわざやるのは面倒くせえ(^^;）

ま、何にせよ、InternetExplorer がこんな糞みたいな（本当はバグの）仕様のせいで、こんなに苦労しないといけないんだけどな。

先週、お客さんのサーバの移設作業をおこなった。

新しいサーバが「セキュリティ重視」のために（俺から見たら、完全に「やり過ぎ」だと思うが(^^;）色々制限があって、単純なプログラム動かすにも苦労した、苦労した。

いや、もう、端から仕組みを作り直してしまえば簡単なんだけど、エンドユーザになるべく「サーバが変わった」ことを意識させたくなかったので。(^^;

で、そういうゴタゴタがあったので、割とすんなり動いたものはついついチェックが甘くなってしまった。
例えばメモリの制限のために、MovableType の再構築が、エントリの多いブログは Out of memory! が発生して失敗してしまう。そのため、業者に設定を変えてもらったりしてバタバタし時間を取られ、ついついすんなり表示されたブログなんかはチェックがお座なりになってしまったのだ。
「お、ちゃんと表示されてるな。ＯＫ！」って具合に。

実は、一見まともに表示されているように見えて、画像ファイルが歯抜けになってたんだよなあ。MovableType って、画像が無くなっても壊れ画像が表示されず IMG タグの ALT の内容が表示されてるんで分かりづらいんだよねえ・・・

原因は「日本語ファイル名」の画像の FTP に失敗しているためだった。

本当にバタバタしてたので、FTP でエラーが発生していることに気づかなかったようで・・・
お客さんからの指摘で初めて気づく体たらく。反省・・・

ただ、言わせて欲しい。

「インターネット上に、日本語名のファイルなんか上げんなよ！！」

いやあ、以前に比べたら、格段にインターネットのマルチコード対応は進んでて、ほとんどの場合問題になることはないのだが、それでも、未だにマルチコードに対応していないソフトウェア、ファームウェアはごまんとある。
MovableType だって、未だにファイルパスに日本語が含まれているとトラブルの原因になったりする。
つまり、今でも「インターネット上にアップするファイルは基本的にマルチバイトの名前はつけない」が基本だ。「いーや、それは違う」なんていう「知ったかぶりの馬鹿な技術者」はもう一回勉強しなおせ！基本が出来てないんじゃ、お前は！たまたま、日本語が上手く通るソフトしかお前は知らんだけじゃあ！ぼけぇ！！はぁはぁはぁ・・・

失礼しました。(^^;

ま、そういうことで、只でさえバタバタしてたのに、日本語ファイル名の FTP 問題に振り回されたのである。

結局、いつも使っている FireFTP では、旧サーバから「ファイルが存在しない」というエラーで落とせない日本語ファイル名のファイルが数個存在。（日本語ファイル名の全てが駄目なわけではない）
何度かリトライしてたら、スクリプトエラーが出て固まってしまった。(^^;

FFFTP と WinSCP は、ダウンロード（GET）出来るんだけど、ファイル名が化け化けに・・・(^^;

つーことで、最終的に、丸ごと tar で固めて新しいサーバに持って行き、そこで展開した。

たまたま、今回のサーバは ssh 接続でターミナルが使えたのでそういうことも出来たが、FTP しか出来んサーバだったらお手上げだった。

ほんま、日本語ファイル名はやめてけれ。
つーか、「日本語ファイル名でないといやだ」というヤツは、インターネット界から消えてしまってほしい。どっかへ行っちゃえ！(^^;

こういう試みは良いな。

いつも、娘を寝かしつける時間と重なるので、生で見れない（聴けない）んだけど。(^^;

RCCラジオで土曜朝の「週末ナチュラリスト」をやってる覆面DJ・一文字弥太郎が USTREAM 流してる番組だ。

ラジオ放送をそのままインターネットに乗せると法律上色々難しいことになるようだが、こうして USTREAM で専用の番組を流してくれると、俺も弥太郎さんの声をクリアに聴けて良いよ、良いよ。
部屋で「週末ナチュラリスト」聴く時はノイズだらけだからなあ。(^^;

Twitter 使って視聴者とリアルタイムなやりとりするところも実に上手くいってる。
ラジオでは時々「おっ」と思うような優等生的な発言が出ちゃうこともある弥太郎さんだが、USTREAM ではニヤリとさせるような毒を吐き、なんか、のびのびとしてるなあ。（笑）

つーことで、なかなかのお奨め。

うちは新旧の家が二軒並んでるんだが、インターネット回線は新宅の方にしか入っていない。
ちゅうことで、旧宅からもインターネット接続できるよう、新宅の窓際に無線LANルータを置くことにしたんだが、せっかくなので三年半前に購入したまま放置していた FON ルータを使ってみることにした。（FON2100E）

FON ルータの接続方法なんて、ネット上でググればすぐに色々見つかるだろうと思ったんだが、これがなかなか見つかんない。
俺の FON2100E は、FON が日本上陸した直後に１台 1,000円の記念価格で輸入モデルを販売したものなので、日本語の説明書なんか付いてないし。

結局「これは」という情報が無かったので、ええい、もう、良いや！って RT57i に接続して電源ＯＮ！・・・実は、これだけでＯＫだったのだ。

ノートパソコンで無線 LAN を探してみると、すぐに WPA2 認証の必要な MyPlace と、セキュリティ保護されていない FON_AP という２つのネットワーク（SSID）が見つかった。
まずは、試しに MyPlace に接続する。FON2100Eの裏に書かれているディフォルトの WPA2 キーを入力するとあっけなくつながった。
Web の閲覧や、Windows Update、ウイルスバスターのアップデート等を行ってみるが、問題なく使える。

さて、問題はもう一つの FON_AP ネットワークの方だ。

知らない人に簡単に説明すると、FON ルータというのは「プライベートとパブリックという２つのネットワークを同時に使えるようになっており、パブリックネットワークは（FON 会員になってパスワードを発行してもらわないといけないが）誰でも接続してインターネットを利用することが出来る」のである。
MyPlace の方はルータ個別の WPA2 キーを知ってないと利用できないのでプライベート利用のためのネットワークである。

どういうことかというと、FON 会員なら誰でも、祖生を走行中に我が家の前に車を停めて、Wi-Fi 機器（ノートパソコン等）を我が家の FON ルータ経由でインターネットに接続することが出来るのである。

・・・が、「誰でも」と書いたけど、実際には（別途有料会員もあるんだけど、それはおいといて）「自分自身も FON ルータでパブリックネットワークを公開している人」しか使うことが出来ないんだね。
「他人にインターネット環境を提供している人だけが、他人のインターネット環境を利用出来る」ということなんだわ。

で、この「俺はパブリックに利用出来るルータを公開してるぜ」という情報をどこで登録すればいいのかが全然わからない。
FON の公式サイトからルータの登録リンクをクリックしても、ルータ購入画面が表示されるだけだし・・・

まあ、いいや・・・と取りあえず FON_AP に接続し（接続はすぐされる）、Web を閲覧しようとしたらブラウザに FON 会員の ID/PW を入力する画面が開く。
ここで、公式サイトで登録した会員 ID/PW を入力すると、「お前のルータ情報を入れろや」的な画面が開く。ああ、ここでルータ登録をするのね・・・と。:-)

ここで、ルータの住所など必要事項を登録すると、これでインターネット接続が可能となるのだ。

つーわけで、考えるより産むが易し・・・だったな(^^;
これで、祖生にお越しの方で急遽インターネット接続が必要になった方は、どうぞうちの FON ルータ経由で接続しちゃってください。
但し、思ったより電波が弱いね。
旧437号線からでもギリギリ電波を捉まえるけど、実用的に使おうと思うと、うちの敷地内に入らないと厳しいかも・・・
ええと、うちの敷地内をノートパソコンや iPad 持ってうろついている人を見たら、確実にうちの嫁さんが 110番しますので、そこのところはご了承ください。（笑）

この間、Google Toolbar の設定とか色々さわってたら、Google の検索結果画面でスクリプトエラーが発生するようになった。

色々設定を触っている時だったので、いったいどの設定が問題だったのやら？
よくわからないので、「ディフォルトに戻す」ボタンを押して設定を元に戻してみたが、やっぱり状況変わらず。

俺的には「Google Toolbar 無しのブラウザは考えられない」のだが、仕方無いので Google Toolbar を非表示にしてみた。

・・・結果、変わらず。

でも、アンインストールまでするのはなあ・・・と思い、エラーが出ている該当部分を見てみると・・・

;window.mbtb1={tbs:"",docid:"81774...40646",usg:"08c4",obd:false};google.base_href='/search?q\x3dgoogle+%E3%82...\x26hl\x3dja\x26rlz\x3d1T4GZEZ_jaJP257JP258';google.sn='web';google.Toolbelt.atg=[0,7,3,4];google.Toolbelt.pbt=[[0,0],[0,0]];google.Toolbelt.pti={0:1,1:1};google.drhs=1;google.y.first.push(function(){google.Toolbelt.initializeToolElements &&google.Toolbelt.initializeToolElements();;google.sw({q:'google スクリプトエラー',nn:'ユーザー',lb:1,ls:'__DS45WDs0lX-Q7-...x3d',ls2:'__yZ65SYq...iJB292qOg\x3d'});google.ac.i(document.gs,document.gs.q,'','google スクリプトエラー','',{o:1,sw:1});google.riu={render:function(){window.setTimeout(function(){var a=document.createElement("script");a.src="/extern_js/f/CgJqYRICan...hM/bA...quc.js";(document.getElementById("xjsd")||document.body).appendChild(a);},0);

どうも、ユーザがらみのエラーのようだ。

なので、Google サービス（Gmail とか）にログインしてみると・・・

・・・エラー、出なくなったよ。(^^;

なんだ、これ？結局、Google ユーザアカウントが取れないので、なにやら関連するオブジェクトに Null が入ってて、それでエラーになっていただけなのか。

ああ、Firefox では同じ Google Toolbar の設定でもエラーにならないのにな」と思ってたんだが、Firefox の方は、起動したら必ず Gmail にログインするようになってたからか。

なんちゅうか、こう言うときは「ログインしてまへんでぇ」とか、ちゃんとしたエラー返すようにしてほしいよな。
Google にしては、何ともとぼけた出来のスクリプトじゃね。(^^;

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 で追加/修正された処理がヘッポコだったんだろうな。

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

日本語名のディレクトリ（フォルダ）への移動や、日本語名のファイルの put は問題ないんだけど（いや、まあ、実際に日本語名のファイルをアップすることなんか無いんじゃけどね）、外部のアプリにファイル名を渡す時、FireFTP はうまくいかないな。

例えば、Perl や PHP のソースだと、FTP クライアント立ち上げておいて、そこで修正したいファイルを選択し、外部エディタを起動して修正・・・なんてことをよくやる。
実際、FireFTP にもそういった外部アプリケーションを登録しておく機能はあって、ファイルを選択し、右ボタンクリックでエディタ起動ってことが出来るんだけど、パスに日本語が混ざってたら駄目じゃね。

秀丸エディタだと「カレントディレクトリの移動に失敗しました。」って出てファイル選択画面が開いちゃう。
もちろん、日本語の混ざっていないパスのファイルであれば普通に開ける。
他のアプリでも試してみたけど、「ファイルが見つかりません」等のエラーが出てやっぱ駄目だったね。

アプリへ渡すデータの多バイト対応が出来てないようだ。残念。

ほとんどのソースが、日本語の顧客名とか案件名のフォルダの下にあるからなあ。(^^;

FireFTP 使ってて、今のところ一番の問題。
まあ、致命的な問題ではないが、ちょっと不便。(^^; 対応を待つ。:-P