.NET Core应用VerifyHash在Windows正常Linux验证失败求助

这种跨平台的诡异问题我之前也碰到过好几次，明明数据看起来一模一样，结果就是验证不通过，大概率是换行符或者编码的隐形差异在搞鬼，毕竟Windows和Linux对文本/文件处理的默认行为差别不小，下面给你几个排查方向：

• 优先排查文件读取的字节流一致性
  如果你是通过文本方式读取文件来计算哈希，Windows默认可能用带BOM的UTF-8或者UTF-16编码，换行符是\r\n；而Linux通常用无BOM的UTF-8，换行符是\n。哪怕你调试输出的哈希和签名字符串看起来一致，实际读取的字节流可能已经有差异了。
  解决办法：直接用字节流读取文件，跳过文本编码和换行符的干扰，示例代码：

  // 读取原始字节，避免文本处理带来的差异
  byte[] fileBytes = File.ReadAllBytes("target-file-path");
  // 用这些字节直接参与哈希计算或验证
  

• 核对VerifyHash的调用细节
  确认你调用VerifyHash时的哈希算法、签名格式是否在两个平台上完全一致：

  • 尽量用HashAlgorithmName枚举（比如HashAlgorithmName.SHA256）而不是字符串传参，避免大小写或拼写的隐性问题；
  • 检查签名的字节顺序（大端/小端）是否被隐式转换，或者是否错误处理了签名的格式（比如OpenSSL用PEM格式，而.NET Core需要DER格式的字节）。

• 借助OpenSSL的结果反向验证
  既然Linux上OpenSSL能校验通过，说明签名和原始哈希本身是没问题的。你可以：

  1. 在.NET Core代码里把待验证的原始字节保存成二进制文件：File.WriteAllBytes("dotnet-data.bin", fileBytes);
  2. 在Linux上用diff命令对比这个二进制文件和OpenSSL校验用的原始文件：

     diff original-data.bin dotnet-data.bin
     

  如果diff有输出，直接就能定位到数据读取的差异；如果没差异，那就是VerifyHash的调用逻辑有问题，可以把你的调用代码贴出来再细化排查。

• 排除Linux文件系统的隐性问题
  偶尔Linux的文件权限、符号链接或者扩展属性可能导致读取内容异常，你可以用md5sum命令计算Linux上目标文件的哈希，和Windows上的文件哈希对比，确认文件本身是完全一致的。

内容的提问来源于stack exchange，提问作者DmqCsm