C语言Socket传输文件及文件名遇异常，求最优解决方案

问题背景 #

通过C语言Socket传输文件及文件名时，现有代码存在以下未定义行为：

• 接收到的文件名包含垃圾数据
• 可能接收到空文件

现有代码 #

服务器端代码 #

char file[18];
memset(file, 0, 18);
file[17] = '\0';
int recvd = recv(newsock, file, 16, 0);

char local_file_path[200];
memset(local_file_path, 0, 200);

// 此处存在bug：将函数名recv作为判断条件，应为recvd == 0
if(recvd == -1 || recv == 0) {
    fprintf(stderr, "File name not received");
    continue;
}

strcat(local_file_path, "/home/ubuntu/results/");
strcat(local_file_path, file);
FILE* fp = fopen(local_file_path, "wb");

char buffer[4096];
while(1)
{
    recvd = recv(newsock, buffer, 4096, 0);
    fwrite(buffer, sizeof(char), recvd, fp);
    if(recvd == -1 || recvd == 0) {
        fclose(fp);
        break;
    }
}
close(newsock);
}
close(servSock);

客户端代码 #

// 此处缺少分号，且后续send调用中变量名拼写错误
char* my_16_long_fname = "filename1234.txt"
int ret = send(sock, my_16_long_file_fname, strlen(my_16_long_fname), 0)

现有代码核心问题 #

1. 文件名传输边界模糊：客户端仅发送文件名的有效字符（不含\0），服务器依赖初始memset保证字符串结束符。若网络粘包或发送长度超出预期，会导致文件名后出现垃圾数据；同时判断条件存在语法错误，无法正确检测接收失败。
2. 文件内容接收无明确结束标记：服务器循环接收时未处理recv返回-1的异常场景，且无文件长度标识，易导致空文件或截断。
3. 客户端语法错误：缺少分号、变量名拼写错误，会引发编译或运行异常。

对用户方案的分析 #

方案1：通过文件签名生成文件名 #

不符合业务逻辑，无法处理“发送错误码”的场景，直接排除。

方案2：第一次recv时遍历找\0，剩余部分作为文件内容 #

该方案既不高效简洁，也不可靠，原因如下：

• 粘包问题无法解决：Socket是流式传输，第一次recv可能同时收到文件名\0和部分文件内容，也可能仅收到文件名的一部分（未到\0），遍历找\0会出现误判或越界访问。
• 效率与复杂度问题：每次接收都需遍历缓冲区，增加不必要的计算；还需处理缓冲区剩余数据的拷贝，代码复杂度陡增。
• 通用性不足：若文件名本身包含\0（业务场景虽少见，但协议需考虑通用性），方案直接失效；同时无法区分“错误码”与“文件名”的消息类型。

推荐的可靠解决方案：定义明确的传输协议 #

流式Socket的核心痛点是无消息边界，必须通过清晰的协议格式区分消息类型（错误码、文件名+文件内容）。

协议设计思路 #

1. 消息头：先发送固定长度的头部，包含1字节的消息类型（0=错误码，1=文件传输）和4字节的后续数据长度（统一使用网络字节序）。
2. 消息体：根据消息类型发送对应内容：
   • 错误码：发送错误码长度+错误码字符串
   • 文件传输：发送文件名长度+文件名+文件内容长度+文件内容

示例代码片段 #

客户端发送文件逻辑

// 发送消息类型：1表示文件传输
char msg_type = 1;
send(sock, &msg_type, sizeof(msg_type), 0);

// 发送文件名长度（转网络字节序）
uint32_t fname_len = htonl(strlen(my_16_long_fname));
send(sock, &fname_len, sizeof(fname_len), 0);
// 发送文件名
send(sock, my_16_long_fname, strlen(my_16_long_fname), 0);

// 发送文件内容长度
FILE* fp = fopen(my_16_long_fname, "rb");
fseek(fp, 0, SEEK_END);
uint32_t file_len = htonl(ftell(fp));
fseek(fp, 0, SEEK_SET);
send(sock, &file_len, sizeof(file_len), 0);

// 发送文件内容
char buffer[4096];
size_t read_len;
while ((read_len = fread(buffer, 1, sizeof(buffer), fp)) > 0) {
    send(sock, buffer, read_len, 0);
}
fclose(fp);

服务器接收逻辑

// 接收消息类型
char msg_type;
recv(newsock, &msg_type, sizeof(msg_type), 0);

if (msg_type == 0) {
    // 处理错误码
    uint32_t err_len = 0;
    recv(newsock, &err_len, sizeof(err_len), 0);
    err_len = ntohl(err_len);
    char err_buf[256];
    recv(newsock, err_buf, err_len, 0);
    err_buf[err_len] = '\0';
    fprintf(stderr, "Received error: %s\n", err_buf);
} else if (msg_type == 1) {
    // 接收文件名长度（转主机字节序）
    uint32_t fname_len = 0;
    recv(newsock, &fname_len, sizeof(fname_len), 0);
    fname_len = ntohl(fname_len);
    
    // 接收文件名
    char file[256];
    memset(file, 0, sizeof(file));
    recv(newsock, file, fname_len, 0);
    file[fname_len] = '\0';
    
    // 构建本地路径
    char local_file_path[200];
    memset(local_file_path, 0, sizeof(local_file_path));
    strcat(local_file_path, "/home/ubuntu/results/");
    strcat(local_file_path, file);
    
    // 接收文件内容长度
    uint32_t file_len = 0;
    recv(newsock, &file_len, sizeof(file_len), 0);
    file_len = ntohl(file_len);
    
    // 接收文件内容
    FILE* fp = fopen(local_file_path, "wb");
    if (!fp) {
        fprintf(stderr, "Failed to open file\n");
        close(newsock);
        return;
    }
    
    char buffer[4096];
    uint32_t received = 0;
    while (received < file_len) {
        size_t to_read = (file_len - received) < sizeof(buffer) ? (file_len - received) : sizeof(buffer);
        int recvd = recv(newsock, buffer, to_read, 0);
        if (recvd <= 0) {
            fprintf(stderr, "File transfer failed\n");
            fclose(fp);
            close(newsock);
            return;
        }
        fwrite(buffer, 1, recvd, fp);
        received += recvd;
    }
    fclose(fp);
}
close(newsock);

方案优势 #

• 可靠性：明确的消息边界彻底解决粘包、文件名垃圾数据问题，同时支持区分错误码与文件传输场景。
• 高效性：无需遍历缓冲区找结束符，按长度接收逻辑清晰，性能损耗低。
• 扩展性：可轻松扩展其他消息类型，适配业务需求变化。

额外注意事项 #

• 所有send和recv调用需处理返回值，封装循环发送/接收函数确保数据完整传输（示例代码简化了此步骤）。
• 跨平台传输时需统一使用网络字节序，通过htonl/ntohl转换。
• 限制文件名长度，避免缓冲区溢出。

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