iPad上HTML5文件读取中文乱码的根源是iOS Safari的FileReader不自动识别UTF-8 BOM且默认ISO-8859-1解码，应改用arrayBuffer()+TextDecoder手动处理BOM与编码。
HTML5 在 iPad 上无法可靠导入文本，不是你操作错了，是浏览器限制了文件系统访问权限——input[type="file"] 触发的读取行为在 iOS Safari 中默认不支持 readAsText 的完整编码识别，尤其对 UTF-8 BOM、换行符（\r\n vs \n）、中文字符边界处理极不稳定。
为什么 iPad 上 FileReader.readAsText() 会丢字或乱码
iOS Safari 的 FileReader 实现存在两个关键缺陷：
- 不自动检测 UTF-8 BOM，若文本文件带 BOM，
readAsText()可能截断首字或误判编码 - 对
File对象的slice()方法支持不一致，部分 iPadOS 版本中file.slice(0, 100)返回空或异常长度 - 未指定
encoding参数时，iOS 默认按 ISO-8859-1 解码，中文直接变
用 FileReader.readAsArrayBuffer() + 手动解码保全中文
绕过编码黑箱，自己控制解码逻辑。这是目前最稳的方案：
- 必须使用
readAsArrayBuffer()读取原始字节 - 用
TextDecoder显式指定utf-8，并启用fatal: false容错 - 避免依赖
file.text()（iOS 不支持）或new TextDecoder().decode(buffer)（不处理 BOM）
const input = document.querySelector('input[type="file"]');
input.addEventListener('change', async (e) => {
const file = e.target.files[0];
if (!file) return;
const arrayBuffer = await file.arrayBuffer();
// 手动跳过 UTF-8 BOM（EF BB BF）
let offset = 0;
const view = new Uint8Array(arrayBuffer);
if (view.length >= 3 && view[0] === 0xef && view[1] === 0xbb && view[2] === 0xbf) {
offset = 3;
}
const decoder = new TextDecoder('utf-8', { fatal: false });
const text = decoder.decode(arrayBuffer.slice(offset));
console.log(text); // 此时中文、换行、标点全部保留
});
iPad 文件选择器选中后没触发 change 事件？
这不是 bug，是 iOS Safari 的策略：只有用户**真实点击** 才触发事件；用 JS 调用 click()、或包裹在 里但 label 没加 for 属性，都会静默失败。
立即学习“前端免费学习笔记（深入）”；
- 确保
input是可见且可点击的（不能display: none或opacity: 0） - 如需隐藏原生控件，用
position: absolute; left: -9999px替代不可见方式 - 绑定事件必须在 DOM 加载完成后执行，且不能被
preventDefault()干扰
别依赖 file.name 或 file.size 做唯一判断
iPad 上通过“文件”App 导入的文本，file.name 可能为空字符串，file.size 可能为 0（尤其从备忘录粘贴后另存为 txt）。更可靠的判断方式是：
- 检查
file.type是否为"text/plain"或空字符串（iOS 常返回""） - 用
arrayBuffer().then(buf => buf.byteLength > 0)确认内容非空 - 对前 100 字节做
Uint8Array检查，确认是否含可读 ASCII/UTF-8 字符
真正麻烦的不是读取，而是 iOS 把文件输入当成「临时快照」——一旦页面刷新或切换标签页，File 对象就失效。如果要做多步处理（比如导入 → 校验 → 渲染 → 编辑），务必在 change 回调里立刻转成字符串或 ArrayBuffer 缓存，别留着 File 引用等后续读取。
