编码与字符集
Base64 中是什么？查看原始内容
使用工具
API 响应或配置文件里，是否出现过一长串看不懂的字符？你可能会以为它已经加密，因而停止排查。但有时它只是以 Base64 形式表示的数据。
本指南先还原公开的小示例，再逐项改变条件。学习操作不需要粘贴实际凭据。分清原始数据、编码后的表示和输出方式，再长的字符串也能按顺序检查。
YWJj 还原后是什么？
打开 Base64 工具，选择解码、标准 Base64 和 UTF-8 输出。只输入下面四个字符再执行，不包含引号或说明文字。
YWJj结果是 abc。切换为编码并输入 abc，输出应回到 YWJj。这样就完成了原始数据和编码表示之间的往返，全程没有使用密钥或解密密码。
编码是按规则改变表示方式，解码是从该表示取回数据。看起来难读，并不意味着别人无法还原。检查实际数据时，应始终保留这个区别。
为什么要把数据变得难读？
abc 直接发送似乎更简单。但如果要通过面向文本的格式传递图片或任意文件，情况就不同了：并非每种字节都能直接放入这种格式。
Base64 用有限的字符集合表示原始字节。它解决的是表示问题，而不是保密问题。API 若定义了 Base64 字段，可以理解为用文字的形式携带字节，而不是已经保护了内容。
同样是 abc，结果为什么不同？
在编码模式下比较 abc 和末尾带一个 LF 换行的 abc。后者得到 YWJjCg==，不是 YWJj。字母后的不可见字节也是数据，结果并非随机变化。
YWJj
YWJjCg==如果解码文本看起来一样，改用 Hex 输出。无换行是 616263，带 LF 是 6162630a。来自其他环境的数据也可能使用 CRLF，不能只凭显示相似就认定字节相同。
中文也能还原，但要注意字符编码
试试三个字符『日本語』。SheepDev 先把文本转换为 UTF-8 字节，再编码为 Base64，得到 5pel5pys6Kqe。用 UTF-8 输出解码，可还原相同的三个字符；界面语言不会改变这个例子的结果。
Base64 本身不理解中文、日文或韩文。文字转字节、字节转 Base64 是两个不同步骤。源数据若使用 Shift_JIS 等其他编码，即使 Base64 合法，也未必能作为 UTF-8 文本读取。
此时可查看 Hex，并使用数据生成方确认的编码继续检查。不要不断切换编码，只求错误消失。即使出现可读文字，也不能单凭这一点断定正确恢复了原文，应与已知内容核对。
输出变长并非失败：Base64 不是压缩
abc 占 3 个 UTF-8 字节，YWJj 是 4 个 ASCII 字符。Base64 通常把 3 个字节表示成 4 个字符，较长数据约变为原来的 1.33 倍。把图片改成 Base64，并不等于减少传输量。
| 原文 | 标准 Base64 |
|---|---|
| a | YQ== |
| ab | YWI= |
| abc | YWJj |
短输入受补位影响，表面倍率可能更大。依次试 a、ab、abc，末尾等号数量会变化。等号是与长度有关的补位，不是损坏字符或复制产生的杂质。能否省略，要看使用方格式的规定。
Base64url 有什么不同？
标准 Base64 使用 + 和 /，Base64url 在对应位置使用 - 和 _。SheepDev 编码 Base64url 时也省略末尾补位。应按接收格式的规定选择，而不是因为应用运行在网页上就自动选 Base64url。
只用 abc 看不出全部差异，因为某些输入在两种方式下相同。改用 ????：标准结果为 Pz8/Pw==，Base64url 为 Pz8_Pw。还原时选择对应方式，手工替换字符前先检查设置。
解码后不一定是文章
Base64 不只承载文章。图片、压缩数据或密文在解码后未必是合法 UTF-8。Base64 格式错误，与恢复出的字节不能当作 UTF-8 读取，是两种不同的问题。
可用 /w== 练习。按标准 Base64 解码为 Hex 得到 ff，但单个 FF 字节不是合法 UTF-8 文本。因此 UTF-8 报错不代表 Base64 一定有错。Hex 用于观察字节，不是显示原始图片的功能。
无法还原时，按什么顺序检查？
- 确认来源明确规定为 Base64。只凭一长串字母数字，无法与 ID 或哈希区分。
- 检查是否复制了完整的值，而非引号、注释或 data: URL 头部，也要检查有无截断。
- 核对标准 Base64 与 Base64url 选项。SheepDev 不会自动删除所有内部空格与换行，也要确认源格式是否会主动折行。
- 格式能解码后，再确认内容类型。文本要检查字符编码，其他数据要检查原始文件格式，不应把无意义输出当作正确恢复。
看不懂，不代表保密
想想最初不需要密钥就把 YWJj 还原为 abc。密码或个人信息编码后仍有这一特性。提交问题报告时，若把编码值当成已经脱敏的内容，可能暴露原始信息。
哈希的用途不同，不能像 Base64 那样解码哈希值来恢复原文。读出 JWT 内容也不代表签名或可信性已被验证。应查看对应指南，根据想获得的证据选择工具。
怎样用于实际排查？
有用的排查记录不只是『解码成功』。应记录来源规定的格式、输出方式，以及预期与实际内容的差异。例如『标准 Base64 可还原，Hex 是 FF，但不是 UTF-8』，就能把下一步引向数据类型或字符编码。
先确认格式，再取出值，最后确认原始数据类型。养成这个顺序后，转换工具不只是改变字符串，也能帮助缩小问题范围。能读出内容，从不意味着可以安全执行或公开它。