AskaEth
48e41886ba
后端 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」）⇒ 客户端沿用既有通用文案「读不到」， 不自己拼一句假装是服务端说的。