Java 17 音频转写上传前校验：大小、MIME、超时与审计 ID
内容提要
文章介绍用 Java 17 实现音频转写上传前的本地校验：检查文件可读性、扩展名和 20MB 业务上限，生成 SHA-256 短审计 ID，再以带 45 秒超时的 multipart 请求提交转写。日志仅保留不可逆哈希，不含音频或全文。强调授权、隐私与删除机制应优先于便利，扩展名校验不等于安全，生产环境应检测 MIME、时长并采用流式上传。
延伸解读
本地校验的边界与生产增强
文章示例仅用扩展名和20MB业务上限做初步过滤，但明确强调扩展名校验不等于安全。生产环境应补充MIME检测、解码器可读性验证和音频时长检查，避免伪装文件或损坏文件进入转写流程。此外，示例使用readAllBytes将整个文件读入内存，大文件场景应改为流式multipart上传，防止内存溢出。
审计ID的作用与隐私风险
SHA-256截断生成的16位十六进制审计ID用于关联上传事件，便于失败重试和客服定位，且日志不记录音频或全文。但文章提醒该ID不可逆却不应作为安全认证或公开标识，也不能替代加密。若切分音频，需保存片段序号、原文件ID与合并规则，确保可追溯性同时避免泄露敏感信息。
授权与删除机制优先于便利
文章反复强调语音常含姓名、客户信息和商业秘密，最小化收集、告知和删除机制必须先于便利性。内部会议不天然等于所有参与者同意，秘密录音、未成年人敏感内容或需法律效力的逐字证据均不适用此方法。组织若无法回答谁能听到、保存多久、如何删除，就不应急于开放转写。
转写质量与使用目的绑定
会议检索更看重术语、项目代号和数字，客服质检更看重时间戳、频道和原片段追溯。模型断句、术语和说话人归属可能出错，重要决策必须回听原声或由参与者确认。摘要不应覆盖原始转写，也不能把模型补出的说话人名称当作事实。失败恢复时，文件哈希和会话ID可防重复上传，但到期删除应覆盖原音频、转写、搜索索引和缓存。
Q&A
Java 17 音频转写上传前需要做哪些本地校验？
需要检查文件是否为常规可读文件、扩展名是否在允许列表（.mp3、.mp4、.m4a、.wav、.webm）内，以及文件大小是否超过业务设定的 20MB 上限。
为什么扩展名校验不能保证音频文件安全？
扩展名只是文件名的一部分，可以被轻易伪造，不能证明文件真实类型或内容安全。生产环境还应检测 MIME 类型、解码器可读性和音频时长。
如何生成音频文件的审计 ID？
读取文件全部字节，计算 SHA-256 哈希，然后截取前 16 个十六进制字符作为短审计 ID。
上传转写请求时超时时间设置为多少？
单次 HTTP 请求的超时时间设置为 45 秒，同时连接超时为 10 秒。
日志中应该记录哪些信息以保护隐私？
日志只应记录不可逆的短哈希审计 ID，不应包含原始音频或转写全文。
生产环境处理音频转写时有哪些常见错误需要避免？
常见错误包括：将密钥拼进命令行或日志导致泄露；未检查 HTTP 状态码就把错误 JSON 当转写文本；失败后盲目重试导致重复上传敏感录音；误以为内部会议已获得所有参与者同意。
音频转写功能适合哪些场景？
适合内部纪要草稿、访谈初稿、客服质检等已完成授权与留存设计的场景。
音频转写功能不适合哪些场景？
不适合秘密录音、未成年人敏感内容，或需要法律效力的逐字证据等场景。
