Java/zip:为什么非确定性地创建 .jar 文件? [英] Java/zip: Why are .jar files non-deterministically created?

问题描述

我从未真正研究过它，但现在我意识到我无法轻松构建两个相同的 .jar 文件.

I never really looked into it but now I realized that I can't easily build two identical .jar files.

我的意思是，如果我构建两次，不做任何更改，我会得到完全相同的大小，但 .jar 的校验和不同.

I mean, if I build twice, without changing anything, I get the exact same size but different checksums for the .jar.

所以我很快进行了一些测试(基本上是解压，sort -n -k 5'ing 然后diff'ing)来看看.jar 里面的所有文件都是相同的，但 .jar 是不同的.

So I quickly ran some test (basically unzipping, sort -n -k 5'ing and then diff'ing) to see that all the files inside the .jar were identical, yet the .jar were different.

所以我用一个普通的 .zip 文件做了一个测试，发现了这个:

So I did a test with a plain .zip file and found this:

... $ zip 1.zip a.txt
... $ zip 2.zip a.txt
... $ ls -l ?.zip
-rw-rw-r-- 1 webinator webinator 147 2010-07-21 13:09 1.zip
-rw-rw-r-- 1 webinator webinator 147 2010-07-21 13:09 2.zip

(完全相同的 .zip 文件大小)

(exact same .zip file size)

... $ sha1sum ?.zip
db99f6ad5733c25c0ef1695ac3ca3baf5d5245cf  1.zip
eaf9f0f92eb2ac3e6ac33b44ef45b170f7984a91  2.zip

(不同的 SHA-1 和，让我们看看为什么)

(different SHA-1 sums, let see why)

$ hexdump 1.zip -C > 1.txt

$ hexdump 2.zip -C > 2.txt

$ diff 1.txt 2.txt 
3c3
< 00000020  74 78 74 55 54 09 00 03  ab d4 46 4c*4e*d5 46 4c  |txtUT.....FLN.FL|
---
> 00000020  74 78 74 55 54 09 00 03  ab d4 46 4c*5d*d5 46 4c  |txtUT.....FL].FL|

解压这两个 zip 文件肯定会返回我们独特的文件.

Unzipping both zip files surely gives back our unique file.

问题:这是为什么?(我自己回答)

Question: why is that? (I'll answer myself)

推荐答案

(Answering to own) 是因为.zip文件格式节省了创建和修改的时间在其标题中.

(Answering to myself) It is because the .zip file format saves the creation and modification time in its headers.

如果你真的想创建两个相同的 .zip(或 .jar)，你必须让第二个相信它是在与第一个相同的时间.

If you really do want to create two identical .zip (or .jar), you have to make the second one believe it was created/modified exactly at the same time as the first one.

这篇关于Java/zip:为什么非确定性地创建 .jar 文件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！