ＥＺｗｅｂのＵＰ.Ｂｒｏｗｓｅｒは、キャッシュの機能が備わっています。すなわち、一度見た文字や画像などがキャッシュに蓄えられていると、再度読み込まないようになっているのです。
これはとても優れた機能なんですが、ニュースのように新鮮さが求められる情報を提供する場合や、カウンターのようにアクセスするたびにカウントしてほしいような場合に、前に見た情報しか表示されないなど、困ることがでてきます。
キャッシュを無効にするためには、
・端末の場合は、ブラウザ履歴クリア。
・シミュレーターのブラウザメニューにある「Restart」を設定。
を行うことで、その時点でためられた履歴はクリアされますが、いちいちクライアント側に行ってもらう必要があります。
そもそも履歴をためないようにするには、ＥＺ設定のなかにある「履歴クリア設定」をＯＮにしてやればよいのですが、ただ、それでも戻る動作をしたときには、以前に読み込んだ内容が表示されてしまいます。
デッキを作るときに、文頭にくる＜ｈｄｍｌ＞のオプション“ＴＴＬ”の値を「０」に設定してやることで、クライアント側の設定に関係なくキャッシュを無効とすることができますが、それでももどる動作をしたときには表示されるようになっています。
このキャッシュの働きのため思うように動作しないものに、ＣＧＩをＰＯＳＴメソッドで実行させるケースがあります。たとえば、まずＣＧＩにＰＯＳＴメソッドで「data=material」というデータを送り込んで処理を行い、その後あらためて、別の「send=material@s9.xrea.com」というデータで同じＣＧＩを実行しようとしても、すでにＣＧＩの内容がキャッシュの中にためられているため、そのキャッシュの内容（以前に表示した「data=material」）が表示されてしまうのです。
ところが、同じ内容をＧＥＴメソッドで実行すると、うまくいきます。キャッシュが反応するかどうかはＵＲＬで判断されているため、ＵＲＬの後に「？」に続いてデータがセットされるＧＥＴメソッドなら、結果的にＵＲＬとして異なるものになるため、ＣＧＩがきちんと実行されるからです。これがＰＯＳＴデータの場合、データが別のものでも、同じデッキだとみなされてしまいます。
それならおとなしく、ＣＧＩの実行はＧＥＴメソッドで行えばいいじゃないかという話ですが、ＣＧＩに渡されるデータがＵＲＬを表示させることでバレバレになってしまい、セキュリティーの観点から考えると、あまりよろしくない場合もあると思います。
ＵＰ．ＳＤＫのキャッシュオペレーションを用いて、明示的にクリアさせる方法もありますが、キャッシュのクリアのためだけに、余分なＰｅｒｌライブラリを用意するのも考えものです。
簡単に、しかもデータを見えないようにＣＧＩへ渡してやるためには、以下のような方法でＰＯＳＴメソッドによりデータの引渡しを行う方法があります。
http://hogehoge.com/index.cgi?123456ＣＧＩファイル名のあとに「？」をつけてさらに、ユニークとなる文字列をつけてやれば、ＧＥＴメソッドで呼び出すときと同様に、毎回ＣＧＩを実行させることができます。ＰＯＳＴメソッドで行えば、データの内容も見られることもありません。
sub randnum {
$plusnum = '';
@char = ('0'..'9');
foreach(1..6){ $plusnum .= $char[int(rand(@char))]; }
}
あらかじめ、ユニークとなる文字列が生成できるサブルーチンを作っておきましょう。厳密にＵＲＬがダブッてはいけない場合でなければ、こんな感じでいいと思います。このサブルーチンが呼ばれるたびに、“$plusnum”に生成された文字列（今回は６桁の数字）が入ります。
&randnum;
print "<HDML version=3.0 markable=true>\n";
print "<CHOICE name=life>\n";
print "<CENTER>ユニークＵＲＬ\n";
print "<CE task=go dest=#data label=\"入力\">名前<TAB>[\$name]\n";
print "<CE task=go dest=index.cgi?$plusnum METHOD=POST POSTDATA=data=\$data>送信\n";
print "</CHOICE>\n";
print "<ENTRY name=data key=data>\n";
print "<ACTION type=accept task=go dest=#life>\n";
print "名前\n";
print "</ENTRY>\n";
print "</HDML>\n";
ＨＤＭＬファイルを出力するまえに、サブルーチンをあらかじめ実行しておきます。あとはＵＲＬのうしろに“$plusnum”をつけてやれば、ユニークなＵＲＬのできあがりです。これで、キャッシュの内容を返すことなく、毎回サーバでＣＧＩを実行させることができます。
materialは、電話を受けた。
Eメールとスカイメールって、何が違うんですか？
materialは、答えた。
Eメール スカイメール 送受信できる相手 Eメールがやりとりできるものすべて Jフォン、ツーカーのみ 月額使用料 無料（ツーカーは月額100円） 無料 使用文字数 送信時 半角128文字（全角64文字） 半角128文字（全角64文字） 受信時 半角384文字（全角192文字） 半角128文字（全角64文字）
materialは、思った。
パソコンなどですでにEメールをされている方なら、Eメールの何たるやを語らずともご理解いただけるんだけれども、ケータイやピッチでしかメールの送受信をしたことがなかったら、Cメール、Pメールなんかとネーミングも似ているし、何がなんだか分かりにくいだろうね。そういえば、Eメールを申し込めば不特定多数の見知らぬ人とメル友になれると信じていた勘違いさんがいたなぁ(^^;)。
materialは、電話を受けた。
スカイメールを１回しか送っていないのに、相手に何回も届くことがあるんやけど、なんで？
materialは、答えた。
送信元を「Ａ」、メッセージセンターを「Ｂ」、送信先を「Ｃ」としましょう。
ケータイから送信されたメッセージは必ず、「Ｂ」でいったん預かることになるのですが、その際に次のようなやりとりがなされます。
Ａ：これから、メッセージ送るでー、ええかー？
Ｂ：ええよー、送って！
Ａ：あて先はここや。
Ｂ：はいよ！
Ａ：メッセージの内容は、これこれや。
Ｂ：はいよ！
Ａ：よっしゃ、終わったで。
Ｂ：そうか！
Ａ：ちゃんと送ったってや。
Ｂ：ＯＫ！預かったで。
関西の事業者では、このように大阪弁でのやりとりが・・・(・_*)＼ペチ！
冗談はさておき、この一連の流れの初期の段階で途切れた場合、「送信できません」「送信失敗しました」という表示が、ある程度進んだが最後までやりとりが完了しなかった場合、「配信（送達）確認をしてください」という表示が、完全にプロセスを終了できた場合は、「送信完了しました」という表示がでます。
ちょっとあいまいなのが、２つ目のある程度進んだ場合だと思います。例えば、「Ｂ」は最後の“ＯＫ！預かったで”という信号をだして流れを終了させたにもかかわらず、何らかの事情（電波状態など）でその信号が「Ａ」に届かなかった場合などが考えられますが、「Ａ」はそういった場合送信できたかどうかを確認したほうがいいよ、という表示をだすということです。
「Ｂ」で預かることができたメッセージは、「Ｃ」がエリア内で待機状態にあれば、配信プロセスに入ります。
Ｂ：これから、メッセージ送るでー、ええかー？
Ｃ：ええよー、送って！
Ｂ：送信元はここや。
Ｃ：はいよ！
Ｂ：メッセージの内容は、これこれや。
Ｃ：はいよ！
Ｂ：よっしゃ、終わったで。
Ｃ：そうか！
Ｂ：それじゃ、あとはヨロシク。
Ｃ：ＯＫ！ありがとう。
ほとんど上のコピーですが(^^;)。
配信できる、できないという事情も送信時とほぼ同じで、滞りなく配信できた場合はそれで終了、失敗した場合は再度リトライをかけます。
あいまいと表現した事情もやはり同じで、「Ｃ」ではすでに完了したとされているプロセスが、「Ｂ」では失敗したかも、と認識されることがあります。こういう場合、「Ｂ」は律儀にも何とか「Ｃ」にメッセージを受け取ってもらいたい一心で、キッチリ完了するまでリトライし続けます。「Ｃ」において、リトライそれぞれが完了し続けると、同じメッセージが何度も届くという不思議な現象としてあらわれます。
materialは、思った。
この仕様はまったく有り難いくらいで、そういったことが頻発するのならともかく、信頼性の確保という一点においては最高ですね。Ｊフォンでは、スカイウォーカーを拡張したＪスカイサービスを、ツーカーホンでは、スカイメッセージとは別にＫＤＤＩグループとしてＥＺｗｅｂを採用しているけれど、総合的な使い勝手では圧倒的にＪスカイがいいです！ ＥＺｗｅｂの拡張規格として「ＥＺｗｅｂ２０００」というものが策定されているようだけど、目移りするような環境でいろんなサービスが拮抗し合うのは、利用する側としてとてもうれしいことです。
ＥＺｗｅｂ対応機種以外では意味が無いダウンロードコンテンツを作ったり、ＵＰ．Ｓｉｍｕｒａｔｏｒを使ってソースを覗かれたくないような場合、ＥＺｗｅｂ対応の端末以外からのアクセスを禁止したいなと思うことがあります。
ＥＺｗｅｂ対応機種からアクセスしてきかどうかは、環境変数の'HTTP_USER_AGENT'に「UP.Browser」という文字列があるかどうかで判断できます。
あとは、ＵＰ．Ｓｉｍｕｒａｔｏｒからのアクセスかどうかの判定ですが、サブスクライバＩＤが確認できる'HTTP_X_UP_SUBNO'を見ることで判断します。ＵＰ．Ｓｉｍｕｒａｔｏｒからのアクセスであれば、パソコンのコンピュータ名を返しますが、ＥＺｗｅｂ対応機種は「端末固有の数字14桁_UPリンクサーバ」という決まった形式で返します。
以上を踏まえて、スクリプトを書いてみましょう。
$flag = 'NOEZ';
$u_agent = $ENV{'HTTP_USER_AGENT'};
if($u_agent =~ /UP\.Browser/){
$u_subno = $ENV{'HTTP_X_UP_SUBNO'};
if($u_subno =~ /^\d{14}_[a-z][0-9a-z]\.[a-z\.]{5,7}\.ne\.jp$/){
$flag = 'EZ';
}
}
これで「$flag」が'EZ'であれば、ＥＺｗｅｂ対応の端末からアクセスされていると判断できます。
materialは、電話を受けた。
マイデッキ・エディターでホームページを作って、プロバイダのサーバーにアップロードしようと思うんだけど、うちのプロバイダ、HDMLに対応してないみたいなんだよね。これって、何とかならないの？
materialは、答えた。
そうですね、その状態でしたら、ただアップロードしていただいても、エラーが出て閲覧できませんね。でも、もしお客様ご利用のプロバイダが、UNIX系のサーバーで運用されていれば、お客様の側で対応させることができる可能性があります。以下の１文をテキスト形式で記述し、ファイル名「.htaccess」としてFTPで転送してみてください。
AddType text/x-hdml;charset=Shift_JIS hdml
「.htaccess」ファイルは、サーバーの動作をお客様のご希望に合わせて設定したい時に使用するもので、HDML形式のように、初期状態では設定されていないMIMEタイプを追加したりする事が出来ます。一定の書式に従って設定したい内容を記述して、作成したファイルに「.htaccess」という名前を付けてサーバーに転送すると、 転送したディレクトリとそのディレクトリの中にあるすべてのディレクトリ・ファイルに記述した内容が適用されます。結局、Webページを置く最上層のディレクトリにのみ、送っていただくということですね。
ただし、プロバイダによっては、ユーザー側に設定権限がない場合もあり得ますので、HDML対応プロバイダ以外の利用を希望されるのでしたら、事前にお問い合わせいただいた方がいいと思います。
materialは、思った。
そうなのだ、HDMLへ対応させること自体、とても簡単なことなのだ。今後、電話としてではなく、情報インフラとしてのケータイとして、爆発的なシェア拡大が見込まれる世界での記述言語タイプなのだから、プロバイダもそういうところに敏感であってもらいたいですね。