在 「TXT处理」里把编码切成 GBK，是找不到这个选项的。这一页能读 GBK 与 GB18030，但只能写出 UTF-8 或 UTF-8 带 BOM。原因不在功能清单少写了一行，而在浏览器的文本编码能力：网页环境提供的编码转换接口只支持输出 UTF-8，GBK 这类传统中文编码没有对应的编码器。所以任何纯前端的在线文本工具都存不出 GBK 文件，换一家也一样。
为什么读得出却写不回
读的时候可以做猜测：拿到一串字节，按 UTF-8 解一遍、再按 GBK 解一遍，看哪个能出通顺中文，工具就自动挑哪个。这一步不需要官方编码器，自己查表即可。
写的时候必须逐字精确映射，一个汉字要落到正确的双字节位置上，猜不得。浏览器没带这张表，硬做出来的结果会把生僻字写错 —— 那比直接不支持更糟。
补救只有两步，而且在你这边
- 先正常下载 UTF-8 的文件，确认中文在记事本里显示正确。这一步错了后面全错，别跳过。
- 在记事本里执行「文件 → 另存为」，把最下方的编码下拉框改成 ANSI，覆盖保存。中文 Windows 下 ANSI 就等于 GBK 一族。
新版记事本默认就是 UTF-8，下拉框里那几个选项容易被忽略。另存前务必先看一眼当前编码是不是 UTF-8、中文是否正常，如果打开就已经乱码，说明原始编码判断错了，此时保存会把错字符写进文件，再也修不回来。
有一类字确实存不过去
GBK 收录的汉字数量少于 UTF-8。生僻人名用字、部分异体字、特殊符号在 GBK 里没有码位，转成 ANSI 时它们会变成问号或其他字符。这不是操作失误，是目标编码的字库装不下。遇到这种情况只能问接收方能否改用 UTF-8，或者把这些字单独拆出来手工补。想保留全部字符，就得留在 UTF-8。
跟对方系统管理员的沟通话术
不要问「能不能传个 GBK 的文件给我」，这句话会绕很久。直接问三件具体的事：导入程序读取文本时按什么编码解码；表头是否允许出现 BOM；换行符要不要从 CRLF 改成 LF。三个答案拿到，格式就定了。若对方坚持 GBK，明确回一句「在线工具产出的是 UTF-8，我用记事本另存为 ANSI 后再发，请确认能收到」，把责任节点写清楚。
底线判断
不要为了凑 GBK 而去找桌面小工具或来源不明的脚本，那是把整份文本交出去。也不要长期维护两份编码不同的同名文件，迟早有人改了旧的那份。真正稳妥的做法是把转换固定成一个人负责的一个动作：UTF-8 出稿、记事本另存 ANSI、当场双击验证。换行符与编码是两件独立的事，一起搞混的人更多，见 GBK 转 UTF-8 与 CRLF 转 LF。