我们知道Qt中的QBitArray类支持在位(bit)的层次上进行数据操作。本文剖析该类在二进制文件读写时的一些要点。

我们知道,在Qt中,QDataStream类对于二进制文件的读写提供了诸多便利,需要注意的是QBitArray的读写依赖于QDataStream类。

使用QBitArray向文件中写数据:

    QFile file("C:\\Users\\lenovo\\Desktop\\测试");
    file.open(QIODevice::WriteOnly);//只写
    QDataStream input(&file);
    QBitArray bit(5);//构造大小为5的位数组
    bit[0]=1;bit[1]=0;bit[2]=0;bit[3]=1;bit[4]=1;
    input<<bit;//向文件中写入数据10011
    file.close();

使用QBitArray向文件中读数据:

    QFile file("C:\\Users\\lenovo\\Desktop\\测试");
    file.open(QIODevice::ReadOnly);//只读
    QDataStream output(&file);
    QBitArray bit;//此处不需要指定位数组的大小,后面解释
    output>>bit;//从文件中读取数据,可以得到10011
    file.close();

上面只是读写了一个简单的位数组,是最简单的例子。但是当我们需要连续多次的读写这种位数组时,甚至想要一位一位读取这些位信息时,该如何处理呢?

先明确一句话:在进行读操作时,无法根据指定的QBitArray位数组的大小(size)来读取。也就是说实际上读取到的size()大小,与自己设定的大小并不一致。(这个结论个人实验得出)

以如下代码为例:

    QFile file("C:\\Users\\lenovo\\Desktop\\测试");//该文件中已经存在位信息10011
    file.open(QIODevice::ReadOnly);//只读
    QDataStream output(&file);
    QBitArray bit(3);//此处我设置位数组的大小为3,我只想读取3位二进制信息
    output>>bit;//读取
    qDebug()<<bit.size();//输出结果为5,显然与我们希望的不一样。原因后面解释
    file.close();

究竟是什么原因造成的呢??我们开始进入重点:
分析这个原因我们需要分析QBitArray在文件中的编码规则:

每一个完整的QBitArray对象,存储进文件后,其编码格式都是固定的:位数组的大小+位数组的实际数据。以位数据10001为例:

其编码为:(图片中每个数字都是16进制的)

 1、4个字节存储该位数组的位数,00 00 00 05就表示这个位数组有5位

2、剩下部分存储具体的位数据。可是我们的数据是1001 1为什么存储成了19呢???原因如下:

存储QBitArray对象时,采用的是逆存储方式,即先存储后四个位信息,再存储前四个位信息。19中的 “1” 表示 “0001”,“9”表示“10001”

注意这种情况:

    QFile file("C:\\Users\\lenovo\\Desktop\\测试");
    file.open(QIODevice::WriteOnly);//只写
    QDataStream input(&file);
    QBitArray bit(5);//构造大小为5的位数组
    bit[0]=1;bit[1]=0;bit[2]=0;bit[3]=1;bit[4]=1;
    input<<bit[0];//写入数据

这种情况下,向文件中写入了一个位信息,这里并没有写入完整的对象。那么存储时,也就没有完整的结构。其编码如下图:

相当于向文件写入了一个数字1。如果bit[0]=0,那么相当于向文件中写入了一个数字0。

总结:也就是说,每个QBitArray对象存储进文件后的结构都是确定了的。所以如果想一个位一个位的读取,那么就会破坏掉这个对象的编码结构,以至于出现读取错误的情况。想要正确的读取出所有的位信息,必须完整的读取每个QBitArray对象,所以在读取的时候我们不需要设置位数组的大小。也就是说,写入的时候写了多少个QBitArray对象,读取的时候就得用多少个QBitArray对象。

版权声明:本文为cxhblogs原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/cxhblogs/p/9985402.html