saz文件本质是带特定结构的zip包，应直接用zipfile解压；核心数据在raw/目录，需结合entry.json解析请求响应，https明文需fiddler解密配置且受证书固定限制。
SAZ 文件本质是 ZIP，别用专用解析器硬刚
SAZ 不是自定义二进制格式，而是带特定目录结构的 ZIP 包。强行找“C# SAZ 解析库”会绕远路，甚至踩进过时、不维护的坑（比如早期 FiddlerCore 的私有序列化逻辑已弃用）。直接解压最稳，也兼容所有 Fiddler 版本导出的 SAZ。
- 用
System.IO.Compression.ZipFile解压到临时目录，比流式解析更容错 - 注意 SAZ 可能含加密（勾选了“Encrypt with password”），此时
ZipFile.ExtractToDirectory会抛InvalidDataException，需提前捕获并提示用户 - 核心数据在
raw/子目录：每个请求对应一对xxx_0.txt（request）和xxx_1.txt（response）
从 raw/xxx_0.txt 读 HTTP 请求头和 body 要分两步处理
Fiddler 保存的原始文本不是标准 HTTP 报文——它把 headers 和 body 用空行隔开，但 body 前可能插了额外元信息（如 X-Fiddler-Generated: true），且 body 编码不统一（可能是 UTF-8、UTF-16、或二进制 blob）。
- 先按行读取，遇到第一个空行就停，前面是 headers（用
String.Split(':')拆键值，注意冒号后可能有空格） - 空行之后的内容才是真实 body；但得看
Content-Type头：若含charset=，按指定编码；否则默认用UTF8；若含application/octet-stream或无Content-Type，建议保留为byte[]避免乱码 - 别直接
File.ReadAllText整个文件——大文件（如图片响应）会 OOM
Session ID 和时间戳藏在 entry.json 里，不是文件名
很多人以为 raw/123_0.txt 的 123 是 session ID，其实只是 Fiddler 内部索引。真正关联请求/响应、带时间戳和状态码的是同级目录下的 entry.json（每个请求一个 JSON 文件）。
-
entry.json中id字段才是全局唯一 Session ID；startedDateTime是 ISO8601 时间；response.status是状态码 - JSON 是 UTF-8 无 BOM，可用
System.Text.Json.JsonSerializer.Deserialize直接反序列化（.NET Core 3.0+） - 注意：Fiddler 有时会把重定向链拆成多个 entry，但
entry.json里url字段始终是最终请求地址，不是原始跳转 URL
解析 HTTPS 流量时，body 可能为空或乱码
SAZ 里 HTTPS 请求的 request body 和 response body 默认不保存明文——Fiddler 默认只记录 headers，除非你明确勾选了 “Decrypt HTTPS traffic” 并安装了 Fiddler Root Certificate。
- 检查
entry.json中request.bodySize和response.bodySize：若为 0，基本确定没解密 - 即使勾选了解密，某些 App（如 iOS 15+ 或 Android 12+ 的 Target SDK ≥31）会强制证书固定（Certificate Pinning），导致 Fiddler 无法解密，SAZ 中 body 仍是加密后的 TLS 记录碎片
- 此时不要试图“修复” body，应转向分析 headers、URL、timing 字段（如
timings对象里的send/wait时间）
最麻烦的其实是混合流量：同一个 SAZ 里部分 HTTPS 请求可解密、部分不可。得逐个查 entry.json 的 response.bodySize 和 response.content.mimeType 才能判断是否值得继续解析 body。
