base64 エンコーディング / デコーディングは決定論的アルゴリズムを使用します。そのため、特定の入力文字列は常に既知の出力文字列にエンコードされ、その逆も同様です。
ブラウザーを使用して基本認証で保護された URL にアクセスすると、ブラウザーはユーザー名とパスワードのペアを base64 文字列にエンコードし、その文字列を HTTP Authorization 要求ヘッダーに配置します。Firebug を使用すると、そのエンコードされた文字列をネットワーク モニターから簡単に読み取ることができます。これを文字列 A としましょう。
ラズベリー (Debian Wheezy を実行) に ddclient をインストールして、dyndns を使用してドメインの dns レコードを更新しました。ddclient 構成には、ブラウザーで URL にアクセスするために使用されるのと同じユーザー名:パスワードのペアが提供されます。クライアントは (基本認証を使用して) 同じ URL にアクセスしようとしますが、認証が正しくないためにアクセスが失敗します。ddclient のデバッグ出力内で、base64 でエンコードされた文字列を読み取ることができます。これを文字列 B と呼びましょう。
なんらかの理由で、ストリング A とストリング B は異なります。ただし、それらは同じユーザー名とパスワードのペアから作成されます。Debian シェルで文字列をデコードすると
echo myBase64EncodedStringGoesHere | base64 --decode
または JavaScript を使用してブラウザ コンソールで
atob('myBase64EncodedStringGoesHere')
結果は、文字列 A と文字列 B のどちらをデコードしても、常に同じユーザー名とパスワードのペアになります。
私の唯一の説明は、base64 エンコードの結果に影響を与える、ddclient のユーザー名:パスワード構成に目に見えない制御文字が含まれている可能性があるということです。vi
したがって、エディターでコマンドを使用して ddclient 構成を確認しました
:set list
それはすべて良さそうです。私は困惑しています。誰かが何が起こっているのか接着剤を持っていますか?
更新 1
@C4storのコメントのため、ユーザー名とパスワードのペアを取り、シェルコマンドでエンコードするとどうなるかを確認しました
echo username:password | base64
その結果==
、最後にパディング文字を含む文字列 A が得られます。パディングのほかに、debian OS は Web ブラウザ (Windows で使用) と同じ文字列を作成しました。
更新 2
@umläute のリクエストに応じて、2 つのデモ文字列を以下
に示します。
Stirng A: bXlkb21haW4uY29tOmRueURucz
String B: bXlkb21haW4uY29tOmR5bkRucz
atob('STRING')
常に同じデコードされた文字列を提供します。