你在网上见过这种东西吗？一段看起来像乱码但又有点规律的字符串——"SGVsbG8gV29ybGQh"。或者是图片src属性里那个长得离谱的"data:image/png;base64,iVBORw0KGgo..."。这些，都是Base64编码。
很多新手会误以为Base64是加密——毕竟它看起来"乱码"了嘛。但我得先把这个误区掰开了讲清楚：Base64不是加密，它是编码。加密的目的是保密，Base64编码后任何人都能轻松解码，没有任何保密性可言。它的真正目的是——让二进制数据能够安全地通过那些"只接受文本"的通道。
为什么需要Base64？
要理解Base64的必要性，先得了解一个历史遗留问题。
早期的互联网基础设施——Email、SMS、URL、JSON、XML——在设计时主要考虑的是传输纯文本。大部分协议和系统只能安全地处理ASCII可打印字符（32-126这个区间的字符）。
但是图片、音频、视频、PDF……这些文件的本质都是二进制数据，里面充满了0和1，直接塞进文本协议里会出各种问题：某些控制字符会干扰协议解析，二进制数据里的换行符可能被误认为格式结束标志，甚至有些网关会擅自修改"看起来像乱码"的数据。
所以人们需要一个方法，把任意二进制数据转换成"纯文本"——只有可打印ASCII字符，安全穿越各种文本协议。这个方法就是Base64。
Base64是怎么工作的？
Base64的核心思路其实很直接——把每3个字节（24位）的二进制数据，拆成4个6位的组，然后查表转换成4个可打印字符。
为什么是6位？因为2的6次方等于64——正好对应64个可打印字符。这64个字符构成了Base64的"字母表"：
索引: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 字符: A B C D E F G H I J K L M N O P Q R S T U V W X 索引: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 字符: Y Z a b c d e f g h i j k l m n o p q r s t u v 索引: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 字符: w x y z 0 1 2 3 4 5 6 7 8 9 + /
手把手演示：把"Man"编码成Base64
拿"Man"这三个字母来演示：
- 转成ASCII十进制：M=77, a=97, n=110
- 转成二进制：M=01001101, a=01100001, n=01101110（每个字符8位）
- 连成一串：010011010110000101101110（24位）
- 拆成4组6位：010011 010110 000101 101110
- 转成十进制：19, 22, 5, 46
- 查表转换：T, W, F, u
所以"Man"的Base64编码就是"TWFu"。你可以用我们的Base64工具验证一下。
边界情况：填充
如果输入的字节数不是3的倍数怎么办？比如输入只有1个字节"AB"或者2个字节"ABC"？
Base64的解决办法是"填充"（Padding）：用等号"="来补齐到4的倍数。
- 输入"AB"（2字节）→ Base64后为"QUI="——最后补了2个等号
- 输入"A"（1字节）→ Base64后为"IQ=="——最后补了3个等号
解码的时候，看到等号就知道该跳过多少位，不会搞错。
Base64的常见应用场景
Email附件（MIME）
早期的Email只支持纯文本，无法直接附加图片或文档。SMTP协议在设计时也没有考虑二进制传输的问题。于是MIME（多用途互联网邮件扩展）标准引入了Base64编码——把附件文件的二进制数据Base64化，就能作为邮件正文的一部分安全发送了。
Data URL（嵌入式图片）
在网页里嵌入小图标时，一般用img标签引用外部图片文件。但有时候为了减少HTTP请求，会把图片直接写进HTML里——这就是Data URL的用武之地：
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO 9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
浏览器看到这个data:image/png;base64开头的字符串，就会自动解码并渲染成图片。这种做法适合小图标或简单图形，但不适合大图片——因为Base64编码会增加约33%的数据大小。
API数据传输
很多RESTful API在JSON请求体里传输二进制数据（比如上传文件、发送图片）时，会先用Base64把二进制数据编码成文本字符串，再放进JSON里传输。这样做的好处是不用修改协议设计，坏处是效率低了大约三分之一。
JWT Token
JSON Web Token（JWT）在互联网身份认证中广泛使用。一个JWT由三段Base64编码的字符串组成，用点号分隔：Header.Payload.Signature。第一段Payload就是用户信息的Base64编码文本。
Base64不是加密！
我再强调一遍：Base64是编码，不是加密。任何一个会用电脑的人花5秒钟就能把Base64字符串还原成原始数据。
Base64的存在目的从来不是保密，它只是解决"二进制数据如何在纯文本环境中安全传输"这个工程问题。如果你需要真正的保密，请用AES加密——加密后再Base64编码（为了传输），接收方先解码再解密，这才是正确的组合方式。
Base64的优缺点
优点：
- 兼容性极强，任何只支持文本的协议都能用
- 编解码效率高，速度很快
- 只有64个可打印字符，不含控制字符或特殊符号
- URL-safe变体（Base64URL）可以安全地放在URL中使用
缺点：
- 体积增加约33%（3字节变4字符）
- 没有任何保密性
- 不适合传输大量数据
URL-safe Base64
标准Base64用的字符里有"+"和"/"，在URL中会出现问题——"/"会被当成路径分隔符，"+"可能被某些系统解析为空格。所以针对URL场景，又出现了Base64URL变体：把"+"替换成"-"，把"/"替换成"_"。这样生成的就是URL安全的文本。
JWT中用的就是Base64URL编码，而不是标准Base64。
动手试试
Base64的编解码过程其实非常透明。你可以用我们的Base64在线工具来尝试把各种内容——文字、图片URL、代码——编码成Base64，然后再解码回去。试试看哪些你平时常见的数据原来是Base64格式的。
理解Base64对Web开发、API对接、邮件处理都非常有帮助。虽然它看起来不起眼，但背后的设计思路——"在受限环境中安全传输任意数据"——是计算机科学中非常经典的问题。