file api 可获取 name、size、type、lastmodified 和 webkitrelativepath 等基础元数据，但 type 不可靠，真实格式判断和深度元数据提取需后端解析或专用库协作完成。
直接用浏览器原生 File API 可以读取基础元数据（如名称、大小、类型、最后修改时间），但无法可靠判断真实文件格式，也不能提取内容级信息（如图片尺寸、PDF作者、视频时长）。要实现“格式智能判断 + 深度元数据提取”，必须结合后端解析能力或专用库。
File API 能拿到哪些元数据？
用户选择文件后，通过 input[type="file"] 获取的 File 对象本身提供以下属性：
- name：文件名（含扩展名，但可被伪造）
- size：字节大小（准确）
-
type：浏览器根据扩展名或 MIME 类型推测的值（
image/jpeg等），不可信，例如把 .exe 改成 .jpg 就会返回image/jpeg - lastModified：最后修改时间戳（毫秒）
- webkitRelativePath（部分浏览器）：上传时的相对路径（仅限目录上传）
这些信息适合前端快速校验（如限制大小、过滤明显错误扩展名），但不足以支撑安全或业务级判断。
为什么不能只靠 type 属性判断格式？
浏览器的 File.type 是基于文件扩展名或头部简单 sniff 的结果，极易被绕过。实际场景中常见问题包括：
- 用户手动改扩展名（.pdf → .txt），
type变为text/plain，但内容仍是 PDF - 无扩展名文件（如服务器生成的临时文件），
type为空字符串 - Office 文档、压缩包等二进制文件，
type常返回application/octet-stream，失去区分度
真正可靠的格式识别需读取文件头部字节（magic number），这在前端可用 FileReader + ArrayBuffer 实现初步 sniff，但复杂格式（如 DOCX、ZIP 内嵌结构）仍需后端解析。
如何实现真正的智能格式判断与元数据提取？
推荐分两层协作：前端采集原始文件 + 后端执行深度解析。常用方案包括：
- Apache Tika（Java）：支持 1000+ 格式，自动检测类型、提取文本、获取标准元数据（作者、创建时间、页数、语言等），适合 Spring Boot 或微服务集成
-
FilePond + 自定义处理器：上传时调用
loadImage提取图片宽高；对视频可转交 FFmpeg 或服务端提取时长/码率 -
AI 驱动元数据提取（如智能文档 API）：传入
doc_id和提示词（如“提取标题、作者、关键词”），由模型理解语义并结构化输出，适合非标准或扫描件文档 -
轻量级前端 sniff（仅限简单场景）：用
FileReader.readAsArrayBuffer()读前 4–8 字节，比对常见 magic number（如 PNG 是89 50 4E 47，PDF 是25 50 44 46），但不覆盖 ZIP、DOCX 等复合格式
典型工作流示例
以上传一份合同 PDF 为例：
- 前端用
File对象获取name、size、lastModified，显示预览信息 - 将文件 Blob 上传至后端接口（如
/api/v1/metadata/extract） - 后端用 Tika 解析，得到真实 MIME 类型
application/pdf、作者张三、创建时间2026-03-10、页数12 - 若需 AI 提取“甲方名称”“签约日期”，再调用智能文档 API 并传入定制 prompt
- 最终元数据统一存入数据库，供搜索、权限控制或归档使用
不复杂但容易忽略
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
