为什么得到的字符串文字的“用户名：密码”将在Authorization头与Base64编码？ 请告诉我它的背景是什么？
Answer 1:
这是对用户ID，密码产生式规则的元组它的编码之前：
userid-password = [ token ] ":" *TEXT
这里令牌规定如下：
token = 1*<any CHAR except CTLs or tspecials>
这基本上是任何US-ASCII字符的32至126，但没有该范围内一些特殊的字符 （ ( ， ) ， < ， > ， @ ， , ， ; ， : ， \ ， " ， / ， [ ， ] ， ? ， = ， { ， } ，空间，和水平标签）。
和TEXT规定如下：
TEXT = <any OCTET except CTLs,
but including LWS>
这基本上是任何八位字节 （0-255）除序列的控制字符 （码点0-31，127），但包括线性空格序列，其是一个或多个空格或可由一个CRLF序列前面水平制表符：
LWS = [CRLF] 1*( SP | HT )
尽管这不会破坏的报头字段值， LWS具有相同的语义为单个空格 ：
所有线性空白，包括折叠，具有相同的语义SP。
并保持这样的序列是，之前它被放置作为字段值的字符串进行编码。
Answer 2:
了解以下，你应该有一个清醒的认识“字符集”和“字符编码”之间的区别 。
另外，请记住， Base64编码的编码 ，而编码是不加密的 。 在任何Base64编码是故意容易解码。
所述的Base64编码，最重要的是，确保了用户：通过字符是所有部分ASCII字符集和ASCII编码。 用户：通过在HTTP基本认证是授权报头字段值的一部分。 HTTP标头值是ASCII（或扩展ASCII）编码/解码。 所以，当你Base64编码用户：通过，则确保它是ASCII的，因此是有效的报头字段值。
Base64编码还增加了至少某种模糊到清晰的文本用户：通过。 再次，这是不加密的。 但是，它确实防止正常人读取用户：通过一目了然。 这似乎从安全角度来看几乎没有任何意义，我只包括因为以下背景资料吧。
一些背景
如果你看一下RFC 2616 （现在已废弃）和RFC 2617 ，你会看到，他们同时定义的头字段值和基本认证用户：通过，分别为TEXT; 即，ISO-8859-1 OCTECTs（ISO-8859-1是一个8位的扩展ASCII编码）。 这很奇怪，因为它使得它看起来像笔者预期，一个符合规定的用户：通应该使用相同的字符集/编码为需要的HTTP头，在这种情况下，Base64编码似乎除了琐碎混淆毫无意义。
这就是说，它很难相信，这些RFC的的作者没有想到的用户名/密码以非ASCII（非ISO-8859-1）字符集是的。 假设他们有非ASCII用户：通行证记住，他们可能一直在关注如何将/维护/在所有的ASCII套头的中间传输非ASCII字节。 编码的Base64用户：通过一定很好地解决了这个问题。 还有更经典之所以使用Base64编码- 使数据传输更加可靠 。 我的理解是，HTTP是8位的清洁 ; 即使头被运为ASCII，我不认为用户的Base64编码：通就是使传输更可靠。
不问原作者，我不知道我们会永远知道。 这里是由朱利安雷什克话题的有趣的评论 。 他的作者RFC 5987，字符集和语言编码为超文本传输协议（HTTP）头字段参数 。 他还做了HTTP RFC中做了大量的工作，包括最新的HTTP 1.1 RFC检修。
当前的HTTP 1.1 RFC与HTTP报头编码，涉及RFC 7230 ，现在建议USASCII（又名ASCII，7位ASCII）为标题。 RFC 5987定义了一个报头参数编码规范-大概一些正在使用此。 RFC 7235是最近更新RFC 2617的HTTP认证。
文章来源: Why Base64 in Basic Authentication
