为什么在基本身份验证中使用 Base64 [英] Why Base64 in Basic Authentication

查看:26
本文介绍了为什么在基本身份验证中使用 Base64的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

为什么用户名:密码"的结果字符串文字在授权标头中使用 Base64 编码?它的背景是什么?

why has the resulting string literal of "username:password" be encoded with Base64 in the Authorization header? Whats the background of it?

推荐答案

这是 userid-password 元组编码前的生产规则:

This is the production rule for the userid-password tuple before it’s encoded:

userid-password   = [ token ] ":" *TEXT

这里指定了 token如下:

Here token is specified as follows:

   token          = 1*<any CHAR except CTLs or tspecials>

这基本上是范围内的 任何 US-ASCII 字符32 到 126 但没有 一些特殊字符 ((, ), <, >, @, ,;:"/[, ], ?, =, {, }、空格和水平制表符).

This is basically any US-ASCII character within the range of 32 to 126 but without some special characters ((, ), <, >, @, ,, ;, :, , ", /, [, ], ?, =, {, }, space, and horizontal tab).

并且指定了 TEXT如下:

And TEXT is specified as follows:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

这基本上是任何 八位字节 (0–255) 序列除了 控制字符(代码点 0–31、127)但 包括线性空白序列,这是一个或多个空格或水平制表符前面可能有一个 CRLF 序列:

This is basically any octet (0–255) sequence except control characters (codepoints 0–31, 127) but including linear whitespace sequences, which is one or more space or horizontal tab characters that may be preceded by a CRLF sequence:

   LWS            = [CRLF] 1*( SP | HT )

虽然这不会破坏标头字段值,但 LWS 与单个空格具有相同的语义:

Although this doesn’t break a header field value, LWS has the same semantics as a single space:

全线性空格(包括折叠)与 SP 具有相同的语义.

All linear whitespace, including folding, has the same semantics as SP.

为了保持这样的序列不变,字符串在作为字段值放置之前被编码.

And to keep such sequences as is, the string is encoded before it’s placed as field value.

这篇关于为什么在基本身份验证中使用 Base64的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆