Base64値には +、/、= が含まれることがあります。クエリー文字列のパーサーは、そのままの + を空白として解釈する場合があります。無作為に文字を置き換えると、元の間違いが隠れてしまいます。
実際のパスワード、トークン、個人記録ではなく、無害な例を使ってください。UTF-8テキスト a?b は YT9i にエンコードされます。この最初の例では往復変換を確認しますが、問題になる文字は含まれていません。別のリテラルテスト値 a+b/c= はURLコンポーネントのエスケープ確認に役立ちますが、有効なBase64値として示しているわけではありません。
URL Encoder & Decoderでは、パラメーターの値だけをエンコードします。リテラル a+b/c= は a%2Bb%2Fc%3D になります。選んだキーの後に、例えば ?value=a%2Bb%2Fc%3D のように入れます。https://... というアドレス全体をコンポーネントエンコーダーに渡して、URLの区切り文字が変わらず残ると考えないでください。
受信側ではURLコンポーネントを1回デコードします。結果は引き続き a+b/c= であるはずです。受信側が application/x-www-form-urlencoded データを解析する場合、生の + の扱いは decodeURIComponent と異なります。FrAIFlowのコンポーネントデコーダーはリテラルの + を保持し、フォームのデコード規則を自動適用しません。この違いは診断材料であり、どちらかのツールが壊れている証拠ではありません。
実際に有効なBase64値を復元してから、Base64デコードしてください。パディングやUTF-8のエラーが出たら停止し、元の表現と選択した形式を確認します。読める文字列になるまで繰り返しデコードするのは、安全な修復方法ではありません。予期しない %252B は余分なエンコード層を示す場合がありますが、それだけではどのシステムが追加したかは証明できません。
エンコードは暗号化ではありません。URLは履歴やサーバーログに保存されることがあるため、転送用にエンコードするより、秘密情報をクエリー文字列に入れない方が安全です。
関連ツールを使う
入力と結果はこのブラウザー内にとどまります。アカウントやアップロードは不要です。