5.2　Base64算法的定义

Base64是一种基于64个字符的编码算法，根据RFC 2045（http：//www.ietf.org/rfc/rfc2045.txt）的定义：“Base64内容传送编码是一种以任意8位字节序列组合的描述形式，这种形式不易被人直接识别（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）”。经过Base64编码后的数据会比原始数据略长，为原来的4/3倍。经Base64编码后的字符串的字符数是以4为单位的整数倍。

RFC 2045还规定，在电子邮件中，每行为76个字符，每行末需添加一个回车换行符（“\r\n”），不论每行是否够76个字符，都要添加一个回车换行符。但在实际应用中，往往根据实际需要忽略了这一要求。

在RFC 2045文件中给出了如下字符映射表：

这张字符映射表中，Value指的是十进制编码，Encoding指的是字符，共映射了64个字符，这也是Base64算法命名的由来。映射表的最后一个字符是等号，它是用来补位的。也难怪有经验的读者朋友一看到字符串末尾有个等号，就会联想到Base64算法了。

其实，Base64算法还有几个同胞兄弟，如Base32和Base16算法。为了能在http请求中以Get方式传递二进制数据，由Base64算法衍生出了Url Base64算法。

Url Base64算法主要是替换了Base64字符映射表中的第62和63个字符，也就是将“+”和“/”符号替换成了“-”和“_”符号。但对于补位符“=”，一种建议是使用“～”符号，另一种建议是使用“.”符号。其中，由于“～”符号与文件系统冲突，不建议使用；而对于“.”符号，如果出现连续两次，则认为是错误。对于补位符的问题，Bouncy Castle和Commons Codec有差别：Bouncy Castle使用“.”作为补位符，而Commons Codec则完全杜绝使用补位符。

有关Base16、Base32和Url Base64算法的详细内容，读者朋友可以参考RFC 4648（http：//www.ietf.org/rfc/rfc4648.txt），该文档提交于2006年10月，是一份建议标准（Proposed Standard）。