谜题、版本预告和社交帖子里常出现编码字符串。解码能说明字符串代表哪些字节，却不能证明作者是谁、截图是否真实，或未来产品有什么能力。调查线索时，应把这些问题分开。
先准确保存原文
尽量直接复制，保留大小写、标点和填充。另行记录来源 URL 与时间。如果来源是图片，要注明人工识别可能把大写 I、小写 l 和数字 1 混淆。结果看起来像一句话，也不能证明抄录无误。
只说明实际解码结果
例如 NS41 解码为 ASCII 文本 5.5。它首先只是一个字符串，不能独立证明版本号、日期、分数，或某个组织已经发布公告。
const bytes = Uint8Array.from(atob('NS41'), c => c.charCodeAt(0));
console.log([...bytes]); // [53, 46, 53]
console.log(new TextDecoder('utf-8', { fatal: true }).decode(bytes)); // 5.5
console.log(btoa('5.5')); // NS41反向编码可以确认编码关系，但不会增加来源证据。此页面保留与预告搜索相关的历史 URL，不据此断言 URL 中的组织发布过该字符串或宣布过某个产品。
把证据分成三栏
分别记录原始输入、确定性解码结果和当前解释。除非官方来源确认，否则解释应标记为假设。传播产品消息之前直接查看官方公告，不能用转发、截图标题或解码数字代替核验。
解码失败时，报告具体原因，不要连续尝试各种变换直到出现有意义的文本。补齐已知遗漏的填充与删除未知字符不是同一件事。只有来源或格式说明还有一层编码时，才有理由再次解码。
输出也应保持不可执行。谜题可能包含链接或代码，阅读文字不需要打开链接或运行代码。先完成可逆转换，再独立评估解读的证据，这个流程同样适用于游戏线索和调试消息。