客户端-服务器通信中第二文件CRC处理及传输失效问题求助

开发客户端-服务器通信项目，需将文件内容转二进制并添加CRC校验后传输，服务器移除CRC转回字符串发回客户端。处理city.txt全流程正常，但country.txt完全失效：

• 客户端发送countrycrc.txt后，接收返回文件时报错：[-]Error in receiving file size: Success
• 服务器端报错：[-]Error: Not enough bits to extract data part.
• countrycrc.txt和返回的crcasciicountry.txt均为空
• 环境：Ubuntu 20.04，单PC双终端通信

1. 文件本身与预处理阶段问题 #

• 检查country.txt的有效性：
  用命令确认文件是否为空或存在异常：

  wc -c country.txt  # 查看文件字节数
  cat -v country.txt # 显示不可见字符
  

  如果文件为空，或包含特殊二进制字符/异常换行，会导致转二进制时直接生成空数据，后续CRC处理也会生成空的countrycrc.txt。
• 校验CRC生成逻辑的兼容性：
  确认客户端对空文件/短文件的CRC处理逻辑是否正常。比如如果country.txt为空，转二进制后长度为0，添加CRC时是否会生成包含CRC的有效数据，还是直接输出空文件？可以在客户端生成countrycrc.txt后，用stat -c %s countrycrc.txt检查文件大小，若为0则说明预处理阶段直接失败。

2. 通信阶段的边界与数据传递问题 #

• 排查TCP粘包导致的文件大小读取错误：
  连续传输两个文件时，若客户端未正确分隔两次传输的边界，或服务器未处理完第一个文件的剩余数据就开始读取第二个文件的大小，会导致服务器读取到错误的大小值，进而接收不足数据，触发“比特不足”错误。
  解决方向：在每次传输前严格发送固定字节数的文件大小（比如4字节无符号整数），服务器先读取固定长度的大小值，再接收对应字节的数据；传输完成后确保套接字缓冲区无残留数据。
• 检查文件大小获取的正确性：
  客户端发送countrycrc.txt前，确认获取文件大小的逻辑是否正确。比如用文本模式打开二进制文件（如C语言fopen("countrycrc.txt", "r")）会导致大小计算错误，需用二进制模式（"rb"/"wb"）处理所有二进制文件。

3. 服务器端CRC拆分与数据还原逻辑问题 #

• 检查数据与CRC的拆分规则：
  服务器报错“Not enough bits to extract data part”，说明代码中可能假设数据部分的长度必须大于0，或拆分时错误计算了数据与CRC的分界点。比如：
  • 若countrycrc.txt仅包含CRC（原文件为空），服务器拆分时仍尝试提取非空的数据部分，就会触发该错误。
  • 确认CRC的长度是否固定（比如16位、32位），拆分时是否用总比特数减去CRC长度来计算数据部分长度，而非依赖原文件的预设长度。
• 校验二进制转字符串的容错逻辑：
  若服务器从空数据中尝试还原字符串，是否会直接生成空文件？需确认代码在数据部分为空时的处理逻辑，是否能正确返回空字符串对应的文件。

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