iPad上HTML5 FileReader读取PDF失败主因是系统沙盒限制,非代码错误;应优先用readAsDataURL配合pdfjs解析,超30MB改用系统原生链路。
FileReader 读取 PDF 失败:iPad 上的沙盒限制是主因iPad 的 Safari(及所有基于 WebKit 的 WebView)对 FileReader 的行为有严格限制,尤其是读取二进制大文件(如 PDF)时。不是代码写错了,而是系统层面拒绝了完整 ArrayBuffer 读取——FileReader.readAsArrayBuffer() 在 iPad 上常静默截断、返回空或触发 onerror 但无具体错误码。
readAsArrayBuffer 可能直接跳过 onload
input[type="file"] 返回的 File 对象在 iPad 上可能不携带完整元数据或底层句柄,导致后续解析失败pdfjs-dist)依赖完整字节流,一旦 FileReader 提供的是截断 buffer,就会报 InvalidPDFException 或卡在 loading 状态HTML5 标准本身没规定 PDF 导入能力,真正起作用的是浏览器是否允许 JS 访问原生文件系统。iPad Safari 默认禁用 webkitdirectory、不支持 showOpenFilePicker()(仅 macOS Safari 16.4+ 支持),且不开放 FileSystem Access API。
showOpenFilePicker({ types: [{ description: 'PDFs', accept: { 'application/pdf': ['.pdf'] }}] }),在 iPad Safari 中会直接抛 TypeError: showOpenFilePicker is not a function
input[type="file"] + chan
ge 事件是最兼容方式,但必须配合 event.target.files[0] 即时处理——延迟读取(比如放进 Promise 队列或 setTimeout)容易被 iOS 后台策略回收文件引用URL.createObjectURL(file) 后再 fetch,iPad Safari 对 blob URL 的生命周期极短,常出现 net::ERR_FILE_NOT_FOUND
与其硬刚 FileReader,不如让 iPad 自己处理 PDF,再把结果交还给网页。这是目前最稳定、适配 iOS 17–18 的方案。
触发系统选择器,确保 accept 明确限定类型,避免混入不可读文件File 后立即用 FileReader.readAsDataURL()(非 ArrayBuffer)——Base64 虽体积增 33%,但在 iPad 上成功率接近 100%pdfjs-dist:pdfjsLib.getDocument({ data: atob(dataUrl.split(',')[1]) }).promise,注意 atob 解码前需校验是否含空格/换行window.open(dataUrl) 委托系统「图书」App 打开,或用 navigator.share({ files: [file] })(需 HTTPS + 用户手势)唤起分享面板导出到「文件」App用户从微信、邮件、AirDrop 接收的 PDF,经常被系统标记为 application/octet-stream 或空 type 字段,导致 accept=".pdf" 过滤失效或后端拒收。
change 回调里检查 file.type,但不要直接 reject;应 fallback 到扩展名判断:file.name.toLowerCase().endsWith('.pdf')
application/pdf、application/octet-stream 和空字符串,再用文件头(file.slice(0,4).arrayBuffer() 检查 %PDF)二次确认dataURL + pdfjs 是当前最可控的折中路径,但超过 50 MB 就该果断切到原生链路——这不是退让,是尊重平台边界。