日々の破片

_ BKを1つ見つけた

会員登録とかで、メールにURLを埋め込んで送るってのがある。で、そのURLをクリックすることで登録が完了するとか。

こういうURLを作る時、改行は避けられたら避けたほうが良いだろうけど、amzon.toくらいに金をかけられればともかく、短縮URLは使わないほうが良いだろうね（そういうの気にしない人ばっかりだというのは別の話だ）。

でも、ここでのBKはそういうのではない。

実は2つのQueryパラメータを取るサービスでやってしまったのだった。

具体的にはパラメータが2つある（後悔先に立たないが2つ使うように作ってしまったのだった）。1つは受付番号で、もう1つは登録IDだ。

学んだことは次の3つ。

1) できるだけ、QueryStringを使わず、URL埋め込みを利用する。

たとえば、受付番号が32001、登録IDのハッシュが1111e53dというパラメータを与えたいとする場合、http://example.com/fooservice/confirm/32001/1111e53d みたいにする。

2) でも、諸般の事情でそうできなかった場合には、登録IDを先にする。http://example.com/fooservice/confirm?regid=1111e53d&qid=32001 (受付番号をキューされた番号としてqidとしてみた）。

3) でも、それが無理なら、パラメータ名の先頭は「reg」では無いものにする。http://example.com/fooservice/confirm?qid=32001&torokuid=1111e53d

なぜか？ それは、どこかに、「&reg」（末尾の「;」が無い点に注意）を1トークンとして「®」（つまり®）に置き換える腐ったメーラか、または腐ったWebメーラか、または腐ったブラウザーがあるからだ。

具体的に何が起きるかは、I・O DATA サポート&サービス Q&A にある。

テキスト形式に変更してもアクセスができない場合、URL内の「○で囲まれたRのマーク(著作権マーク)」を削除して代わりに

&regと入力してアクセスをお試しください。

「著作権」じゃなくて「登録商標」の間違いだな

きっと、IOデータの人も、URLに、&regid=12345 とかを埋め込んだのだろうなぁ。

同じことで、「copy」で始まるパラメータを2番目以降（つまり&の後ろ）に持ってこないほうが良い。ampやlt、gt、quot みなきっと同じだ。でもregは、罠だなぁ。