能转。读入编码在 UTF-8、带 BOM 的 UTF-8、GBK 三档里选对源文件那一档，输出统一是 UTF-8，单文件 20MB 以内，整个过程在浏览器里完成，文件不离开本机。
所谓乱码，多数不是文件坏了，而是按错的编码去读了。GBK 是一种中文简体字符集编码，UTF-8 是一种 Unicode 转换格式，两者对同一个汉字的字节排法完全不同，用 UTF-8 去读 GBK 的字节，屏幕上就是一堆生僻字和方块。
一、先分清是哪种坏法
| 现象 | 实际原因 | 这一页怎么调 |
|---|---|---|
| 满屏汉字变成生僻字或方块 | 源文件是 GBK，读入按了 UTF-8 | 读入编码改选 GBK 再读一次 |
| 中文正常，个别符号是问号 | 源文件里已经丢了字节 | 换档也救不回来，只能找原始文件 |
| 转好的文件在表格软件里打开又乱码 | 产物没带 BOM | 输出改选带 BOM 的 UTF-8 |
| 行尾多出一个符号或整段挤成一行 | 换行符是另一种平台的写法 | 换行强制改成 CRLF 或 LF |
一句话边界：能在这三档编码之间就地转，不能把源文件里已经丢掉的字节补回来。
二、转码的操作顺序
- 打开「TXT处理」，把文件读进来。这个页收的不只是 TXT，日志、Markdown、CSV（Comma-Separated Values，逗号分隔值文本表）这类纯文本都能读。
- 读入编码先按源文件的真实编码选。不知道就先试 GBK，再看预览里那 500 行是否正常，正常就说明选对了。
- 输出编码保持 UTF-8。要给办公软件或表格软件直接双击打开的，勾上带 BOM 的输出，也就是在文件开头写上那几个标识字节。
- 换行按需选保持原样，或强制 CRLF、LF；只在跨平台交付时才动它。
- 导出成品，文件名自己认得就行；这一步不产生服务器副本。
有些浏览器对本地 GBK 原生文件的直接读取支持不好，如果换了编码档预览仍是整屏乱码，先在编辑器里把它另存一次再读进来，这是最省事的兜底走法。
三、BOM 这个开关到底管什么
BOM（Byte Order Mark，文件开头那几个标识字节）就三个字节，写在文件最前面，作用等于自报家门：谁来打开我，先读我就知道我是 UTF-8。带与不带的差别在打开方式上：编辑器一般都能自己判断，表格软件则常常靠它决定要不要按 UTF-8 拆列拆字，缺了就退化成乱码。给人直接双击看的产物建议带，纯程序读的文本建议不带，因为有的解析器会把这三个字节当成第一个字段的一部分。
四、顺手能一起做的几件事
这一页不只是转码，转码之后可以接着清。
- 去重是逐行比对，可以勾选忽略大小写。
- 删空行连只有空格的行一起删。
- 排序能按字符码位排，也能按拼音升降排。
- 查找替换可以切到正则模式，按 JavaScript 语法写。
能做这些就地清理，不能替你判断哪几行是你要留的内容，去重和排序前先看一眼预览。
五、分场景怎么选
- 一份老日志要合到今天的文件里：先转 UTF-8，再换行统一成 LF，最后合并。
- 文本其实是行列数据：转码后改走 CSV转换 那一站处理分隔符，比在纯文本里手工对齐可靠。
- 只想修一小段：直接把那段粘进页面处理，粘贴文本按 200KB、5000 行以内比较稳，页面预览一次也只给 500 行。
- 内容涉密：这一档本来就是浏览器内完成，不用先评估要不要上传。
常见问题
问：要不要登录，占不占每日转换次数？
答：都不用登录，也不占用每日转换次数。文件不离开本机，不上传服务器，转码全程在浏览器里算。
问：多大的文件能处理？
答：单文件 20MB 以内。超过这个数先按段落或按日期把源文件拆成几份，逐份转。
问：转出来还是乱码怎么办？
答：按顺序排查：先把读入编码换一档再看预览；仍是乱码说明源文件本身不是这三档里的编码，或字节已经在传档过程中丢失，换原始出处重来一次。
本站能力与限额说明
站内 TXT处理，读入编码可选 UTF-8、带 BOM 的 UTF-8、GBK，统一输出 UTF-8，顺带做去重、删空行、排序和带正则的查找替换。
能就地完成编码之间的转换并把换行统一，不能修复源文件里已经丢失的字节，也不做翻译与字段抽取。
这一步在浏览器里完成，文件不上传到服务器，也不占用每日转换次数，游客可直接用，单文件 20MB 以内。