C++实现文件切片与合并 _ 二维码二进制流分段读写【源码】

大文件切片，听起来简单，但实际操作中坑不少。特别是对于二维码二进制流这种对完整性要求极高的数据，一个字节的偏差都会导致解码失败。这里梳理几个关键点，基本覆盖了从切片到合并的全流程，可以当作一份实操 checklist 来用。

用 fstream 按固定大小切分大文件，别直接 read() 到 std::string

当处理几百 MB 的二维码二进制流时，一个常见的错误是试图把整块数据先读进 std::string 或 std::vector，再写入子文件。这么做不仅容易导致内存爆掉，性能也会骤降。正确的做法是：用 std::ifstream 和 std::ofstream 配合一块固定大小的缓冲区进行循环读写，全程不加载全文到内存。

有几个关键细节值得注意：

• read() 的返回值必须检查——它实际读取的字节数可能少于请求数，尤其是在接近文件末尾时。不能想当然地认为“调用一次就能读满”。
• 缓冲区大小建议设为 8192 或 65536 这类 2 的幂次方，可以避开磁盘页边界问题，这已经是行业里的共识了。
• 切片命名时，推荐带上序号和总片数，比如 data_0001_of_0012.bin，这样合并时排序会非常方便。

std::ifstream src("qrcode.bin", std::ios::binary);
char buf[8192];
int slice_idx = 0, slice_size = 1024 * 1024; // 1MB per slice
while (src.good()) {
    src.read(buf, sizeof(buf));
    size_t n = src.gcount();
    if (n == 0) break;
    std::ofstream dst("slice_" + std::to_string(++slice_idx) + ".bin", std::ios::binary);
    dst.write(buf, n);
    dst.close();
}

合并时按文件名自然序读取，别依赖 readdir() 返回顺序

很多人在合并时容易忽略一个细节：文件名的排序。在 Linux/macOS 下，readdir() 并不保证返回的文件名是有序的；Windows 的 FindFirstFile 同样不可靠。如果切片文件名是 slice_1.bin、slice_10.bin、slice_2.bin，直接遍历目录读取，会先读 1，再读 10，再读 2——这会导致二进制流错乱，解码时自然一塌糊涂。

实操层面的建议：

• 切片时强制使用定宽数字命名，比如 slice_0001.bin，位数根据总片数提前预估好。
• 合并前，先用 std::vector 收集所有匹配的文件名，再用 std::sort 排序。由于文件名已经是定宽格式，直接基于字符串排序即可。
• 不要用 std::filesystem::directory_iterator 边遍历边合并——C++17 标准并不保证遍历顺序，而且部分旧编译器根本没实现这个功能。

二维码二进制流对完整性极度敏感，合并后必须校验 SHA-256

二维码解码失败，很多时候不是算法的问题，而是切片或合并过程中引入了空字节、截断或偏移。有几个细节必须盯死：

• ofstream 默认不加 std::ios::binary 标志，在 Windows 下会把 \x0A 自动转成 \x0D\x0A，这会直接破坏原始二进制数据。
• 切片最后一块如果不足指定大小，仍然要原样写入，不能补零。否则解码器收到多余字节会直接失败。
• 合并完成后，立刻计算源文件与合成文件的 SHA-256 哈希值，二者必须完全一致——这是唯一可信的完整性判断依据。

推荐使用 OpenSSL 的 C++ 封装，或者找一个像 sha256.h 这样的单头库。千万别用 CRC32——它无法检测小范围的数据重复或重排，对于二维码这种场景来说，校验能力远远不够。

跨平台路径拼接要用 std::filesystem::path，别手拼 "./slices/" + name

硬编码 / 或 \ 在 Windows 和 Linux 下都会出问题。用 + 拼接 std::string 很容易忽略路径分隔符的逻辑。C++17 的 std::filesystem::path 是目前唯一稳妥的跨平台方案。

• 构造路径时，用 fs::path dir = "slices"; fs::path p = dir / "slice_0001.bin"; 这种写法。
• 检查文件是否存在，用 fs::exists(p)，比 std::ifstream(p.string()).is_open() 更可靠。
• 需要注意的是：MSVC 19.20+、GCC 9+、Clang 10+ 才完整支持 std::filesystem。如果项目环境比较老，需要回退到 Boost.Filesystem，或者手动处理分隔符。

切片和合并的逻辑本身并不复杂，真正让人卡住的永远是那些边界情况：最后一片读不满、路径斜杠处理、二进制换行被自动转换、哈希校验没做。把这些细节盯死，比堆砌什么花哨的 API 都管用。