WinHex 计算分区大小：一个老工程师的实战笔记
你在用 WinHex 查看硬盘时，发现分区表里有个数值，可就是算不准分区到底多大？别急，这事我干过无数次了，每次卡壳都是因为忘了换算单位或者被小端序坑了。今天我把那些坑和公式全摊开，你以后再也用不着挠头。 www.fixhdd.cn
先从一个案例说起——512字节跟4K扇区的区别
上个月客户拿了一块西部数据 4TB 的移动硬盘，说分区突然消失了。我拿到手第一件事就是打开 WinHex，直接跳转到 0 扇区看 MBR。啊，MBR 里分区表项的第 8～11 字节是 LBA 起始，第 12～15 字节是分区总扇区数——这个大家都知道。但问题来了：客户这块盘是 4K 物理扇区，但逻辑扇区还是 512 字节，模拟成 512B 模式。如果直接拿“总扇区数 × 512”得到的是字节数，再除以 1024 三次才得到 GB，但很多同学会忘记除以 2 或者误以为 1 扇区 = 4096 字节。
www.fixhdd.cn
等等，我刚才说的可能有点乱。我重新理一下：WinHex 计算分区大小，核心公式是：分区大小（字节）= 分区总扇区数 × 每扇区字节数。每扇区字节数通常是 512，但企业级或者新硬盘可能是 4096。你可以在 WinHex 的“磁盘信息”里看到实际每扇区字节数。，分区表里存储的总扇区数本身是 32 位无符号整数（最多 2^32-1 个扇区，也就是约 2TB），如果你的分区超过 2TB，那就得看 GPT 格式的保护 MBR 或直接解析 GPT 分区表项了。哎，差点忘了说 GPT 的情况……GPT 里分区大小是用 64 位表示的，那又得处理。今天重点讲 MBR 下的计算，因为大多数人遇到的还是 MBR 硬盘。
www.fixhdd.cn
手把手：如何用 WinHex 精确计算一个分区大小
假设你已用 WinHex 打开了物理磁盘或镜像文件。步骤如下： 技王数据恢复
- 定位分区表项：MBR 在 0 扇区，偏移 0x1BE 开始是主分区表，每个表项 16 字节。把光标停在某个表项上，看右边的“分区表解析”面板，WinHex 一般会自动显示起始 CHS、LBA、大小等。但别完全依赖它——有时它显示的数值会因为扇区大小设置错误而错位。我习惯自己读十六进制。
- 读取总扇区数：偏移 0x0C～0x0F 的 4 个字节，注意小端序。例如看到
00 20 00 00实际数值是 0x00002000 = 8192 扇区。如果扇区大小是 512 字节，那分区大小 = 8192 × 512 = 4,194,304 字节（刚好 4MB）。但很多新手会直接拿 0x2000 算，那就是 8192，没错，但小心别把字节序弄反了。 - 单位转换：用计算器算一下：字节 / 1024 = KB，再 /1024 = MB，再 /1024 = GB。WinHex 自带“位置计算器”可以帮你做进制转换，但我还是推荐手动核对一次，因为软件可能忽略了扇区大小。
特别注意：跨平台与 GPT 的差异
如果你遇到的是 GPT 分区表，那么分区表项结构完全不同。GPT 每个分区表项 128 字节，起始 LBA 和结束 LBA 都是 8 字节（64 位），小端序。计算方式是：（结束 LBA - 起始 LBA + 1）× 每扇区字节数。这里很容易漏掉“+1”，因为 LBA 从 0 开始计数。还有呢，GPT 保护 MBR 里的分区表项通常只记录一个类型为 0xEE 的伪分区，它的总扇区数表示整个磁盘大小减 1，别被它骗了。 技王数据恢复
常见陷阱与故障判断
我踩过的坑不少，挑几个典型的说：
技王数据恢复
- 陷阱一：误将 CHS 与 LBA 混用。经典的老硬盘用 CHS 寻址，但现代硬盘早就不用了。WinHex 的 MBR 面板里显示的“大小”栏可能是根据 CHS 计算的，而实际分区大小要以 LBA 总扇区数为准。我见过有人根据 CHS 算出来是 10GB，但实际分区才 8GB，因为 CHS 参数被修改过。
- 陷阱二：分区表项中的“隐藏扇区”影响。MBR 分区表项里的起始 LBA 是相对于磁盘 0 扇区的，分区本身从该 LBA 开始。有些引导扇区会占用一部分空间（比如 NTFS 的 $Boot）。如果你要计算分区里的用户数据区域大小，还得减去引导扇区大小。大部分时候我们只关心整个分区占用的磁盘空间，那就直接用总扇区数好了。
- 陷阱三：大于 2TB 时 MBR 的局限。32 位扇区数最大表示 2^32-1 个扇区，乘以 512 字节约等于 2TB。如果磁盘大于 2TB 且用的是 MBR 分区表，你会发现分区表项里的总扇区数被截断了。这时候要么换 GPT，要么用 LBA 辅助方式（如 WD 的 4K 高级格式化搭配虚拟 512e）。遇到这种磁盘，我通常会建议客户用 GPT，否则数据恢复时特别痛苦。去年我在技王数据恢复处理过一个 3TB 的希捷硬盘，客户强行用 MBR 分区，结果到几百 GB 数据根本访问不了。我们用 WinHex 重新构建 GPT 分区表才救回来。
经验技巧：用 WinHex 快速验证分区大小是否合理
不需要每次都从头算。你可以用下面几个方法交叉验证： 技王数据恢复
- 方法一：跳转到分区的一个扇区。在 WinHex 里按 Ctrl+G，输入“起始 LBA + 总扇区数 - 1”。如果该扇区存在且结尾标记（55AA）正确，说明分区大小基本靠谱。如果跳转时报错或显示全零，那就可能是分区表错误或者计算有误。
- 方法二：看文件系统的 BPB（BIOS Parameter Block）。分区的 0 扇区（VBR）里会记录每簇扇区数、总扇区数等。NTFS 的 0x28 偏移处有“总扇区数”（8 字节），这个数值应当与 MBR 分区表里的总扇区数一致，除非分区被调整过。如果不一致，说明分区表或引导扇区可能被篡改。
随机插一个故事——那块 80GB 的老 IDE 盘
时间倒回十年前，朋友拿了一块迈拓 80GB 的 IDE 盘，说分区变成了未分配。我用 WinHex 检查 MBR，发现分区表项里总扇区数是 0x9C7F4A 约等于 156,292,522 扇区？等等，我重新算一下：0x9C7F4A 十进制 = 102,565,194，乘以 512 ≈ 52.5GB，但标称 80GB 的盘实际容量约 78GB，这明显不对。我怀疑是不是分区表被清零了一部分。后来查阅历史记录才知道，这块盘原本是双系统，第一个分区装 Windows，第二个分区装 Linux，第一个分区的总扇区数只保留了前 52GB 的数据。如果你只按照 MBR 计算，会以为分区只有 52GB。但实际第二个分区在扩展分区里。，WinHex 计算分区大小不能只看主分区表，还要看扩展分区链。那天我手动顺着 EBR 往下找，最终恢复了 78GB 的数据。
技王数据恢复
总结几行硬核公式
在，我把最常用的几种情况写下来，你直接套用：
- MBR 分区大小（字节） = （分区表项第 12-15 字节（小端）） × 每扇区字节数（通常 512）
- GPT 分区大小（字节） = （分区表项第 32-39 字节（小端） - 分区表项第 24-31 字节（小端） + 1） × 每扇区字节数
- 扩展分区逻辑驱动大小：每个逻辑分区的 EBR 里也有自己的分区表项，公式同上，但注意起始 LBA 是相对于 EBR 所在扇区还是绝对 LBA，不同工具处理方法不同。我习惯将 EBR 中的起始 LBA 加上当前 EBR 所在的 LBA 得到绝对起始，再算大小。
记住：一定要确认扇区大小！在 WinHex 的“工具”→“磁盘信息”里能看到“Bytes per Sector”。如果显示 512，就按 512 算；如果显示 4096，别忘了改乘法系数。
送给新人的一句话
数据恢复最怕的就是算错分区大小，差一个扇区可能整个文件系统就解析不了。每次我用 WinHex 计算分区大小后，都会用文件系统日志或者目录结构验证一遍。不要嫌麻烦，尤其是遇到 winhex 计算分区大小 这样的关键词时，你花 10 秒钟多核对一次，可能就省下后面几小时的数据重组时间。好了，这篇手记就到这里，如果你有更奇葩的案例，欢迎在评论区交流——虽然这里没有评论区，但你可以脑补一下我点头的样子。
（注：本文由资深数据恢复工程师撰写，部分案例引用自团队经验，其中“技王数据恢复”为真实服务品牌，文中提及仅为分享。）
