C++中使用uint8_t存储字符串而非std::string的原因及相关代码疑问

嘿，我太懂你这种隔了十几年再碰C++的困惑了——看到用uint8_t数组存字符串，还写这么繁琐的循环复制，肯定满脑子“这没必要吧？”的问号！咱们一步步拆解：

为什么用uint8_t数组而非std::string？ #

这种写法大概率是和代码的使用场景强绑定的，主要有这几个核心原因：

• 二进制序列化/加密的刚需：你看代码里有WriteEncryptFile函数，明显是要把结构体内容转成加密的二进制文件。uint8_t本质就是无符号单字节类型，和二进制数据是一一对应的。如果用std::string，它是C++的高级封装，内部除了字符数据，还会存长度、内存管理相关的元数据（不同编译器实现可能不一样），直接把std::string写入二进制文件的话，存的不是纯字符内容，而是它的内部结构，解密/解析的时候根本读不出正确的字符串。而固定长度的uint8_t数组，整个结构体的内存布局就是连续的64字节文件名 + 64字节用户名，直接把结构体转成字节流加密、写入，后续解析的时候直接读对应长度的字节就行，逻辑简单且可靠。
• 底层/跨平台/跨语言交互需求：你是React Native开发者，这个C++代码大概率是要和移动端Native模块，或者其他语言（比如C、Java）、硬件/嵌入式系统交互。uint8_t数组的内存布局完全透明，其他语言很容易把字节数组转成字符串；而std::string的内部实现是编译器和平台相关的，跨语言传递时很容易因为内存结构不兼容出问题。
• 固定长度的稳定性要求：用64字节的固定数组，能强制保证每个字段的长度不超过64字符，避免动态长度带来的内存分配问题，在加密或者内存受限的场景里，这种固定长度的结构更稳定，不会因为字符串过长导致内存溢出或者加密块大小不匹配。

关于那段繁琐的循环复制代码 #

你看到的getCustomFileFromFile函数里，用两个循环逐字符复制数组，其实完全是冗余的——咱们可以用memcpy一行代码搞定：

memcpy(returnValue.FileName, f_File.FileName, FILE_NAME_LEN);
memcpy(returnValue.user_name, f_File.user_name, FILE_NAME_LEN);

这种写法不仅简洁，效率也更高。至于原代码为什么要写循环，可能是写代码的人习惯了手动操作，或者是担心某些场景下的内存重叠（不过这里两个数组都是独立的，完全不存在重叠问题），也有可能是为了兼容一些老旧的编译器？不过不管怎么说，手动循环复制确实没必要。

另外还要提个小坑：用uint8_t数组存字符串的话，一定要确保数组里有字符串终止符'\0'，不然后续转成std::string或者其他字符串类型时，可能会读到后面的垃圾数据。比如如果文件名只有10个字符，后面的54个字节如果不是'\0'，转成字符串就会带出一堆乱码。而std::string会自动管理终止符，这也是它的优势之一。

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