AskaEth
48e41886ba
feat(documents): App 内预览对非文本拒收 —— 跟上 v0.61 的 .pdf
后端 v0.61 把文档白名单 22 → 23 项（新增 .pdf）并改成（扩展名, 字节嗅探）成对裁决，
读侧 MIME 如实下发 application/pdf。而 W11 的附件预览是把字节当 UTF-8 文本渲染的
（那时白名单里除 .pdf 外全是文本类）⇒ 一旦点开别的端发来的 PDF 附件，预览就是一整屏
二进制乱码，像文件坏了。这次堵的是这个兼容洞，不是新功能。
- 选文件器加 application/pdf：原先刻意不列（那时必被后端 415 拒），现在 PDF 在选择器里
不该是灰的，服务端收得下。
- 新增 DocumentPreviewGate（纯函数）：mime 非空时只看服务端那次字节嗅探（以 text/ 开头
判为文本，其余一律非文本，未知 mime 也判非文本——两侧代价不对称，误判成文本正是本闸
要消灭的乱码）；mime 缺失/空白时按扩展名兜底（白名单里只有 .pdf 是非文本），这条兜底
服务的是待发附件（它只有本地 URI 与显示名）。大小写不敏感并剥掉 ; charset 参数。
- 弹层新增 plan 参数：判为非文本时正文区留空、只留一句人话并指路两条出口——弹层照常打开，
文件名/体积/字数/状态与两条出口一个不少，也绝不假装加载失败（字节其实是取回来的，
只是本端不渲染它）。
- 两条出口刻意未动：打开用 DTO 的 mime（PDF 就该交给 PDF 阅读器，不用通配符），保存继续
传 */*（W11 实测结论：SAF 会按 mime 给文件名补扩展名）。
- 测试 766 → 775（DocumentPreviewTest 新增 9 条：闸的判定矩阵、扩展名兜底与大小写、
未知 mime 拒收、待发附件接线、以及 PDF 的打开类型不是通配符）。
未做（缺口留给主代理登记 02）：DTO 只有 status=unreadable，没有服务端那句原因文案
（含「图片型/无文本层 PDF，需要 OCR」）⇒ 客户端沿用既有通用文案「读不到」，
不自己拼一句假装是服务端说的。
2026-10-04 21:16:29 +08:00
..
2026-10-04 21:16:29 +08:00
2026-09-08 21:48:40 +08:00
2026-09-08 20:40:58 +08:00