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 会按后缀解析，结果把逗号当分隔符全吃掉。
