在现代 C 系统级开发与高性能网络通信中原始字节流的高效处理是决定软件吞吐量与延迟表现的核心要素。作为 Qt 框架中用于承载和操作原始字节数组及 C 风格字符串的基础工具QByteArray 的设计演进轨迹不仅折射出 C 语言标准的变迁也代表了 Qt 核心架构向低开销、高安全性演进的决心。本报告针对 Qt 5.155.x 时代的终极长期支持版本与 Qt 6.116.x 新一代演进版本中的 QByteArray 进行全方位的深度对比剖析其底层内存架构、寻址空间、轻量级视图机制、API 清理以及跨平台行为学差异为企业级项目的重构与迁移提供权威、详实的技术参考。底层内存架构与数据结构的重构从 Qt 5.15 跨越至 Qt 6.11QByteArray 经历了一场脱胎换骨的底层数据结构重构。这不仅改变了它的内存布局还深刻影响了多类容器间的互操作性与代码的运行时安全。从 QArrayData 到 QArrayDataPointer 统一架构在 Qt 5.15 中QByteArray 的物理支撑依赖于私有的、非模板化的 QArrayData 结构体。这种设计虽然通过复杂的偏移量计算和特定的类型转换实现了隐式共享Copy-on-Write和动态扩容但由于缺乏统一的模板化泛型控制导致 QByteArray、QString 以及 QVector在 Qt 5 中与 QList 分立之间的底层实现存在严重的壁垒在容器间相互转换时往往难以避免昂贵的动态内存分配和内存拷贝。进入 Qt 6 时代开发团队重构了整个容器体系的基石。在 Qt 6.11 中QString、QByteArray 以及统一后的 QList由原 QVector 演进并作为其底层实现全面转为采用泛型模板类 QArrayDataPointerT针对 QByteArray 特化为 QArrayDataPointerchar进行内存统一管理。这一变革彻底打破了容器间的数据物理隔离使这些最基础的字符串与字节容器在特定场景下能够实现真正意义上的零拷贝转换。在行为细节上这种架构统一也带来了一些向前兼容性妥协。例如为了兼顾存量代码的行为一致性Qt 6.11 依然在头文件中保留并默认启用了 QT5_NULL_STRINGS 宏其值定义为 1。尽管这在学术上不够纯粹但在工业实践中它有效阻止了因“空字节数组”Null QByteArray与“空字符数组”Empty QByteArray在行为差异上产生的运行时崩溃。内存初始化与 overwrite 性能优化在缓冲区管理方面QByteArray 的扩容和空间分配接口在 Qt 6 中得到了进一步细化。在 Qt 5.15 中开发者在申请大段缓冲区时通常只能调用 resize() 接口而新分配的字节流内容是未定义的存储着堆内存残留的脏数据开发者随后必须通过物理覆盖或 fill() 进行清空这对于追求极致性能的 I/O 数据流接收模块而言存在明显的冗余开销。Qt 6.11 引入了更加符合现代高性能编程范式的resizeForOverwrite(qsizetype size)接口。该方法允许直接调整物理缓冲区的大小同时向编译器和内存分配器明确宣告这部分空间不需要执行任何形式的初始化或填充操作从而在后续立刻进行物理 I/O 写入如直接通过套接字或文件句柄填充缓冲区时将数据准备阶段的 CPU 开销降至最低。迭代器失效与引用稳定性的断层数据结构的精简与性能的提升并非没有代价。在 Qt 5.15 中非隐式共享状态下的修改操作在一定程度上对已持有的元素迭代器和引用提供了相对缓和的稳定性保护。然而为了追求执行路径的绝对高效Qt 6.11 重新定义了引用稳定性规范。根据 Qt 6 的容器物理规范除了官方文档明确声明的极少数例外任何导致 QByteArray 尺寸Size或容量Capacity发生改变的操作包括 insert()、remove()、append() 等方法都必须被视为会使所有已保存的迭代器、内部裸指针如 .data() 或 .constData()以及元素引用瞬间失效即便该 QByteArray 实例当前处于单引用未共享状态。在多线程高频交互和复杂的回调逻辑中未能遵守这一原则的代码会直接暴露在内存悬空Dangling Pointer与未定义行为Undefined Behavior的巨大风险之下。寻址空间拓展与数据类型的重定义随着海量数据处理、高吞吐网络解析以及超大文件读写逐渐成为工业界常态32 位有符号整型在物理内存寻址上的局限性日益凸显。Qt 6.11 通过引入全新的尺寸与索引类型体系彻底扫平了这一物理障碍。关键规格属性Qt 5.15 版本性能与规范Qt 6.11 版本性能与规范底层核心指针表示基于非模板 QArrayData基于模板特化 QArrayDataPointerchar底层存储空间间接寻址存在两层指针间接寻址开销指针及基础数据直接嵌于对象体中默认空指针行为宏控制隐式隔离空与未初始化状态显式使能 QT5_NULL_STRINGS 维持兼容性未初始化扩容安全支持仅支持传统 resize()无明确未初始化语义支持原生 resizeForOverwrite() 极致性能扩展高频迭代器稳定性规范局部非共享状态下修改可能维持部分稳定性任何物理尺寸变更操作皆强制判定所有引用失效突破 2GB 内存配额壁垒在 Qt 5.15 及其所有历史前代版本中QByteArray 的大小、长度、索引和物理扩容参数均统一由 32 位有符号整型 int 承载。由于 int 的上限物理制约QByteArray 单个实例的最大连续内存空间被牢牢锁死在最大空间限制 2 31 − 1 字节 ≈ 2 GB \text{最大空间限制} 2^{31} - 1 \text{ 字节} \approx 2 \text{ GB}最大空间限制231−1字节≈2GB在雷达高速采集、高清视频无损 PCM 缓存或者大型点云序列反序列化等场景中这一限制常年逼迫开发者放弃成熟的 Qt 核心类转向物理控制极不安全的原始堆分配或第三方容器。在 Qt 6.11 中整个核心库容器层的数据寻址与大小类型全面重构为qsizetype。在 64 位操作系统架构下qsizetype 物理映射为 64 位有符号整型 ptrdiff_t在 Qt 内部定义为 qssize_t。这一重大变动直接将 QByteArray 的理论单实例最大物理寻址上限推升至2 63 − 1 2^{63} - 1263−1字节使 Qt 在超大规模连续物理内存段的操作上能够完美融入现代 64 位硬软件生态。编译期类型系统冲击与窄化警告尽管向 qsizetype 的提升在物理架构上带来了显著优势但在大型工程迁移中它也是引发编译阻断的主要诱因。// ⚠️ 在 Qt 5.15 下可编译在 Qt 6.11 下会触发窄化转换警告或错误QByteArray networkBufferreadNetworkData();intpayloadSizenetworkBuffer.size();// size() 返回值已变更为 qsizetype当存量代码中充斥着成千上万个使用 int 接收 size()、length()、indexOf() 返回值或作为循环条件边界的表达式时现代 C 编译器如 GCC 8、Clang 9 及 MSVC 2019会基于更严格的类型安全检查触发大面积的隐式窄化类型转换Narrowing Conversion警告甚至编译错误。为了应对这一断层工程团队在迁移到 Qt 6.11 时必须通过采用 auto 关键字自动推导、将索引类型物理提升至 qsizetype 或进行显式的 static_castint 强转等手段对代码进行系统性的类型安全修复。QByteArrayView 的引入与轻量级只读视图范式在高性能字符和字节数据解析场景如 HTTP 协议栈、JSON/CBOR 序列化与反序列化等中频繁的堆内存申请与释放、隐式共享带来的写时复制惩罚是制约系统性能的隐形杀手。为此Qt 6.0 引入并于 Qt 6.11 中完全确立了QByteArrayView这一具有里程碑意义的轻量级非拥有性Non-owning字节视图类。物理本质与零开销参数传递机制QByteArrayView 引用了一段物理上连续存储的只读原始字节序列其自身在栈内存上仅占用一个指向物理数据首地址的指针和一个长度标识共 16 字节而不持有这部分内存的所有权。它的核心设计初衷是作为函数的输入参数类型。在 Qt 5.15 中为了让一个解析方法能够兼顾不同的字节输入源库作者通常必须针对各种输入类型设计极其繁复的函数重载体系。而在 Qt 6.11 中通过将参数声明为接收 QByteArrayView一个函数接口便能零拷贝、统一地兼容以下所有的物理存储格式QByteArray 本身传统的 const char * 裸指针固定大小的字符数组 char ()[Size]标准库中的 std::string_view、std::string包含 signed char、unsigned char 或 C17 新增的 std::byte 连续容器如 std::vectorstd::byte在物理传递上QByteArrayView 必须采用传值Pass-by-value而非传引用Pass-by-reference-to-const的方式传递。在现代编译器和 ABI 规范下仅占用 16 字节的轻量结构体能够直接塞入 CPU 寄存器中进行传递这比将其作为引用本质上是传递多重间接寻址的指针具有更快的执行速度和更低的 CPU 流水线气泡。编译期类型匹配守卫与兼容性隔离为了确保零拷贝转换不会引发非预期的隐式模板递归QByteArrayView 的头文件设计如 IsContainerCompatibleWithQByteArrayView 等私有机制体现了高超的现代 C 元编程技巧。templatetypenameTstructIsContainerCompatibleWithQByteArrayView:std::false_type{};底层通过 IsCompatibleByteType 和 IsCompatibleByteArrayPointer 机制严格过滤出仅允许 char、signed char、unsigned char 和 std::byte 参与重载匹配。更为关键的是该机制显式排除了 QByteArray 以及 QByteArrayView 本身作为直接匹配容器如通过 std::negationstd::is_same…。这不仅在编译期建立了坚实的静态安全守卫防止因不当类型嵌套引发无限模板特化导致编译器崩溃还杜绝了各种隐式的重分配漏洞。此外QByteArrayView 的迭代器实现遵循了只读语义其定义的 iterator 与 const_iterator 均为同一只读类型。这种设计从类型系统层面阻断了任何试图通过迭代器修改只读物理内存的编译期尝试极大提升了接口的健壮性。视图 API 的规范化演进与异构查找随着 Qt 6 的迭代演进不仅只读视图本身在功能上愈发成熟自 Qt 6.3 起QByteArrayView 获得了免分配数值转换 API如直接调用 toDouble()、toFloat()、toInt() 等无需再物理构建 QByteArray其裁剪行为也在 Qt 6.5 后迎来了更严苛的现代规范。为了纠正历史命名的学术偏差并澄清“仅移动视窗而非产生内存拷贝”的物理本质Qt 6.5 及之后的版本包含 Qt 6.11已全面弃用DeprecatedQByteArrayView 内的 left()、mid() 和 right() 方法。新编写的工程代码应完全转向使用 first()、sliced() 以及 last() 系列切片算子这三种新算子在运行时完全零拷贝对高速网络数据头/尾解析和偏移切片具有无可比拟的性能优势。此外在 Qt 6.8 之后进一步在 Qt 6.11 得到强化通过 C20 的异构查找Heterogeneous Lookup机制QHash 能够在不创建临时 QByteArray 物理键的情况下直接支持 QByteArray 与 QByteArrayView 键值对的高效哈希异构寻址。行为学变更、API 清理与多平台深度融合除了数据结构和尺寸类型的重构QByteArray 在具体方法重载、隐式转换、字符编码控制以及多平台融合层面也展现出了崭新的行为特征。阻断 QString 的隐式 UTF-8 自动追加在 Qt 5.15 中QByteArray 存在一个极其宽松但饱受技术指摘的隐式转换接口append(const QString str)。当开发者不慎将 QString 传递给此接口时底层会在静默状态下自动调用 QString::toUtf8() 进行编码转码随后拼接至字节数组中。这种“便利”在现实工程中带来了两大致命硬伤一是导致对字符编码不敏感的开发者频繁写出非预期乱码的代码二是在高性能解析路径中引入了极其昂贵、且难以在静态分析阶段被轻易察觉的运行时隐式转码与动态分配开销。在 Qt 6.11 中所有这些隐式跨编码追加的宽泛重载被全部阻断。任何试图将 QString 追加到 QByteArray 或在两者之间执行隐式强制转换的行为都将直接触发编译失败。开发者必须清晰、显式地标明其字符集编解码意图QByteArray dataBuffer;QString textMessageUserText;// ❌ 在 Qt 6.11 下直接编译报错阻断隐式开销dataBuffer.append(textMessage);// 正确、显式的现代标准写法dataBuffer.append(textMessage.toUtf8());头部插入Prepend的算法复杂度飞跃在字节追加操作中头部插入Prepend历来是性能优化的重灾区。在 Qt 5.15 中向 QByteArray 的头部插入数据是一项算法复杂度为线性时间O ( N ) O(N)O(N)的极其低效的操作其中N NN为当前字节数组的物理长度。这是因为其底层结构设计仅支持尾部缓冲区预留每次头部插入都会迫使整个内存块在堆上向后发生全局平移。得益于 QArrayDataPointer 统一底座带来的物理对齐Qt 6.11 中的 QByteArray 获得了与 Qt 5 中 QList 相似的头部缓冲区物理预留机制。这直接使得 QByteArray::prepend 在数据物理结构层面的性能产生了质的飞跃其均摊算法复杂度跃升为均摊算法复杂度 Qt 6 Prepend Amortized O ( 1 ) \text{均摊算法复杂度}_{\text{Qt 6 Prepend}} \text{Amortized } O(1)均摊算法复杂度Qt 6 Prepend​AmortizedO(1)对于逆向序列化、流式协议头组装以及高频接收无序网络帧并物理重组的工业算法该机制带来了数倍至数十倍的瞬时吞吐量红利。现代 C 规范化与已弃用 API为了维护现代 Qt 架构的敏捷性Qt 6.11 对已经过时、易引发歧义的非成员函数及成员函数进行了彻底清理qsizetype QByteArray::count() const 的弃用该无参版本由于其物理行为与 size() 及 length() 完全重合在 Qt 6.4 后被正式废弃强烈建议全面替换为标准的 size()。格式化辅助函数 qsnprintf 与 qvsnprintf 的弃用由于其跨平台行为差异极大且在 WebAssembly、Android 平台对 %a十六进制浮点及 %ls宽字符的支持存在严重歧义这两者在 Qt 6.9 中已被标记为废弃。推荐使用标准 C11 的 std::snprintf() 或 Qt 自身的 QString::asprintf()。operator_qba 算子的更替在 Qt 6.2 中引入的用于快速构造物理只读字节数组的字面量算子 operator_qba在 Qt 6.8 后被废弃。统一推荐转向使用更具标准语义的 Qt::StringLiterals 命名空间下的 _ba 算子。极致 C 风格安全保障nullTerminate 与 nullTerminated尽管 QByteArray 能够保存包含嵌入式 \0 的任意二进制原始数据但在与底层操作系统接口、第三方纯 C 库交互时尾部空终止符 \0 的物理完整性是避免缓冲区溢出Buffer Overflow安全漏洞的关键屏障。为了解决由于从外部裸数据构造 QByteArray如调用 fromRawData()时物理内存尾部可能缺失空终止符的安全隐患Qt 6.10/6.11 引入了 nullTerminate() 与 nullTerminated() 方法。在不确定字节流尾部是否已安全零化时开发者可以通过调用 nullTerminate() 确保底层物理内存追加零终止符。这一操作能够安全地避开不必要的深拷贝检测极大方便了与底层 POSIX 系统调用的交互并能通过 nullTerminated() 快速进行无开销的零检查。多平台融合生态从 WebAssembly 到 Apple/Andorid 系统作为跨平台框架的排头兵Qt 6 极大地增强了 QByteArray 在各类主流以及新兴平台上的物理集成便利度WebAssembly (WASM) 运行沙箱融合在 WASM 环境下由于浏览器文件系统的沙箱物理隔离传统的文件 URL 读取无法直接交付给多媒体等组件。针对此场景Qt 6 WASM 框架中获取的本地文件直接以 QByteArray 形式安全交付。 在底层转换上QByteArray 新增了fromEcmaUint8Array(emscripten::val)物理接口允许将 JavaScript 环境下的 Uint8Array 零拷贝或高能效转换为 QByteArray打通了浏览器原生堆内存与 WebAssembly 堆内存之间的边界。Apple 系统原生数据交互在 macOS/iOS 编译环境下QByteArray 原生提供了fromCFData()、fromRawCFData()、fromNSData()以及fromRawNSData()物理转换接口完美对接 Apple Foundation 层的 CFDataRef 与 NSData 原生系统句柄实现了无需二次动态分配的高性能跨框架数据桥接。Android 生态增强配合 Android 平台的 JNI 与 JVM 数据通信QByteArray 的序列化支持在 Qt 6.11 下变得更为敏捷能够顺畅地流转于各类原生强类型嵌入式 Activity 之间。内存流媒体桥梁QBuffer 与 QByteArrayList 的演进在内存级二进制流读写中QBuffer 扮演了将 QByteArray 桥接至 QIODevice 抽象接口的核心通道角色。QByteArray dataPayload;QBufferioBridge(dataPayload);ioBridge.open(QIODevice::WriteOnly);// 无需物理文件即可在内存中进行流媒体读写由于 QBuffer 自身并不接管底层 QByteArray 的生命周期这种设计极大地便利了开发者使用 QDataStream 或 QTextStream 以内存数据库的形式进行高频序列化。与之相呼应的是专门用于拼接海量二进制大对象BLOB的QByteArrayList容器。与专门用于处理可打印字符、包含大量复杂排序过滤逻辑的 QStringList 相比QByteArrayList 在 Qt 6.11 中依然保持着其极简纯物理、专供高速拼接的定位。更值得注意的是Qt 6.3 专门为其新增了接收 QByteArrayView 间隔符的 join() 重载。由于拼接过程中不需要重复构造临时的间隔字符数组拼接海量字节序列的速度较 Qt 5 提升了数倍。典型 API 重载与方法签名变迁对比矩阵下面提炼了从 Qt 5.15 到 Qt 6.11 版本典型成员函数与核心 API 在重载形式、参数及返回类型上的详细演进变化典型成员方法与核心 APIQt 5.15.x 版本重载签名特征Qt 6.11.x 物理签名特征与演进机制基础构造函数QByteArray(const char *data, int size -1)QByteArray(const char *data, qsizetype size -1) QByteArray(QByteArrayView v) (自 6.8 显式使能)字符定位 at()char at(int i) constchar at(qsizetype i) const元素追加 append()QByteArray append(const QString str) QByteArray append(const char *str, int len)物理废弃 QString 重载 QByteArray append(QByteArrayView data) QByteArray append(const char *str, qsizetype len)区间擦除 erase()未提供高效迭代器擦除iterator erase(const_iterator first, const_iterator last) (自 6.1) iterator erase(const_iterator it) (自 6.5)数据赋值 assign()未提供统一数据赋值QByteArray assign(QByteArrayView v) (自 6.6) QByteArray assign(InputIterator first, InputIterator last) (自 6.6)子串查询 indexOf()int indexOf(const QString str, int from 0) const int indexOf(const QByteArray ba, int from 0) const废弃 QString 查询接口 qsizetype indexOf(QByteArrayView bv, qsizetype from 0) const哈希散列辅助 qHash()uint qHash(const QByteArray key, uint seed 0)size_t qHash(const QByteArray key, size_t seed 0) (64位哈希保护)十六进制解析 fromHex()QByteArray fromHex(const QByteArray hexEncoded)QByteArray fromHex(QByteArrayView hexEncoded) (零分配解析视图)迁移重构指南与工程实践最佳路径对于正处于 Qt 5.15 代码库向 Qt 6.11 LTS 跨越式迁移通道中的研发团队而言围绕 QByteArray 开展的系统性重构工作既是消除编译告警的核心战场也是挖掘运行时系统性能红利的黄金窗口。以下提炼出在真实工程环境下应当贯彻的四项核心重构实践。诊断并阻断析构崩溃~QByteArray Segment Fault在迁移重构早期阶段部分研发团队会在包含 QByteArray 析构、返回局部字节变量的复杂执行路径中遭遇令人费解的段错误Segmentation Fault崩溃。分析表明该问题的物理本质并非 Qt 6 底层代码存在漏洞而是由于研发团队在大型工程中错误混用了 Debug 与 Release 模式下的物理二进制模块。由于 Qt 6 的 QArrayDataPointer 统一了底座并采用了极其敏捷的指针直接释放管理Debug 与 Release 构建下的物理堆内存结构有着根本性的分配尺寸差异。如果应用的主程序Debug加载了 Release 构建的第三方 Qt 动态链接库在调用 ~QArrayDataPointer() 析构分配在其上的字节数组时会因内存堆对齐错误触发操作系统内核的堆保护机制产生难以定位的崩溃。因此工程重构的首要任务是必须实施彻底的清理与构建环境隔离确保整个依赖树的二进制兼容性ABI绝对一致。全面采用静态断言与元编程守卫重写高频 API为了彻底消灭由于 qsizetype 寻址拓展引入的几万个窄化转换告警应当贯彻如下的重构操作避免在循环计数和下标遍历中显式使用 int// ❌ 存在窄化隐患的传统遗留写法for(inti0;idataPayload.size();i){process(dataPayload[i]);}// 符合现代 C20 与 Qt 6 规范的高性能重构写法for(qsizetype i0;idataPayload.size();i){process(dataPayload[i]);}// 或者直接使用基于范围的 for 循环Range-based forfor(charbyteValue:dataPayload){process(byteValue);}重构外部 C 函数的数据接口在必须将 QByteArray::size() 传递给接收 int 或 size_t 的第三方底层库如 OpenSSL 或特定解密硬件驱动时不要依赖编译器的隐式窄化转码而应当通过显式的静态断言或物理转码进行安全约束// 显式断言边界安全并强转抵御溢出风险Q_ASSERT(dataPayload.size()std::numeric_limitsint::max());thirdParty_legacy_API(dataPayload.constData(),static_castint(dataPayload.size()));实施极致零分配用 QByteArrayView 替换只读形参重塑所有内部模块的数据交互通道这是大幅减少数据链路动态内存分配的最佳工程路径清理只读函数重载在任何需要只读字节流的地方将所有的形参 void processData(const QByteArray array)void processData(const char *rawData, int len) 统一重构重写为 void processData(QByteArrayView dataView)确保数据生命周期安全在将参数改为 QByteArrayView 传递后需要对包含高频回调、异步槽函数执行的异步执行路径进行深度生存期审计。必须保证在只读视图存续期间底层的字节拥有者容器如原生的 QByteArray不会因为析构、超出局部作用域或发生修改导致物理内存重分配而退化为虚空悬挂指针。若代码路径存在无法完全预知、不可控的重分配操作必须通过调用视图的 .toByteArray() 强行物理克隆出一个拥有物理控制权的本地实例来锁死内存生存期。严防由于物理扩容导致的隐式迭代器悬空大型工程重构中另一项必须重点防御的物理漏洞在于由于扩容行为造成的物理重分配和指针失效。在 Qt 5.15 下能够侥幸过关的代码在 Qt 6.11 极致追求性能的重分配器下会迅速暴露隐患// ❌ 存在致命悬挂漏洞的错误用法QByteArray dataContainerPacketHeader:;constchar*packetBeginPtrdataContainer.constData();// ⚠️ 该物理追加可能会由于触发预留空间不足导致整段物理内存发生全局堆迁移dataContainer.append(readSocketPayload());// 此时 packetBeginPtr 可能已指向被系统标记回收的野内存段parseHeader(packetBeginPtr);重构的工程规约应当严格规定在对 QByteArray 进行任何可能改变尺寸、容量的操作之后凡是先前已经解析并暂存的裸指针、参考引用以及各类内部迭代器必须立即全部废弃并重新初始化。这种规约虽然在编码控制上增加了心智负担但能换来极高可靠、坚固且无懈可击的高性能应用。引用的著作QByteArray Class - Developpez.com, https://qt.developpez.com/doc/6.6/qbytearray/File and Datastream Functions | Qt Core | Qt 6.11.1 - Qt Documentation, https://doc.qt.io/qt-6/io-functions.htmlChanges to Qt Core - Qt Documentation, https://doc.qt.io/qt-6/qtcore-changes-qt6.htmlQByteArray Class Reference, https://doc.bccnsoft.com/docs/PyQt4/qbytearray.htmlPorting to Qt 6 | Qt 6.11 - Qt Documentation, https://doc.qt.io/qt-6/portingguide.htmlNew Features in Qt 6.0 - Qt Wiki, https://wiki.qt.io/New_Features_in_Qt_6.0QtCS2017 QtCore - Qt Wiki, https://wiki.qt.io/QtCS2017_QtCoreQList changes in Qt 6, https://www.qt.io/blog/qlist-changes-in-qt-6[Development] User-defined literals for QString (and QByteArray), https://lists.qt-project.org/pipermail/development/2021-March/041106.htmlChanges to Qt Core - Felgo, https://felgo.com/doc/qt/qtcore-changes-qt6/qbytearray.h source code [qtbase/src/corelib/text/qbytearray.h] - Codebrowser, https://codebrowser.dev/qt6/qtbase/src/corelib/text/qbytearray.h.html[Development] QString and related changes for Qt 6 - Mailing Lists, https://lists.qt-project.org/pipermail/development/2020-May/039455.htmlPySide6.QtCore.QByteArray - Qt for Python, https://doc.qt.io/qtforpython-6/PySide6/QtCore/QByteArray.htmlList of All Members for QByteArray | Qt Core | Qt 6.11.0 - Qt Documentation, https://doc.qt.io/qt-6/zh/qbytearray-members.htmlQBuffer Class | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbuffer.htmlQByteArray Class Maximum size and out-of-memory conditions is 2GB?? - Qt Forum, https://forum.qt.io/topic/134995/qbytearray-class-maximum-size-and-out-of-memory-conditions-is-2gbQByteArray Class | Qt Core 5.7 - MIT, https://stuff.mit.edu/afs/athena/software/texmaker_v5.0.2/qt57/doc/qtcore/qbytearray.htmlQt: Fix compilation on Qt5 and clang (!11709) · Merge requests - GitLab, https://gitlab.com/wireshark/wireshark/-/merge_requests/11709Qt 6 WASM: Uploading Playing Back Audio Files - KDAB, https://www.kdab.com/qt-6-wasm-uploading-playing-back-audio-files/QByteArray Class | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbytearray.htmlQt 5 to Qt 6 migration: a step-by-step tutorial - Spyrosoft, https://spyro-soft.com/expert-hub/qt5-to-qt-6migration-step-by-stepCutelyst - The Qt Web Framewok, https://cutelyst.org/blogQBinaryJson Namespace | Qt 5 Core Compatibility APIs | Qt 6.11.1, https://doc.qt.io/qt-6/qbinaryjson.htmlQByteArrayView Class - Developpez.com, https://qt.developpez.com/doc/6.2/qbytearrayview/QByteArrayView Class | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbytearrayview.htmlqbytearrayview.h source code [qtbase/src/corelib/text/qbytearrayview.h] - Codebrowser, https://codebrowser.dev/qt6/qtbase/src/corelib/text/qbytearrayview.h.htmlQByteArrayList Class | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbytearraylist.htmlObsolete Members for QByteArrayView | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbytearrayview-obsolete.htmlWhat’s New in Qt 6.8, https://doc.qt.io/qt-6/whatsnew68.htmlQt - QStringList to QByteArray - Stack Overflow, https://stackoverflow.com/questions/41759371/qt-qstringlist-to-qbytearrayC API changes | Qt 5.7 - MIT, https://stuff.mit.edu/afs/athena/software/texmaker_v5.0.2/qt57/doc/qtdoc/sourcebreaks.htmlQt C QString to QByteArray Conversion - Stack Overflow, https://stackoverflow.com/questions/37802575/qt-c-qstring-to-qbytearray-conversionMigrating from Qt 5 to Qt 6 - Bryan Cairns (VoidRealms) - Medium, https://bcairns.medium.com/migrating-from-qt-5-to-qt-6-ef6eda65c00bObsolete Members for QByteArray | Qt Core | Qt 6.11.1, https://doc.qt.io/qt-6/qbytearray-obsolete.htmlWhat’s New in Qt 6.10 - Qt Documentation, https://doc.qt.io/qt-6/whatsnew610.htmlList of All Members for QByteArray | Qt Core 6.8.7, https://doc.qt.io/qt-6.8/ja/qbytearray-members.htmlQByteArrayList Class | Qt Core | Qt 6.11.1 - Qt Documentation, https://doc.qt.io/QT-6/qbytearraylist.htmlQt6 Migration: Upgrade Your GUI with Expert Tips - Witekio, https://witekio.com/blog/how-to-successfully-migrate-to-qt6/Porting from Qt 5 to Qt 6 – Top 3 reasons and steps to follow - Somco Software, https://somcosoftware.com/en/blog/porting-from-qt-5-to-qt-6.readAll succeed but Segmentation fault on ~QByteArray when function return | Qt Forum, https://forum.qt.io/topic/142772/readall-succeed-but-segmentation-fault-on-qbytearray-when-function-returnCrash when creating QT QList - c - Stack Overflow, https://stackoverflow.com/questions/78977378/crash-when-creating-qt-qlistHeap corruption when Enumerating QActions in a QMenu in 6.8.1 | Qt Forum, https://forum.qt.io/topic/160064/heap-corruption-when-enumerating-qactions-in-a-qmenu-in-6-8-1Convert QByteArray to uint8_t*(uint8_t array) - c - Stack Overflow, https://stackoverflow.com/questions/75306635/convert-qbytearray-to-uint8-tuint8-t-array