然后使用一个工具（例如版本1.2 SDK中的jarsinger)对整个JAR文件签名。这个签名工具将首先对JAR文件的内容进行单向散列计算，以产生一个散列。
这个单向散列计算之所以被称为“单向”，是因为在只给出散列（即那个少量的数据）的情况下， 这个散列值不能包含足够的输人的信息，因此不能从散列重新生成原输人。这个计算是单向的， 从大到小，从输入到散列。
散列也被称为消息文摘，它相当于一种输人“指纹”。虽然不同的输入可能产生相同的散列， 但通常认为，在实际情况下，一个散列足以代表了产生它的输人。
因为单向散列算法是从大量数据（输人）中产生少量数据（消息摘要或者散列），所以不同 的输人可能产生相同的散列。单向散列算法倾向于充分随机地分布产生相同散列的输入，从而使产生相同散列值的概率主要依赖于散列的大小。例如，如果使用了一个长8位的散列值，散列 算法最多产生256个不同的散列值。如果有一个JAR文件，它的散列值是100,然后你幵始将这 个8位的散列算法在其他JAR文件上运用，毫无疑问，每进行大约256次计算，将可能得到一个值 为100的散列。当然，如果散列的位数越多，产生相同散列值的情况就越不可能发生。在实际情况中，普遍采用的是64位或丨28位的散列，通常认为这个长度已经足够了，这时要想从一个不同 的输人中产生一个相同的散列的计算是不可行的。因此，防止黑客用恶意输人替换你的善意输 人，并且产生相同的散列值的主要障碍在于，他必须花费大量的时间和资源才能找到这个恶意的输人。