Answers:
如果使用加密了文件gpg -c，则在不知道密码的情况下无法验证文件包含的内容。这是对称加密的核心属性。由于仍然需要提供密码短语，因此请进行实际测试：将文件解压缩并将其与原始文件进行比较。在Linux或其他unix变体上：
gpg -d <50GBfile.gpg | cmp - 50GBfile
如果要进一步保证完整性，可以-s在加密文件时通过添加选项来使用私钥对文件签名。
gpg -c -s 50GBfile
然后，您可以使用验证签名gpg --verify 50GBfile.gpg。请注意，这仅能保证该文件是您已签名的文件之一，但这并不能防止您对错误的文件进行签名。
如果您使用非对称加密（使用收件人的公钥-您自己的公钥），则验证文件是否具有所需的内容将需要收件人的私钥。对于多个收件人，任何收件人的私钥都可以。通常，您会使用GPG配置文件encrypt-to或将其自己的密钥作为所有加密消息的收件人hidden-encrypt-to。
gnupg中唯一的“验证”操作是签名验证，它基本上使用公共密钥（= sign）对加密文件的哈希进行加密。
在我看来，这意味着如果在加密文件的同时输出位已损坏，则将针对损坏的文件计算哈希值。由于您已经签名了已经损坏的文件，因此您将永远无法通过验证该文件的签名来发现这一点。
肯定地验证加密文件是否损坏的唯一方法是，经过冗长的过程来解密生成的文件，并将其哈希值与原始文件进行比较。
而这也正是Sepero上面提供的，但不是“你可以验证......”应该是“的唯一验证方法...”
更新-使点回家：
几分钟前，我做到了：将9.8GB的备份文件分成5个rar文件，每个文件均由gnupg对称加密。在删除rar片段之前，我如上所述验证了加密片段的完整性：5个中的1个未通过哈希测试。我再次解密了那个片段，现在解密的片段的哈希值确实与原始rar片段匹配。
我用二进制比较了不良解密的rar部分和良好解密的rar部分，这2GB文件的唯一区别是一个字节：C8 vs. 48-这是由1位翻转引起的（即11001000 vs 01001000）。
故事的寓意是，如果在良好的WIN7系统和良好的HDD上，gnupg可以在解密方面有所作为，那么它也可以在加密方面做到这一点。我将永远不会再跳过此完整性验证步骤。
如果要验证完整性，还需要对原始文件进行签名。
gpg --encrypt --sign 文件
最后，您可以通过解密文件（自动检查完整性）来验证完整性（基于签名）。
gpg --decrypt file.asc