解析过程：

1. 入口判断：先确认版本号是 1.3，随后进入扩展块解析流程，位深初始值默认为 8 bpc。
2. 找扩展块：读取基础块第 126 字节，得到扩展块数量。每个扩展块固定 128 字节，紧跟在基础块之后。逐个检查这些扩展块。
3. 确认是 CEA 块：只有标签为 0x02 的才是 CEA-861 扩展块（HDMI 设备通常带一个）。同时读取块内的 DTD 起始偏移，它划定了数据块集合的范围（从头部的第 4 字节开始，到 DTD 起始位置结束）。
4. 遍历数据块：在数据块区域内，每个块由一个头字节加若干数据字节组成。头字节的高 3 位是标签码，低 5 位是数据长度。逐块扫描，找标签码为 0x03 的"厂商自定义数据块"（VSDB）。
5. 确认是 HDMI 的 VSDB：VSDB 开头 3 个字节是厂商识别码（OUI）。只有识别码等于 HDMI 标准规定的 00-0C-03，才是 HDMI 专用的 VSDB，其他厂商的块直接跳过。
6. 读取深色标志：在 HDMI VSDB 的第 7 个字节（偏移 6）里存着 Deep Color 支持标志，按位表示：第 4 位代表 30 bit（即每通道 10 bpc），第 5 位代表 36 bit（12 bpc），第 6 位代表 48 bit（16 bpc）。
7. 得出结论：按"能支持的最高位深优先"的原则取值——三个位从高到低检查，第一个置位的即为结果；若一个都没置位，说明设备只支持 8 bpc。
   兜底逻辑：如果根本没有扩展块、扩展块不是 CEA 类型、找不到 HDMI VSDB，任何一环失败，最终结果都保持默认的 8 bpc。

流程：版本确认 → 数扩展块 → 验 CEA 标签（0x02）→ 遍历数据块找 VSDB（标签 0x03）→ 校验 HDMI OUI（00-0C-03）→ 读第 7 字节 Deep Color 标志 → 取最高支持位深。
标志位映射：bit6 → 16 bpc，bit5 → 12 bpc，bit4 → 10 bpc，均未置位则 8 bpc。
任一环节失败（无扩展块 / 非 CEA / 非 HDMI VSDB），结果保持默认 8 bpc。

解析的是接收端最大能力，不是当前实际协商/输出的位深——实际输出还取决于源端和链路协商。

结论：解析不出来。EDID 里没有这个信息。
Windows 显示的是“当前链路实际输出的位深”，这是运行时状态，由源端（GPU）决定，不存在于 EDID 中——EDID 只是显示器的静态能力描述。想得到和 Windows 一样的值，必须换数据源：
方案一：查询本机图形栈的实时输出状态（Windows 就是这么做的）

• Linux/DRM 体系（OpenHarmony 图形后端）：通过 drmModeObjectGetProperties 读取 connector 的 max bpc、Colorspace 等属性，实际生效值由显示驱动上报
• DisplayPort 设备：可通过 AUX 通道读 DPCD 链路状态
• HDMI：无标准寄存器可查“当前值”，实际位深由源端配置决定——所以源端驱动的输出配置就是权威值
  在 OpenHarmony 上落地：向 Composer HDI / 显示驱动新增“当前信号格式”查询接口，window_manager 从 HDI 拿实时值，EDID 解析仅作能力参考。