iPad上HTML5读取本地CSV/Excel乱码的根本原因是FileReader默认UTF-8解析而文件实为GBK等编码，且Safari不支持GBK TextDecoder及readAsText编码参数；应改用readAsArrayBuffer+iconv-lite解码，并用PapaParse安全解析CSV，最后校验字段对齐。
iPad 上用 HTML5 读取本地 Excel 或 CSV 文件时出现乱码，根本原因几乎总是编码识别失败——FileReader 默认按 UTF-8 解析，而用户上传的文件实际是 GBK、GB2312 或 Windows-1252 编码（尤其国内 Excel 导出的 CSV）。
为什么 FileReader.readAsText() 在 iPad 上更容易乱码
iPad 的 Safari 对 FileReader 的编码参数支持不完整：即使显式传入 "GBK"，iOS 16 及更早版本会直接忽略，仍按 UTF-8 解析；且 iOS 不提供 TextDecoder 对 GBK 的原生支持（new TextDecoder("gbk") 会抛 TypeError）。
- Windows 电脑导出的 CSV 多为 ANSI（即 GBK/GB2312），无 BOM；Safari 无法自动探测
- iPad 文件 App 或邮件附件解压后可能丢失原始编码元信息
-
input[type="file"]选中文件后，file.name和file.type都不携带编码线索
用 fetch() + ArrayBuffer 绕过 FileReader 编码限制
不依赖 readAsText()，改用 readAsArrayBuffer() 获取原始字节，再用第三方解码库（如 iconv-lite）处理。注意：需提前引入压缩版 iconv-lite.min.js（约 28KB），并确保它支持浏览器环境。
- 必须使用
FileReader.readAsArrayBuffer(file)，不能用readAsDataURL - 解码前先检测是否含 UTF-8 BOM（
0xEF 0xBB 0xBF），有则直接用 UTF-8；否则尝试 GBK - iPad Safari 不支持
TextEncoder的encodeInto，但iconv-lite.decode(buf, "gbk")兼容性良好
const reader = new FileReader();
reader.onload = function(e) {
const buf = e.target.result; // ArrayBuffer
const bytes = new Uint8Array(buf);
// 检查 UTF-8 BOM
if (bytes[0] === 0xEF && bytes[1] === 0xBB && bytes[2] === 0xBF) {
const text = new TextDecoder("utf-8").decode(buf);
parseCSV(text); // 你的解析逻辑
} else {
// 用 iconv-lite 解码为 GBK（需提前加载库）
const text = iconv.decode(Buffer.from(bytes), "gbk");
parseCSV(text);
}
};
reader.readAsArrayBuffer(file);
CSV 表格整序：用 PapaParse 替代手写分割
直接 split(",") 会崩在带逗号的单元格（如 "张,三",25）或换行符内；iPad Safari 的正则性能也较弱。必须用流式 CSV 解析器，且要关掉自动类型转换（避免数字被转成 Number 导致精度丢失）。
立即学习“前端免费学习笔记（深入）”；
- 启用
header: true自动提取首行作字段名，比手动split("\n")[0]稳定 - 设
dynamicTyping: false，所有字段保持字符串，后续再按需parseInt()或parseFloat() - 加
skipEmptyLines: true过滤空白行，防止 iPad 用户误触生成空行
const results = Papa.parse(csvText, {
header: true,
dynamicTyping: false,
skipEmptyLines: true,
delimiter: ",", // 显式指定，避免制表符等干扰
});
// results.data 是数组，每项为对象，字段名来自首行
最后一步：表格渲染前做字段对齐校验
用户可能上传列数不一致的 CSV（比如某行少一个字段），PapaParse 默认用 null 填充，但 iPad 上 innerHTML += 容易因 ... null 渲染出错。必须预检每行长度是否匹配表头。
- 拿到
results.meta.fields后，遍历results.data，用Object.keys(row).length !== fields.length标记异常行 - 不要直接丢弃——显示警告并高亮该行，让用户知道“第5行字段缺失”
- 用
document.createDocumentFragment()批量插入，避免频繁重排影响 iPad 流畅度
真正麻烦的不是解码，而是用户上传的文件根本没标准可言：Excel 导出 CSV 时勾不勾「UTF-8」、用不用引号、有没有隐藏字符……这些细节在 iPad 上全靠前端兜底。别信“自动识别编码”，老老实实加 BOM 检测 + GBK 回退 + 字段校验，才是能上线的方案。
