纯文本看起来最「通用」，实际是兼容性问题的重灾区。两类问题最难查：编码和换行符 —— 因为它们都不改变文字的可见内容，只在对方系统里才暴露。

编码：识别容易，输出受限

TXT 处理 能自动识别 UTF-8、UTF-8 带 BOM 与 GBK/GB18030，读进来基本不会错。但输出只能选 UTF-8 或 UTF-8 带 BOM。

原因不是功能缺失，是浏览器的编码器只能输出 UTF-8。所以「帮我转成 ANSI」这类需求这一页做不到，页面上给的办法是确定的：用记事本打开下载结果，另存为时选编码 ANSI。

不支持 UTF-16、Big5、EUC-KR，这三类文件要先在本地转存成 UTF-8 或 GBK 再处理。繁体旧文档常见 Big5、Windows 系统导出常见 UTF-16，撞上的表现是整篇乱码或全是空格。

BOM 到底该不该加

BOM 是文件开头的 EF BB BF 三个字节，作用是告诉读取方「这是 UTF-8」。

加 BOM 的场景：Excel 双击打开 CSV 不乱码、Windows 记事本查看。
不能加的场景：程序解析、Linux 工具链、接口对接 —— 首字段名会多出三个看不见的字符，表现为「键明明一样，程序却说找不到」。

站内的 CSV 导出把这两种选择都做成了显式选项，就是这个原因，见 CSV 打开中文乱码怎么修？分清 UTF-8 和 GBK 就一次搞定。

换行符：三种表现，两种原因

CRLF 是 Windows 的换行，LF 是 Unix 与 macOS 的换行（现在的 macOS 也用 LF）。这一页可以保持原样，或统一成其中一种。

三个典型故障：

  • Linux 脚本在 Windows 上编辑后报「找不到命令」：CRLF 让解释器把 \r 当成命令名的一部分。转成 LF 就好。
  • 老 Windows 记事本打开一整行显示：只认 CRLF，遇到 LF 不分行。新版记事本已能识别 LF，但很多行业内置的老编辑器不行。
  • 文本里出现莫名多余的空行：从网页复制内容常常是 CRLF，导入按 LF 切分的系统时，每行都会被当成两行。统一一次即可。

排序与统计各有坑

排序有两种规则：按 Unicode 码位，或按中文拼音（同时具备数字感知，abc2 排在 abc10 前面）。只有码位排序会让中文按笔画乱排、编号按字符顺序错乱 —— 需要人看的清单选拼音。

统计项分别是：行数、字符数（含空白与不含空白）、中文字符数、按所选输出编码计算的字节数。 这四个数含义不同，别混用：

  • 平台限制「多少字以内」看字符数（不含空白）
  • 限制「多少 KB」看字节数 —— 同一个汉字在 UTF-8 里占 3 字节、在 GBK 里占 2 字节，这是「字数没超但体积超了」的原因
  • 判断识别结果有没有丢段落看行数

顺手能做的行处理

删除重复行（保留首次出现的位置，可忽略大小写）、删除空行（只含空格的行也算空行）、去除行首尾空格、升降序排序，以及对整个文本执行查找替换，可区分大小写、可启用 JavaScript 正则并显示命中次数。

输入不限于 .txt：.log、.md、.csv、.json、.xml、.ini、.srt 与直接粘贴的文本都行。文件建议 20MB 以内，超过 5000 行或 200KB 时输入输出框只显示前 500 行预览，处理、统计与下载仍按完整内容执行。

全程在浏览器本地完成，文件不上传服务器、不占每日转换次数、不需要登录。