水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2010年のえび日記 > 2010年7月 > 2010年7月25日(日曜日)

2010年7月25日(日曜日)

エコポイントの申請には書類の郵送が必要

公開: 2010年7月26日1時15分頃

本日、日立ルームエアコンRAS-M22Z (www.amazon.co.jp)を購入したところ、エコポイントの申請用紙なるものをいただきました。以前、エコポイントのサイトが話題になっていた (takagi-hiromitsu.jp)ことを思い出して「サイトで申請できるやつですよね」と訊いたら、紙で申請する方法を一通り説明していただいた後で、付け足すかのように「おっしゃるようにインターネットでも申請できますので」とのご回答が。

サイトで申請した方が楽そうなのに、あんまり推奨していない気配なのは何なのだろう……と思いつつ、帰ってからエコポイントのサイト (eco-points.jp)を確認してみました。

インターネットによる申請

本サイトに設置される入力フォーム上での申請方法です。

申請後に家電エコポイントの管理、照会、ポイント交換がインターネット上で簡単に行えます。

手書きでの申請に比べエコポイントが平均で1週間程度早く発行されます

以上、家電エコポイントの申請 より

フォーム上で申請できると書いてあるように読めますね。ところが、実際に申請フォームの入り口を見るとこんなことが書かれています。

<インターネットによる申請の場合>

インターネット申請はこちら

インターネットによる申請の場合は、全ての必須事項入力後、申請書をプリントアウトしてください。

以上、家電エコポイントの申請 より

え、プリントアウト? 控えをプリントアウトする必要がある? と思いつつ、さらに読み進むと……。

■インターネット入力による郵送申請する場合

申請フォームに必要事項を入力後、プリントアウトした申請書を下記住所にお送りください

以上、家電エコポイントの申請 より

結局、申請書を郵送しないと駄目っぽいようですね。冒頭で「入力フォーム上での申請」と言っていたのはいったい……。最初から「郵送が必要」とはっきり書いておいてくれれば、無駄な時間を費やさずに済んだのですが。

※サイト滞在時間が伸びる効果を狙っているとか? :-)

そういえばずっと昔にこんな記事がありました……「エコポイント」の情報システムがわずか3週間で完成した理由 (it.nikkei.co.jp)。前に読んだときは、エコポイントの申請がWeb上でできるシステムなのかと思っていたのですが、良く読むとちゃんと書いてありますね。

次にエコポイントで交換を希望する商品のコードを入力すると、「エコポイント登録・交換申請書」が表示される。それを印刷し、保証書のコピーや領収書と一緒にエコポイント事務局に郵送すると、商品が届く仕組みだ。

3週間で完成してスゴイという話なのですが、そもそも、Web上で完結できない申請フォームは必要不可欠なものだったのでしょうか。単にQ&A集と申請書の雛形PDFを置いた静的コンテンツでも良かったのではないかとも思えます。そのほうがシンプルで分かりやすそうですし、少なくとも、Web上で完結できると誤解した利用者がさまよったりすることは起きないでしょうし。

交換商品一覧 (eco-points.jp)」の機能は必要なのかもしれませんが、これはこれで私には何が何だかさっぱり分かりませんでした。以下のように書いてあるのですが、

また、店頭利用で電球形蛍光ランプ、電球形LEDランプ、充電式ニッケル水素電池への利用は、商品価格の半分のポイントでの交換が可能です。

たとえば、4,000円分のLED電球と交換する場合、これまで4,000点必要でしたが、2,000点で交換できるようになります。

以上、交換商品一覧 より

では電球形LEDランプを見てみようかと思い、スクリプトを有効にして「電球形LEDランプ」をキーワード検索しても、「ご指定の検索条件に該当する交換商品はありませんでした。」と言われてしまいます。商品カテゴリもなんだか良く分からず、「省エネ・環境配慮製品」→「家電/AV・カメラ」→「東京都」では該当なし、「省エネ・環境配慮製品」→「キッチン/日用品雑貨」→「東京都」とすると、電球と関係なさそうなものばかりが出てきてしまいました。

あまりにも難しいので、店頭で詳しい人に訊きながら手書きで申請しようと思います。

関連する話題: Web / ユーザビリティ

URLに%22が含まれると例外が出る問題

公開: 2010年7月25日21時30分頃

IIS6でワイルドカードアプリケーションマップ使用時に、パス文字列に%22が含まれると例外が出るという問題があります。

IIS6には「ワイルドカードアプリケーションマップ」という機能があり、これを使うと、Webサーバへのアクセスを全て特定のプログラムで処理することができます。詳しくは「ワイルドカード アプリケーション マッピングをインストールする (technet.microsoft.com)」に書かれていますが、設定はとても簡単です。

bakera.jpではこの機能を使っていて、http://bakera.jp/ 以下へのリクエスト全てをASP.NETで処理するようにしています。拡張子.htmlに見えるリソースも、実はすべてASP.NETが処理しています。

この方法だと、あらゆるリクエストを特定のアプリケーションで処理できる……はずなのですが、実は問題があって、URLのクエリよりも前の部分に%22が含まれていると謎の例外が発生してしまいます。

[ArgumentException: パスに無効な文字が含まれています。]

System.IO.Path.CheckInvalidPathChars(String path) +7491109

System.IO.Path.GetExtension(String path) +19

System.ServiceModel.Activation.HttpModule.ProcessRequest(Object sender, EventArgs e) +218

System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

スタックトレースを見ると分かりますが、アプリケーションに処理が渡る前のところで例外が発生していますので、アプリケーション側ではどうしようもありません。おそらく、内部的に一度パスに対応するファイルを探していて、パス名として無効な文字が含まれていると死ぬのでしょう。ワイルドカードマッピングなのですから、ファイルを探す必要はないはずなのですが。

これ、昔から分かってはいたのですが、そもそもbakera.jp内でURL内に%22を使ったりはしていませんし、そんなリクエストもないので特に気にしていなかったのでした。が、最近、何故かURLの末尾に余計なゴミの%22をつけてくるリクエストが来るようで、イベントログに毎日例外の記録が残るようになりました。

仕方ないので対応を検討することに。とりあえず、web.configに以下のような記述を追加して……。

<customErrors defaultRedirect="/error"/>

こうしておくと、エラー時に /error?aspxerrorpath=(エラーが起きたパス) にリダイレクトされるようになります。クエリの後ろになら %22 があっても大丈夫なので、このURLはエラーになりません。そして、/error 側で %22 を除去してもう一度リダイレクトすると。

しかし、なんだか非常にまだるっこしいですね。他にもっとスマートな解決法はないものでしょうか。

※2010-07-31追記: HttpModuleを使う方法でスマートに解決しました……URLに%22が含まれても何とかする方法

関連する話題: C# / .NET / ASP.NET / IIS / hatomaru.dll

最近の日記

関わった本など