web-dev-qa-db-ja.com

一部のメールクライアントは％2b文字列を自動的にurldecodeしますか？

ウェブサイトにメールアドレスの確認プロセスがあります。サイトは最初に適切なキーを文字列として生成します

mykey

次に、そのキーを一連のバイトとしてエンコードします

&$dac~ʌ����!

次に、base64がそのバイトの束をエンコードします

JiRkYWN+yoyIhIQ==

このキーはHTMLメールに配置されるURLのクエリ文字列値として与えられるため、最初にURLEncodeを実行し、次に結果をHTMLEncodeする必要があります（ここではHTMLEncodingの効果はありませんが、私はできます）例のやり直しに煩わされる）

JiRkYWN%2ByoyIhIQ%3D%3D

これは、次のような電子メールの一部として送信されるHTMLに埋め込まれます。

click <a href="http://myapp/verify?key=JiRkYWN%2ByoyIhIQ%3D%3D">here</a>. 
Or paste <b>http://myapp/verify?key=JiRkYWN%2ByoyIhIQ%3D%3D</b> into your browser.

受信ユーザーがリンクをクリックすると、サイトはリクエストを受信し、クエリ文字列の 'key'パラメーターの値を抽出し、base64がそれをデコードし、解読し、サイトロジックの観点から適切な処理を行います。

ただしクリックが無効であると報告するユーザーがいる場合があります。そのようなユーザーの1人が、送信された電子メールを転送し、検査時にHTMLが変換されました（上記の例に関して言えば）

click <a href="http://myapp/verify?key=JiRkYWN+yoyIhIQ%3D%3D">here</a>
Or paste <b>http://myapp/verify?key=JiRkYWN+yoyIhIQ%3D%3D</b> into your browser.

つまり、％2B文字列は-エンコードされた他の文字列はどれもプラスに変換されていません。

key=JiRkYWN%2ByoyIhIQ%3D%3D
key=JiRkYWN+yoyIhIQ%3D%3D

だから私はいくつかの可能性があると思う：

  1. 見えない愚かなことをしている、または

  2. 一部のメールクライアントは、誤ってプラス記号をURLEncodingに変換して、すべてを元に戻すことで、人々の問題に対処しようとします。

1の場合-それは何ですか？ 2の場合-どのメールクライアントですか？または、代わりに、この種のシナリオに対処する標準的な既知の方法はありますか？

助けてくれてありがとう

htmlurlemailurl-encoding
2
Yellowfog

エンコードを正しく行っているようです。一部のメールクライアントがファンキーなことをしていることに同意します。

あなたが試すことができるいくつかのアプローチがあります：

キーのスペースを置き換えます

URLのプラス記号は、URLをスペースにデコードします。ウェブサーバーが「キー」パラメータを取得したら、スペースをプラスに置き換えます。これにより、キーが修正され、読み取りが可能になります。

Base64エンコードに異なる文字を使用する

+と=を使用する代わりに、.と-などのbase64エンコード用の2つの異なるシンボルを試してください。これらはURLとパラメーターのコンテキストで安全です。これには、base64エンコーダーを変更またはラップする必要があります。

16進エンコードに切り替える

16進エンコードは、数字と文字a〜fのみを使用します。 16進数でエンコードされた文字列は、base64でエンコードされた文字列よりも長くなりますが、文字列は非常に短く、この場合はそれほど違いはありません。

キーをまったくエンコードしないでください

電子メール検証プロセスを作成するとき、サーバーに一般的な文字と数字の文字列を生成させ、エンコードせずにurlパラメーターに貼り付けることができます。そのためのアルゴリズムは次のようになります。

array alphabet=['a','b','c',...'A','B','C',...'0','1','2'...]
string key=""
for 0 to desired_key_length
    key += alphabet[random(alphabet.length)]
2
Stephen Ostermiller