ウェブサイトにメールアドレスの確認プロセスがあります。サイトは最初に適切なキーを文字列として生成します
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
だから私はいくつかの可能性があると思う:
見えない愚かなことをしている、または
一部のメールクライアントは、誤ってプラス記号をURLEncodingに変換して、すべてを元に戻すことで、人々の問題に対処しようとします。
1の場合-それは何ですか? 2の場合-どのメールクライアントですか?または、代わりに、この種のシナリオに対処する標準的な既知の方法はありますか?
助けてくれてありがとう
エンコードを正しく行っているようです。一部のメールクライアントがファンキーなことをしていることに同意します。
あなたが試すことができるいくつかのアプローチがあります:
URLのプラス記号は、URLをスペースにデコードします。ウェブサーバーが「キー」パラメータを取得したら、スペースをプラスに置き換えます。これにより、キーが修正され、読み取りが可能になります。
+
と=
を使用する代わりに、.
と-
などのbase64エンコード用の2つの異なるシンボルを試してください。これらはURLとパラメーターのコンテキストで安全です。これには、base64エンコーダーを変更またはラップする必要があります。
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)]