Base-64编码是一种获取二进制数据并将其转换为文本的方法，这样就更容易在电子邮件和HTML表单数据中传输。

http://en.wikipedia.org/wiki/Base64

对Brad所说的进行一点扩展:许多电子邮件和Usenet的传输机制以及其他移动数据的方式都不是“8位干净”的，这意味着标准ascii字符集之外的字符可能在传输中被破坏——例如，0x0D可能被视为回车符，并被转换为回车符和换行符。64进制将所有二进制字符映射为几个标准ascii字母、数字和标点符号，这样它们就不会被打乱。

Base-64编码是一种获取二进制数据并将其转换为文本的方法，这样就更容易在电子邮件和HTML表单数据中传输。

http://en.wikipedia.org/wiki/Base64

在计算机的早期，当电话线系统间的通信不是特别可靠时，一种快速而肮脏的验证数据完整性的方法被使用:“位奇偶校验”。在这种方法中，传输的每个字节都有7位数据，第8位将是1或0，以强制字节中1位的总数为偶数。

因此，0x01将作为0x81传输;0x02将是0x82;0x03仍然是0x03等等。

为了进一步完善这个系统，当定义ASCII字符集时，只有00-7F被分配字符。(直到今天，所有设置在80-FF范围内的字符都是非标准的)

当时的许多路由器都把奇偶校验和字节转换放在硬件中，迫使连接到它们的计算机严格处理7位数据。这迫使电子邮件附件(以及所有其他数据，这就是为什么HTTP和SMTP协议是基于文本的)转换为纯文本格式。

这些路由器很少能活到90年代。我非常怀疑它们中任何一个现在还在使用。

几年前，当邮件功能被引入时，它完全是基于文本的，随着时间的推移，对图像和媒体(音频、视频等)等附件的需求出现了。当这些附件通过互联网发送时(基本上是以二进制数据的形式)，原始形式的二进制数据损坏的概率很高。因此，为了解决这个问题，BASE64出现了。

二进制数据的问题是它包含null字符，在一些语言中，如C, c++表示字符串的结束，因此以包含null字节的原始形式发送二进制数据将阻止文件被完全读取并导致损坏的数据。

例如:

在C和c++中，这个“null”字符表示字符串的结束。所以"HELLO"是这样存储的:

H e l l o

72 69 76 76 79 00

00表示“停在这里”。

现在让我们深入研究BASE64编码是如何工作的。

注意:字符串的长度应该是3的倍数。

例1:

要编码的字符串:" ace "，长度=3

将每个字符转换为十进制。

A = 97, c= 99, e= 101

将每个小数改为8位二进制表示。

97= 01100001, 99= 01100011, 101= 01100101

合并:01100001 01100011 01100101

在一组6位中分离。

011000 010110 001101 100101

从二进制到十进制计算

011000= 24, 010110= 22, 001101= 13, 100101= 37

使用base64 chart将十进制字符转换为base64。

24= Y, 22= W, 13= N, 37= l

“ace”=>“YWNl”

例2:

要编码的字符串:" abcd "长度=4，不是3的倍数。因此，要使字符串长度为3的倍数，我们必须添加2位填充使length= 6。填充位用“=”符号表示。

需要注意的是:一个填充位等于两个000，所以两个填充位等于四个0 0000。

所以让我们开始这个过程:-

将每个字符转换为十进制。

A = 97, b= 98, c= 99, d= 100

将每个小数改为8位二进制表示。

97= 01100001, 98= 01100010, 99= 01100011, 100= 01100100

在一组6位中分离。

011000, 010110, 001001, 100011, 011001, 00

所以最后6位是不完整的，所以我们插入两个填充位，等于4个零“0000”。

011000, 010110, 001001, 100011, 011001, 000000 ==

现在，它是相等的。末尾的两个等号表示添加了4个零(有助于解码)。

将二进制计算为十进制。

011000= 24, 010110= 22, 001001= 9, 100011= 35, 011001= 25, 000000=0 ==

使用base64 chart将十进制字符转换为base64。

24= Y, 22= W, 9= j, 35= j, 25= Z, 0= A ==

“abcd”=>“YWJjZA==”

大多数情况下，我看到它被用于在只能处理ascii或简单字符集的上下文中对二进制数据进行编码。