Apache Tika 无法直接在 C# 中使用，需通过 REST 调用本地运行的 tika-server.jar（依赖 JDK 8+），C# 侧用 HttpClient 复用实例发送 PUT 请求至 /tika 或 /meta 接口，注意编码、字段名大小写、格式兼容性及超时设置。
Apache Tika 在 C# 里不能直接用，得走 REST 或进程调用
Apache Tika 是 Java 写的，没有官方 C# 绑定。你搜 TikaClient 或 TikaSharp 会看到几个第三方封装，但它们本质都是在后台启动 java -jar tika-server.jar，再通过 HTTP 调用 /tika 或 /meta 接口。直接 NuGet 安装个包就想解析 .docx/.pdf/.eml 就出文本？不行。
常见错误现象：FileNotFoundException 找不到 tika-server.jar，或调用 http://localhost:9998/tika 返回 404/500，其实是 Java 环境没配、端口被占、JAR 没运行。
- 必须提前装好 JDK 8+（不是 JRE），并确保
java -version能执行 - 下载对应版本的
tika-server.jar（推荐从 tika.apache.org 拿 latest stable，别用 snapshot） - 启动命令别写错：
java -jar tika-server.jar --port 9998；加--host 0.0.0.0才能被其他机器访问（内网调试时容易漏） - C# 侧用
HttpClient发PUT请求到/tika（文本提取）或/meta（元数据），Body 是文件流，Content-Type设为application/octet-stream
用 HttpClient 调 Tika Server 提取文本：POST 和 PUT 别搞混
Tika Server 的文本提取接口是 PUT /tika，不是 POST。很多 C# 示例抄了 curl 命令但没注意动词，结果返回空响应或 405 错误。
使用场景：上传一个 .xlsx 文件，要拿到纯文本内容（不含公式、样式、单元格位置）。
-
HttpClient实例必须复用（别每次 new），否则高并发下会耗尽 socket - 上传大文件（>10MB）时，设
HttpClient.Timeout = TimeSpan.FromMinutes(10)，Tika 解析 PDF 可能卡住几秒 - 响应体是纯文本，但编码不一定是 UTF-8——比如含中文的 .doc 文件可能返回 GBK 字节，需用
Encoding.Default解码（Windows 环境下通常 OK） - 示例关键行：
await client.PutAsync("http://localhost:9998/tika", new StreamContent(fileStream))
提取元数据时字段名大小写敏感，且不同格式返回键不同
调 /meta 接口返回的是 JSON，但字段名来自 Apache Tika 内部的 Metadata 类，不是标准化 schema。比如 Author 在 .pdf 里可能是 Author，在 .docx 里却是 creator，而 .eml 里又变成 X-Originating-IP 这种非标准头。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
容易踩的坑：写死 json["Author"]，结果 .xlsx 文件根本没这个 key，直接 NullReferenceException。
- 永远用
json.TryGetValue("Author", out var author)或类似安全取值方式 - 常用字段建议 fallback 链：
Author→creator→meta:author→xmp:CreatorTool - 日期类字段（如
Creation-Date）是字符串，格式不统一（2023-04-01T12:34:56Z或Wed, 1 Apr 2023 12:34:56 GMT），别直接DateTime.Parse()，先试DateTime.TryParseExact() - 部分格式（如加密 PDF）元数据为空，Tika 不报错也不抛异常，只返回空 JSON 对象
上百种格式 ≠ 全都可靠，PDF 和 Office 是主力，小众格式得实测
Tika 官网说支持“1000+ MIME 类型”，但实际在 C# 场景中，真正稳定可用的是 PDF、DOC/DOCX、XLS/XLSX、PPT/PPTX、TXT、HTML、XML、RTF、EML、MSG（需搭配 Outlook Interop）、ZIP 内嵌文件。像 .pages、.numbers、.vsdx、.dwg 这些，要么解析失败，要么只返回乱码或空字符串。
性能影响：单个 .pdf（200页带图）平均耗时 800ms~3s，.xlsx（10万行）约 1.2s；但一个 .msg 文件如果带 10MB 附件，Tika 会尝试解压所有嵌套，可能卡住 20s+ 且不超时。
- 上线前必须拿真实业务文件做回归测试，尤其注意扫描版 PDF（OCR 不开）、密码保护 PDF（默认跳过）、宏启用的 .xlsm（可能被拦截）
- 不要依赖
detect接口判断类型——它靠魔数和扩展名，对无后缀或改名的文件极不准，不如自己用Path.GetExtension()+ 白名单预过滤 - 遇到解析失败，Tika 默认返回 HTTP 200 + 空体，不是 5xx。必须检查响应长度和内容是否为空字符串，再决定重试或降级（比如只读文件名和大小）
复杂点在于：你没法绕过 Java 进程，也没法完全屏蔽格式差异。每个文件都得当特例看，尤其是客户传来的“看起来是 Excel 其实是 CSV 改后缀”这类情况——Tika 会按后缀解析，结果把逗号当分隔符全吃掉。
