使用nc传输文件时字节变化的原因及预防方案

嘿，这个问题我碰到过好多次！咱们先捋清楚为啥哈希对不上，再给你实用的解决办法：

问题根源：文本模式读取破坏了二进制数据 #

你在Windows端用的Get-Content binaryFile.exe是关键问题！PowerShell的Get-Content默认是文本模式读取文件，它会把文件内容当成文本字符来解析，而不是直接读取原始字节流：

• 二进制文件里的非文本字节（比如0x00、0xFF这类控制字符或无效UTF-8字节）会被错误转换或丢弃；
• 它还会自动处理换行符（把Windows的CRLF转换成PowerShell内部的换行格式）；
  这些操作直接篡改了原始文件的字节结构，传到Ubuntu那边的target文件自然和源文件哈希不一样了。

预防/解决方法 #

给你两个靠谱的方案，任选其一就行：

方案1：强制PowerShell以二进制模式读取文件 #

修改发送端的命令，给Get-Content加上-Encoding Byte和-Raw参数，让它直接读取原始字节，不做任何编码转换：

powershell@windows $ Get-Content binaryFile.exe -Raw -Encoding Byte | nc 192.168.155.51 4444

方案2：绕开PowerShell管道，直接让nc读取文件 #

如果你的Windows版nc支持直接读取文件（大部分主流版本都支持），可以用重定向替代管道，完全避免PowerShell的编码干扰：

powershell@windows $ nc 192.168.155.51 4444 < binaryFile.exe

另外提个小建议：传输完成后，记得用哈希工具（比如Windows的Get-FileHash和Linux的sha256sum）再校验一遍，确保文件完整无误~

备注：内容来源于stack exchange，提问作者TMOTTM