从最外层开始
编码是按顺序包裹的，解码必须反向执行。若原文先 Base64、再 URL 编码，拿到的字符串最外层会出现 %2B、%2F 或 %3D；因此先 URL 解码，再做 Base64。
| 外观 | 优先假设 | 验证方式 |
|---|---|---|
| %41、%2F、%3D | URL 百分号编码 | 解码后是否出现结构字符 |
| A-Za-z0-9+/ 与 = | Base64 | 解码后是否为文本或文件头 |
| 成对的 0-9a-f | Hex | 两个字符还原一个字节 |
| 8 位 0/1 分组 | Binary | 每组应在 0–255 |
| 字母仍像单词但错位 | ROT13/Caesar | 替换后语言结构改善 |
给每一步留下证据
推荐记录“输入摘要、执行操作、输出前 80 个字符、判断理由”。例如：
Step 1 URL decode
Input ZmxhZyUyNTdCY2hhaW4lMjU3RA%3D%3D
Output ZmxhZyUyNTdCY2hhaW4lMjU3RA==
Reason %3D 还原为 Base64 padding
Step 2 Base64 decode
Output flag%257Bchain%257D
Reason 可读文本，仍含百分号序列接着进行两次 URL 解码，最终得到 flag{chain}。这里每一层都有格式信号，过程可以复现。
判断输出有没有变好
一次转换值得保留，通常因为输出出现了更明确的结构：可读语言比例提高、JSON/XML 能解析、出现文件签名、出现题目已知前缀，或字符集从高熵变成有规则的分组。只因为“工具没有报错”不算证据。
失败也要保留
记录无效分支可以防止团队成员重复尝试。同一个输入不要在没有新证据时循环 Base64、Hex 和 ROT13。
处理歧义
纯十六进制文本也可能恰好只含 Base64 字符。此时分别尝试一次，并比较输出结构。长度、上下文和题目类别都是辅助证据：网络参数优先考虑 URL 编码，文件片段优先检查魔数，JWT 段优先考虑 Base64URL。
稳定流程
- 复制原始值并保留。
- 列出可见特征，不急着操作。
- 选择证据最强的外层转换。
- 执行一次，检查输出是否更有结构。
- 把有效步骤加入工具链，无效步骤标记后回退。
- 得到 Flag 后反向复核每一层。