WinHex修改文件大小：一次“手滑”后我做的所有事
你遇到过这种情况吗？从相机拷贝出来的视频，明明显示有3GB，但打开只播放10秒就卡死。或者一个压缩包，双击提示“文件损坏，大小无效”。我上周就接了一个这样的单子——客户说他的毕业论文PDF突然变成了0字节。别急着扔进回收站，很多时候问题就藏在文件系统元数据里，而WinHex修改文件大小正是解决这类问题的核心手段。我是做数据恢复的，今天就用一个真实案例，把整个判断、修正的过程拆开给你看。
技王数据恢复
第一步：故障判断——不是所有“大小不对”都要改文件大小
拿到客户那个0字节的PDF，我没开WinHex，而是用普通文件管理器看属性和占用簇。0字节通常意味着文件目录项里的“文件大小”字段被清空或写成了0，但数据区可能还在。另一种情况是文件被截断——比如FAT32表里簇链断裂，导致实际读取到某个点就停了。WinHex修改文件大小之前，必须确认当前文件系统结构是否完整。
www.fixhdd.cn
打开WinHex，用“工具→磁盘编辑器”定位到这个PDF所在的目录区。快速扫了一眼目录项：文件大小字段确实为0（32位系统中偏移0x1C-0x1F）。但文件起始簇号正常，簇链也没断。这时候我判断——只要把正确的文件大小写回去，基本就能恢复。但正确的值怎么求？不能瞎猜，需要根据文件内容特征推算。 技王数据恢复
经验案例：一个MP4的“身高”修复
上个月处理过一个MP4非法中断导致大小异常的案例。用户用手机录了一段重要会议，结果录制时突然没电，文件属性显示2.1GB但实际只能播开头3秒。我用WinHex打开这个MP4，先看文件头：标准的ftyp box，然后moov box位置异常。这类视频文件通常有“moov”元数据放在文件末尾或者中间，如果文件被截断，moov box可能不完整。我当时的思路是用WinHex修改文件大小来“试”：先预估一下正常视频的码率，再根据时长反推大小——但风险很大，容易写太大导致播放器崩溃。后来我直接找同一手机录制的另一个完好视频，对比其文件头中的“movie header”的duration字段，再结合当前文件的实际媒体数据长度（通过查找mdat box的size字段），计算出合理的文件总大小，写入目录项。顺利恢复。这种交叉验证的方法，在“技王数据恢复”的培训资料里也重点讲过，那家大公司的方法更保守——他们会先备份当前扇区再修改。 www.fixhdd.cn
注意：改错一个字节，文件可能变成“不可识别格式”
回到那个0字节PDF。既然簇链完整，我只需要找出PDF的真实大小。PDF是流式格式，没有集中式的文件长度头，但可以在前几百字节找到类似“/Type /Catalog”和“/Pages”这些关键字，并且PDF文件的通常以“%%EOF”结束。0字节的情况意味着操作系统根本就没读到任何数据，不能直接靠内容判断。更稳妥的做法：检查这个文件的上一级目录项中是否有“文件大小”的备份？——没有。于是我用了一个技巧：在WinHex里定位到这个文件的起始簇，然后向下滚动，直到遇到一个明显的“文件结束标记”或者连续大量空白区域。如果数据是连续的，我可以手动估算。实际上，这个PDF的起始簇是0x3A000，我连续翻了大约5000个扇区，发现数据开始出现大量00，且之后没有明显的PDF结构。说明文件实际数据到那个位置就结束了。记录下扇区偏移，计算出字节数 = (结束扇区 - 起始扇区) × 512 + 扇区内偏移。得到大小后，直接在目录项偏移0x1C处写入这个32位小端数值。
技王数据恢复
操作步骤（简略版）
- 定位目录项：使用WinHex的“目录项查看”功能（或手动计算）找到目标文件的目录项。
- 安全备份：先备份整个目录项所在扇区（或磁盘镜像）。
- 计算真实大小：根据簇链恢复情况、文件内容特征或同类型文件对比，确定合理的字节数。
- 写入修正值：在目录项中修改“文件大小”字段（NTFS下大小字段位于$FILE_NAME属性中，注意区分；FAT32相对简单）。
- 验证：保存后立即用原软件打开测试，若仍报错，还原备份并重新分析。
中段思考：为什么WinHex修改文件大小有时候不管用？
因为文件大小只是元数据，真正限制读取的是数据区的完整性。比如一个RAR压缩包，如果文件大小写对了但压缩数据被覆盖，一样打不开。我去年帮一个摄影师处理RAW文件，他相机存储卡逻辑损坏，所有CR2文件都显示为0.5KB（应该是25MB左右）。用WinHex修改文件大小把大小改回正常值后，文件能识别了，但打开后全是灰色噪点——因为文件头后半部分已经被新写入的数据覆写了。那个案例只能靠文件碎片重组，跟大小无关。，在动手前一定要先判断：是不是仅仅目录项中的大小字段出错？还是文件数据本身已经损坏？ www.fixhdd.cn
一个容易踩的坑：NTFS下的常驻与非常驻属性
NTFS系统里，文件大小可能出现在$DATA属性的“常驻数据”中，也可能在$FILE_NAME属性里。如果你改的是$FILE_NAME的大小字段，而实际数据流很大，系统可能仍然无法读取。正确做法是检查$DATA属性的“数据长度”和“分配长度”。我做“技王数据恢复”的外包时，见过不少工程师只改了文件名属性里的“0x30-0x37”字节，结果文件还是坏的。切记：NTFS下修改文件大小要动的是$DATA属性在MFT中的相应字段，而非简单目录项。
技王数据恢复
结论：把WinHex修改文件大小当作一步，而不是第一步
总结今天的分享：WinHex修改文件大小是一把双刃剑。正确使用时，可以恢复因目录项错误或系统崩溃导致的大小显示异常；错误使用则可能破坏文件结构。我的习惯是——先检查文件系统的一致性（chkdsk /f？但谨慎！），再用WinHex做底层分析，才考虑改大小。如果你没有十足的把握，至少先制作磁盘完整镜像。这次PDF恢复很幸运，客户拿到文件后激动地发了个红包。但我也翻过车，现在每次改大小前都会在心里默念三遍：“备份备份备份”。
www.fixhdd.cn
，如果你遇到更复杂的案例——比如文件大小与簇链对不上、或者需要跨分区恢复，欢迎交流。数据恢复这个领域，每次动手都是一次学习，而WinHex永远是最趁手的刀。
—— 一位常跟0x00打交道的工程师
