<p>apache tika 无法直接在 c# 中使用，需通过 rest 调用本地运行的 tika-server.jar（依赖 jdk 8+），c# 侧用 httpclient 复用实例发送 put 请求至 /tika 或 /meta 接口，注意编码、字段名大小写、格式兼容性及超时设置。</p>
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 这种非标准头。
容易踩的坑：写死 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 会按后缀解析，结果把逗号当分隔符全吃掉。
