前几天，在处理IOS-SDK，遇到了历史遗留关于base64相关的问题，于是翻查资料，并总结如下
Base64 内容传输编码
Base64 内容传输编码旨在表示任意形式的八位字节序列，不需要人为可读。编码和解码算法很简单，但是编码数据始终只比原始数据大 33%的未编码的数据。这种编码实际上使用的编码与 RFC 1421 中定义的隐私增强邮件 (PEM) 应用程序中的编码相同。
RFC2045_Base64.png
说明:
使用 65 个字符的 US-ASCII 子集，每个可打印字符可以使用2进制的 6 位表示。（额外的第 65 个字符，“=”， 用于表示特殊的处理功能。）
即： 0011 1111 表示 "/" (10进制63), 0011 1110 表示"+"(10进制62) 如图。 由于6位只能到63 即 64个字符，所以使用额外的第65个字符"="来表示特殊的处理功能，即常说的对齐
编码过程:
将24位的输入位组表示为输出由4个编码字符(一个字符8位)组成的字符串。 从左到右，24位输入组由3个8位输入组串联而成。这24位然后被视为4个连接的6位组，每组在base64字母表中转换成一个数字。当通过base64编码对位流进行编码时，位流必须假定最有效位在前面。也就是说，流中的第一个比特将是进入的高阶比特第一个8位字节，第8位将是低阶位第一个8位字节，以此类推。
比如: UTF-8编码下A进行base64Encode后输出是QQ==
Ａ在十进制下是65转换成２进制为 0100 0001 (一个字节8位)
一个字节只能组成2个6位 不足的补0
视为4个连接的6位组： 01 0000 01 0000
补全为8位： 0001 0000 0001 0000
其中 0001 0000 转为10进制即16， 对应表 RFC2045_Base64.png 为Q
然后会转换成ASCII下的 0101 0001 0101 0001 0011 1101 0011 1101
故A进行base64Encode后输出是QQ==（=是用来对齐的，因为要构成4个字节即32位）
参考JAVA的Base64.java 的具体做法是：
Base64.java.png
由于只有一个字符所以重点在 if(sp < end)里面
b0 = 65 （src[sp++] = src[0] = A = 65）
dst[0] = base64[16] (RFC2045_Base64.png) 即dst[0] = Q (ASCII 值为 81)
然后sp == end (都是1)
des[1] = base64[16] (RFC2045_Base64.png) 即dst[0] = Q (ASCII 值为 81)
des[2] = '='
des[3] = '='
所以得到的byte[] 的长度为4 值为 QQ==
Base64.png
其他情况同理可得
细心的朋友可能发现了上图中有个toBase64URL并且是RFC 4648，结合上面的RFC 3548
他们的差异总得来说就是3548过时了，但是实际上区别也并不算大
而我所遇到的问题恰恰也就是这些问题---因为后端接口升级而OC代码混用接口，导致Base64解码失败（实际情况很简单，但是因为对OC代码的不熟悉，对上一个编写代码的人的风格也掌握不到位，所以导致理解出了问题----虽然我至今也不理解为什么他要这样做）
网友评论