dism拆分合并wim文件大小一致SHA1不同

zjlee51

使用dism拆分wim文件再合并，发现文件大小一致，但SHA1不一致，理论上说应是不对的，不知道这个合并后的文件是否能正常使用（未测试），这种应用场合虽然很少，但有时也是需要的，如在需要重新分区，使用U盘启动恢复系统备份，wim文件一般大于4G，操作实例如下：

Microsoft Windows [Version 10.0.18363.1016]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Windows\system32>Dism /Split-Image /ImageFile:d:\1909.wim /SWMFile:d:split.swm /FileSize:4096

Deployment Image Servicing and Management tool
Version: 10.0.18362.900

The operation completed successfully.

C:\Windows\system32>Dism /Export-Image /SourceImageFile:d:\split.swm /SWMFile:d:\split*.swm /SourceIndex:1 /DestinationImageFile:d:1064.wim /CheckIntegrity

Deployment Image Servicing and Management tool
Version: 10.0.18362.900

Exporting image
[==========================100.0%==========================]
The operation completed successfully.

C:\Windows\system32>


*****************************
名称:1909.wim（拆分文件）
大小: 15234851650 字节 (14 GiB)
SHA1: E3DAC9A3E33B1666857EE5CB9E6FF6F37E040703

名称: 1064.wim（合并文件）
大小: 15234851650 字节 (14 GiB)
SHA1: 90A212967C397182F70619F3555D759F39FD24E5
PS:没想到这个问题引起这么多高手的关注，SHA1的原理的确还不懂，只是按一般常识理解，班门弄斧了；后面查了下官方关于Export-Image命令的说明文件，称”导出映像会删除不必要的资源文件“，因此重新打包成wim文件会与源文件不同，所以即使文件大小一样，SHA1也会不同的情况是正常的。

cnpsouth

如果一致，那才不正常。如果一致那么这种校验还有啥意义

eutgoeru

“使用dism拆分wim文件再合并，发现文件大小一致，但SHA1不一致”正常的，不影响正常使用

盖头

SHA1值只要你动过文件，计算大小一样，里面内容一样，SHA1值都会不一样

hugarninwow

斩断了的东西再怎么拼接，也不可能与原来一样的吧。个人理解，哈希计算本身就是对文件整体性、时间戳的一种印章，拆过了的文件，整体性已经无存了，时间戳也变化了的吧。

Evangelion_air

谁和你说会一样的？
dism创建镜像文件每次都不一样
UUP转wim你自己试试同样的cab文件，每次转出来的wim是一个sha吗？

sutao80216

楼主可以去大致了解一下SHA1的原理和算法，就会明白是怎么回事了。

xiao128255

SHA1肯定会不一样啊

wushijun20

DISM 拆分.WIM文件、合并.SWM都会尝试进行压缩操作。
哈希校验值必然是不一样的。

除非是那种不对文件进行任何压缩、编辑等处理，直接进行二进制分割的操作，才会分割前与合并后文件哈希值一致。

xgfancz

就算再一样，你这个文件的生成时间还是不一样，所以SHA1肯定不一样

默然King

正常，dism导出属于创建了新文件，不是简单的复制。

listen_run

简单来说，一分文件动过，他的sha1就变化了，如果拆分前和合并后一样才有鬼呢

sasalemma

wushijun20 发表于 2020-8-26 21:12
DISM 拆分.WIM文件、合并.SWM都会尝试进行压缩操作。
哈希校验值必然是不一样的。

实际上 dism 对文件操作是一致的，就是文件的排序，还有不修改默认的压缩比，实际上压缩比也是一致的。

只是wim是个容器，容器不只是把文件打包还带了张标签纸，这个才是导致每次wim的sha1变动的原因。

对于二进制来说，就是文件的头部多了一些添置属性的表格。

问题1：同样是容器的txt，带时间属性，但同样文字，在不同时间建立，为什么sha1是一致的？

问题2：同样的txt，修改不同的文件名，里面的内容一致，sha1为什么一致？

问题3：同样的txt，不同文件名，压缩成zip，zip的sha1肯定不一致，同样的文件名呢？

问题4：实际上可以实验一下，同一个txt，在不同时间压缩，比如用winrar，在时间选项卡页面中选择压缩时间为：原始压缩文件时间，这样得到rar是不是sha1一致。

所以哪怕不是分割合并，直接解包wim这个压缩包，再重新打包，只要标签纸的时间一项变动，就会让wim的sha1变动了，除非dism能自定义打包时间。

另dism这个wim分割，和别的压缩工具不一样，这个货是不会把文件分割成二进制的，而且排序都是按照字母顺序？（未验证）

把一个2G的wim，分割文件比如700M，2G里有 A1+A2+A3+...+An，A1=500M，A2=350M，A3=300M，那wim分割的swm就是swm=500M，swm1=650M。

实验1：有空的朋友可以尝试下，一个4G的iso文件打包成wim，然后分割成700M，看看什么情况。

实验2：可以自己建立一些文件 ABCD，然后分割，再解包分割文件的排序。并多次打包，分割，然后你就懂了。

但这个并不是这个话题的重点

重点是：分割按这样的排序，那合并也是同样的排序，就不说标签纸问题了。

所以个人认为并不是分割导致文件的变动，从而影响了sha1，纯粹是打包容器的属性标签纸的信息变动而已。

但对于想使用sha1来检验wim的强迫症来说，是个 打击。



完毕！