Base64原理：
🔢 Base64编码详解
Base64编码的过程，本质上是一种二进制到文本的重新表述 。它定义了一个包含64个字符的索引表（A-Z, a-z, 0-9, +, /），每个字符对应一个0-63的值
编码过程的核心步骤如上图所示，旨在将原始的每3个字节（共24位）数据，转换为4个Base64字符。这是因为 3 * 8 = 4 * 6 = 24，6和8的最小公倍数是24，所以3字节一组是最高效的转换方式
处理数据末尾的不足
当待编码数据的字节数不是3的倍数时，就需要处理末尾不足 的情况。Base64使用等号=作为填充字符来解决这个问题
-
情况一：剩余2个字节 。这两个字节共16位，按6位一组可分成2组后还余4位。处理方式是：第3组用剩余的4位低位补2个0构成，第4组则完全用
=填充 。因此，编码结果末尾会有一个=，例如PC编码后为UEM= -
情况二：剩余1个字节 。这个字节共8位，按6位一组可分成1组后还余2位。处理方式是：第2组用剩余的2位低位补4个0构成，第3、4组都用
=填充。因此，编码结果末尾会有两个=，例如P编码后为UA==
应用场景与注意事项
-
数据传输：确保二进制数据（如图片、附件）在仅支持文本的协议（如电子邮件、某些API）中完整传输。
-
数据嵌入：将小图片或字体文件直接以Base64形式嵌入HTML或CSS代码中，可以减少HTTP请求次数。
注意点
-
数据膨胀 ：编码后的数据体积会比原始二进制数据大约三分之一 ，3字节变4字节
-
非加密算法 ：Base64只是一种编码方式，任何人都可以轻松解码，绝不能用于保护敏感信息
-
URL安全变种 ：标准Base64中的
+和/字符在URL中有特殊含义。为避免问题，存在一种URL安全的变种，使用-和_替代这两个字符
Http Header
header 只起到说明的作用，比如说明要传输的数据是什么格式，是什么编码，以便服务器接收到之后，进行何种处理。对实质传输的数据没有影响。
另外 ：所有的数据在传输层都是以二进制传输的，服务器在收到数据之后，会根据传输层进行解析。如果实际数据和content-type不一致就会报错，比如声明为"application/json",实际上是二进制数据。
Content-Encoding
声明响应内容的压缩格式，如 Content-Encoding: gzip。如果为gzip，中间件，网关层一般会对数据进行解压，返回解压后的数据，给服务端使用。
Content-Type
响应体的媒体类型，例如 Content-Type: text/html; charset=UTF-8。服务器拿到数据后，以什么方式处理。
Range
用于客户端向服务器请求资源的特定部分。例如，客户端可以请求文件的前 1024 字节或文件的某个区间。Range: bytes=0-1023