自动判断编码 · 乱码修复 · 码点与字节对照 · 按指定编码导出
下面是当前读出来的文字，可以直接改，改完导出的就是改过的。但换编码会重读原文件，这里的手改会被替换掉，所以先定编码再动笔。
看着是乱码时，选它「本来是用哪种编码写的」，页面把现在这些字按错读的那条路还原成字节，再用本来的编码解一遍，列出候选给你挑。最常见的两种：UTF-8 的内容被当成 GBK 读、GBK 的内容被当成 UTF-8 读。这些字里有哪种是「被当成」那个编码压根写不出来的，那条路就直接跳过——它本来不可能是这样读错的。
目标编码里装不下的字会当场列出来，不会悄悄变成问号。导出的是新文件，不改动你电脑里的原文件。
先嗅 BOM，再按严格解码一个个试，认出来会写明按哪种读的、凭什么。
UTF-8 被当 GBK 读、GBK 被当 UTF-8 读，都能编回字节再解一遍。
逐字给出码点、UTF-8 字节和 GBK 字节，可疑字符单独列出来。
UTF-8、UTF-16、GBK、Big5、Windows-1252、Latin-1 任选，装不下的字会点名。
文字文件里存的从来不是字，是一串编号。GBK 与 UTF-8 是两套编号表：同一串字节，按 GBK 查是一句人话，按 UTF-8 查就成了「浣犲ソ」这种怪字——那其实是「你好」两个字的 UTF-8 字节被按 GBK 查了一遍。谁也没写错，只是读的时候拿错了表。
BOM 是放在文件最前面的几个字节，作用是自报家门：EF BB BF 表示 UTF-8、FF FE 表示 UTF-16 小端、FE FF 表示 UTF-16 大端。带不带都能存，但老程序常常靠它来认。微软的说明写得很直接：带 BOM 的 UTF-8 CSV 在 Excel 里能正常打开，不带 BOM 就得走「数据 → 从文本/CSV」这类导入路。所以本页不替你做主，要不要带 BOM 由导出时那个勾决定。
两个表只有 0x80 到 0x9F 这 32 个位置不同：Latin-1 在那里放的是控制字符，Windows-1252 放的是欧元号、弯引号、省略号这些能看的字。麻烦在于 WHATWG 的编码标准（浏览器解码器的依据）里根本没有独立的 Latin-1，iso-8859-1 这个标签直接指向 Windows-1252。所以本页的 Latin-1 是自己按「一个字节一个编号」实现的，和 Windows-1252 是两条真的不一样的路。
不是。GB2312 最小，GBK 把它包进来并补了繁体与更多字，GB18030 最全，连生僻人名用字和少数民族文字都用四字节编码补上了。本页读的时候按 GB18030 这张最大的表来认，所以 GBK、GB2312 的文件都读得进；导出的时候只能填两字节的 GBK 部分，遇到 GB18030 才有的四字节字会点名告诉你，不会悄悄替换。
读进来靠浏览器自带的解码器：UTF-8、UTF-16 大小端、GB18030／GBK、Big5、Shift JIS、EUC-KR、Windows-1252 都能试，Latin-1 是本页自己实现的。写出去只做了逐字节验过的几路：UTF-8（带或不带 BOM）、UTF-16 LE／BE、GBK 的两字节部分、Big5、Windows-1252、Latin-1；Shift JIS 和 EUC-KR 的编码表要整表内置，本页坚持单文件零依赖，就不硬凑一个没验过的写法。
有些字符看不见但会捣乱：零宽空格、不间断空格、私有区字符、复制网页带回来的软连字符。它们在码点表里各有一个明确编号，找出编号比凭眼看准得多。统计条里的「替换符」数的是 U+FFFD 这个字符出现的次数，只要不是零，就说明有字节在当前编码里对不上号。
超过 10 MB 的文件本页不接（浏览器里解起来太慢，也容易把标签页挤爆）；0 字节密集又不呈 UTF-16 规律的，看着是图片、压缩包那一类，本页先拦一次不硬读，你确定它是文本的话，在「按编码读」里点一个编码就会照样读给你看。UTF-32 有专门的 BOM，认出后直接说明，不会拿别的方式硬解。