HTML5无法直接导入iPad文档，需通过<input type="file">或FileSystemAccess API读取，但iPadOS限制严格：仅支持文件App/iCloud/下载文件夹，不识别.pages等原生格式，FileReader存在大文件卡死和编码乱码问题，文档解析应交由服务端处理。
HTML5 本身不提供直接“导入 iPad 文档”的能力——所谓“导入”，实际是用户通过 <input type="file"> 选择文件，或通过 Web API（如 FileSystemAccessAPI）读取本地文件。iPad 上的 Safari（尤其是 iOS/iPadOS 16.4 之前）对这些能力有严格限制，很多你以为能跑通的逻辑会静默失败或根本不可用。
iOS/iPadOS 的 <input type="file"> 实际支持范围很窄
iPad 用户点击 <input type="file"> 后，系统弹出的文件选择器受限于当前 App 的沙盒权限和 WebKit 实现：
- 仅支持从“文件”App、iCloud Drive、本地“下载”文件夹中选取（且需用户手动开启对应位置权限）
- 无法访问 Pages/Numbers/Keynote 等原生文档的编辑态内容——它们导出为
.pages、.numbers等格式后，Safari 默认不识别其 MIME 类型，accept属性几乎无效 -
capture属性在 iPad 上对文档类无意义，它只对user/environment摄像头或microphone生效 - 即使用户选中一个
.pdf文件，File对象的type字段也常为空字符串（""），不能依赖 MIME 判断类型
读取文档内容必须用 FileReader，但 iPad 上有兼容性陷阱
选中文件后，必须用 FileReader 读取二进制或文本内容。但在 iPadOS 15–16.3 中存在两个关键问题：
-
FileReader.readAsArrayBuffer()在处理大于 ~20MB 的文档（如大 PDF 或 Word）时可能卡死或触发abort事件，无错误提示 -
FileReader.readAsText()对非 UTF-8 编码文档（如 GBK 中文 Word 导出的 TXT）会乱码，且 iPad Safari 不支持传入编码参数（Chrome/Firefox 支持readAsText(file, "gbk")） - 若用户从“邮件”App 点击附件跳转到网页，
input.files可能为空——这是 WebKit 的已知 bug（iOS 16.4 已修复，但旧设备仍大量存在）
const input = document.querySelector('input[type="file"]');
input.addEventListener('change', (e) => {
const file = e.target.files[0];
if (!file) return;
<p>const reader = new FileReader();
reader.onload = () => {
// 注意：reader.result 是 ArrayBuffer 或 string，取决于 readAsXXX 方法
console.log('文件大小:', file.size, '字节');
};
reader.onerror = () => console.error('读取失败:', reader.error);
reader.readAsArrayBuffer(file); // 避免用 readAsText 处理未知编码文档
});想解析 Word/PDF/Excel？别指望纯前端在 iPad 上可靠运行
HTML5 没有内置文档解析能力。常见方案如 docxtemplater、pdfjs-dist、xlsx 库，在 iPad 上面临真实约束：
立即学习“前端免费学习笔记（深入）”；
-
pdfjs-dist的getDocument()在 iPadOS 15+ 上需显式传入workerSrc，否则报Missing PDF.js worker错误；且默认 worker 路径在 Service Worker 环境下可能 404 -
xlsx解析 .xlsx 文件时，若使用XLSX.read(data, {type: "array"})，需确保data是Uint8Array（不是ArrayBuffer），否则 iPad Safari 报Cannot read property '0' of undefined - 所有这类库在内存紧张时（如 4GB 内存的 iPad Air 2）容易触发页面崩溃，尤其解析带图片的 Word 文档
真正可行的路径：服务端辅助 + 客户端降级策略
不要试图在 iPad 前端完成完整文档解析。合理做法是：
- 前端只做最小化验证：检查
file.size < 10 * 1024 * 1024、扩展名是否为.pdf/.docx/.xlsx（靠file.name后缀，不依赖type） - 上传前用
File.slice()截取前 1024 字节，发给后端做魔数（magic number）校验，确认真实格式 - 上传走
fetch()+FormData，禁用XMLHttpRequest（iPad Safari 对其 progress 事件支持不稳定） - 上传成功后，由后端返回结构化数据（如 PDF 文本页、Excel 表格 JSON），前端只负责渲染，不解析原始二进制
最易被忽略的一点：iPad 用户习惯用“分享表单”而非“打开浏览器输入 URL”，所以你的页面必须支持 PWA 安装、离线缓存基础 JS，并在 beforeinstallprompt 事件中引导用户添加到主屏幕——否则他们下次找不到入口。
