base64编码/解码使用确定性算法。因此，给定的输入字符串将始终编码为已知的输出字符串，反之亦然。
使用浏览器访问使用基本身份验证保护的URL，浏览器将username：password对编码为base64字符串，并将该字符串放入HTTP Authorization请求标头中。使用Firebug可以很容易地从网络监视器中读取编码的字符串 - 我们称之为字符串A.
在树莓上（运行Debian Wheezy）我安装了ddclient来使用dyndns为我的域更新dns记录。 ddclient配置提供了相同的用户名：密码对，用于通过浏览器访问URL。客户端甚至尝试访问相同的URL（使用基本身份验证），但由于身份验证不正确，访问失败。在ddclient的调试输出中，我可以读取base64编码的字符串 - 让我们称之为字符串B.
由于任何原因，字符串A和字符串B不同！但它们是使用相同的用户名创建的：密码对。如果我解码Debian shell中的字符串
echo myBase64EncodedStringGoesHere | base64 --decode
或使用JavaScript的浏览器控制台
atob('myBase64EncodedStringGoesHere')
结果始终是相同的用户名：密码对，无论我是否解码字符串A或字符串B.
我唯一的解释是用户名中可能存在一些不可见的控制字符：ddclient的密码配置，影响base64编码结果。因此，我使用带有命令
的vi编辑器检查了ddclient配置
:set list
看起来一切都很好。我很难过。有没有人有胶水会发生什么？
因为@ C4stor的评论我检查了当我使用我的用户名：密码对并使用shell命令对其进行编码时会发生什么
echo username:password | base64
结果我在结尾处得到带有填充字符==的字符串A.除了填充之外，debian OS创建了与Web浏览器（在Windows上使用）相同的字符串。
根据@umläute的要求，这里有两个演示字符串：
Stirng A: bXlkb21haW4uY29tOmRueURucz
String B: bXlkb21haW4uY29tOmR5bkRucz
使用
atob('STRING')
总是给出相同的解码字符串。
答案 0 :(得分：1)
在ddclient的配置文件中，必定存在一些不可见的控制字符，可能是由于副本＆amp;粘贴......
使用vi我删除了文件中的内容并手动编写了每一行。现在ddclient产生了预期的base64编码字符串。
我仍然想知道为什么我不能用vi＆＃39; :set list命令看到这些角色，但至少现在问题已经解决了。