文件编码转换工具（UTF-8 带BOM・Shift_JIS）
转换CSV或文本文件的字符编码。为UTF-8文件添加BOM以便Excel正确打开，或转换为Shift_JIS。自动识别原编码，支持换行符转换，全部在浏览器内处理。
按用途推荐的设置
应保存为哪种编码取决于接收方。以下为参考。
| 需求 | 推荐设置 |
|---|---|
| 用Excel直接打开UTF-8的CSV | UTF-8 ＋ 添加BOM（Excel可正确判断编码） |
| 导入旧业务系统・会计软件 | Shift_JIS ＋ CRLF（面向Windows的传统组合） |
| 由程序（Python・PHP等）读取 | UTF-8（无BOM）＋ LF（BOM会混入首个字段名） |
| 用Mac版Excel打开 | UTF-8 ＋ 添加BOM |
| 导入Google表格 | UTF-8（BOM可有可无）（BOM会被自动忽略） |
| 准备旧邮件环境的正文 | JIS（ISO-2022-JP） |
各编码的特点
本工具支持的编码及注意事项。
| 编码 | 特点 |
|---|---|
| UTF-8 | 当前的通用标准，可表示各国文字与表情符号。 |
| UTF-8（带BOM） | 文件开头附加3字节标记，使Excel不会误判编码。 |
| Shift_JIS | Windows日文环境长期使用的编码，无法表示表情符号与部分异体字。 |
| EUC-JP | 主要用于UNIX系统的日文编码，现在很少新采用。 |
| ISO-2022-JP（JIS） | 邮件中使用的编码，无法表示半角片假名。 |
CSV 的乱码为何会发生
以 Excel 开启 CSV 时文字崩坏的原因，多半是档案的字元编码与 Excel 所假定的字元编码不一致。Windows 版的 Excel 在 CSV 档案没有任何标记时，会假定其内容为当地既有的字元编码（日文环境即 Shift_JIS）来读取。然而近来的网路服务或程式所输出的 CSV 多为 UTF-8，将 UTF-8 的位元组序列当作 Shift_JIS 解读的结果，便会显示出「譁�蟄怜喧縺�」这类崩坏的字串。
解决方式有两种。一是将档案转换为 Shift_JIS，二是维持 UTF-8 并在档案开头加上 BOM（Byte Order Mark，3位元组的标记）。有 BOM 时 Excel 便能判断「这是 UTF-8」，因此可在不改动内容的情况下避免乱码。本工具支援两种转换，原始档案的字元编码会自动判定。处理全部在浏览器内进行，档案不会送往伺服器。
字元编码转换的使用方法
- 选择档案 将 CSV 或文字档拖放进来，或点击选择。读入后会自动判定原本的字元编码与换行字元。
- 以预览确认判定结果 若预览的文字能正确阅读，即表示判定成功。若看起来崩坏，可能选到了文字档以外的档案。
- 选择转换目标 若要以 Excel 开启，请选「UTF-8」＋「加上 BOM」；若要汇入旧的业务系统，请选「Shift_JIS」。
- 下载 按下「转换并下载」，便会储存为在原档名加上字元编码後缀（_utf8bom、_sjis 等）的档案。
用好本工具的小技巧
- 若只是想用Excel打开，UTF-8加BOM最安全，正文字符完全保留。
- 转换为Shift_JIS时无法表示的字符会变成「?」。本工具会先列出将要丢失的字符。
- 由程序读取的文件请勿添加BOM，否则BOM会成为首个字段名的一部分。
这些时候可以使用
从网路服务输出的 CSV 在 Excel 中乱码
以 UTF-8 输出营收资料或会员名单的服务很多，直接以 Excel 开启便会乱码。只要加上 BOM 即可解决。
无法汇入会计软体或薪资系统
旧的业务系统有时只接受 Shift_JIS 的 CSV。将 UTF-8 档案转换为 Shift_JIS 即可顺利汇入。
以程式读取带 BOM 的 CSV 时首栏异常
BOM 是看不见的3个位元组，直接读取时会混入第一个栏位名称中。转换为去除 BOM 的 UTF-8 即可解决。
换行字元（CRLF/LF）的差异导致被视为一行
在 Mac 上以 LF 建立的档案，若以旧的 Windows 应用程式开启，换行可能被忽略而整份看起来只有一行。转换为 CRLF 後再交付即可解决。反之，在 Windows 建立的 CRLF 档案通过 Unix 系指令时行尾会残留 ^M，此时请转换为 LF。
想确认乱码档案的内容
由于会自动判定字元编码并正确重新读取，即使原本开启後无法阅读的档案，也能以预览确认其内容。
与字元编码相关的术语
- 字元编码
- 将文字与电脑内部的位元组序列相互对应的规则。输出时与读取时的规则不同，便会发生乱码。
- BOM
- Byte Order Mark 的缩写，是置于档案开头的3个位元组（EF BB BF）标记。具有告知应用程式「这是 UTF-8」的作用，但以程式读取时可能被视为多余的字元。
- 换行字元
- 表示一行结束的位元组。Windows 使用 CRLF（2位元组），Mac 与 Linux 使用 LF（1位元组），因此跨环境时可能看起来只有一行，或多出额外的行。
- Shift_JIS
- 在 Windows 的日文环境中长期广泛使用的字元编码。收录字数少于 UTF-8，无法表现表情符号与部分异体字。
- 乱码（mojibake）
- 以与原本不同的字元编码读取後，排列出不具意义文字的状态。「譁�蟄怜喧」这类排列是将 UTF-8 当作 Shift_JIS 读取时的典型例子。
常见问题
闲话 ― 乱码的形状会告诉你原因
乱码有可辨认的规律。出现一串互不相关的汉字，通常是把UTF-8的字节当作Shift_JIS读取所致——UTF-8中一个日文字符占3字节，按2字节重新切分自然会得到完全不同的字。反之把Shift_JIS当作UTF-8读取时，由于字节序列本身无效，会出现一排替换字符。
BOM原本是为UTF-16标示字节顺序而设计的。UTF-8不存在字节顺序问题，因此Unicode标准并不推荐为UTF-8添加BOM。但在Windows生态中它依然广泛使用，因为只能靠猜测判断编码的应用确实需要一个明确的标记。