C++二进制文件与文本文件区别及使用场景对比_技术教程

必须使用ios::binary标志，否则Windows下会错误转换换行符（\n↔\r\n）并遇\x1A截断，导致图片、音频等二进制数据损坏；应显式指定该标志，避免文本模式干扰。

二进制文件读写必须用 `ios::binary` 标志

不加这个标志，ifstream 或 ofstream 会默认按文本模式处理：Windows 下自动把 \n 转成 \r\n，读取时又反向转换；遇到 \x1A（EOF 字符）直接截断。这对图片、音频、序列化对象等二进制数据是灾难性的。

实操建议：

所有二进制 I/O 必须显式指定 ios::binary，例如：ofstream fout("data.bin", ios::binary);
文本文件可以省略该标志，但加上也无害；混用会导致不可预测的换行/截断问题
fread/fwrite（C 风格）默认就是二进制，无需额外设置，但需注意平台字节序和结构体对齐

`std::string` 和 `std::vector` 适合做二进制缓冲区

文本文件常用 std::string 存行或小段内容，但二进制数据可能含 \0 字节，std::string 的 c_str() 或构造函数会误判为结尾。更安全的是用 std::vector 或 std::basic_string（保留空字符）。

常见错误现象：

用 std::string s(buf, len) 构造二进制数据，但 buf 中有 \0 → 实际只拷贝到第一个 \0
用 s.data() 传给 write() 却没传长度 → 写入长度被 \0 截断

正确做法：

std:
:vector buf(1024);
fin.read(buf.data(), buf.size()); // 显式传长度
// 或
std::string bin_data;
bin_data.assign(buf.begin(), buf.end()); // 不依赖 \0 终止

文本文件适合人读，二进制文件适合机器高效存取

文本文件（如 JSON、CSV、XML）可直接用编辑器查看、grep 搜索、Git diff 对比，但解析慢、体积大；二进制文件（如 Protocol Buffers、自定义结构体 write(reinterpret_cast(&x), sizeof(x))）体积小、读写快，但无法直读、不可 diff、跨平台需处理字节序和对齐。

使用场景判断：

日志、配置、用户可见数据 → 文本优先
游戏资源包、传感器原始采样、网络协议载荷、高频序列化 → 二进制优先
需要长期存档或跨语言互通 → 选带 schema 的二进制格式（如 FlatBuffers），别手写 memcpy

结构体写入二进制文件前必须考虑内存对齐与字节序

直接 write() 一个结构体，看似简单，实际埋雷：编译器插入填充字节（padding），不同平台结构体布局可能不同；多字节整数在 x86 是小端，ARM 可能是大端。

容易踩的坑：

结构体含 bool、char、int 混排 → 实际大小 ≠ 成员字节和，sizeof(S) 不等于你算出来的值
用 #pragma pack(1) 强制紧凑对齐 → 解决 padding，但可能降低访问性能，且需两端一致
跨平台传输整数 → 必须用 htons()/htonl() 或手动翻转字节，不能直接写 int32_t

示例（安全写入紧凑结构）：

struct __attribute__((packed)) Header {
    uint32_t magic;   // 网络序写入
    uint16_t version;
};
Header h = {htons(0x1234), htons(1)};
fout.write(reinterpret_cast(&h), sizeof(h));