CN101000635A - 一种智能卡的海量数据存储与管理方法 - Google Patents

Abstract

本发明涉及微电子领域中的智能卡设计与应用技术，具体涉及一种智能卡的海量数据存储与管理方法。该方法在智能卡上建立一个具有基本存储、查询、比较、排序功能的数据库，该数据库的基本结构是两组链表，第一组只包括一个主链表，数据库中的所有记录按照一定的排序方式排成这个链表，使用该链表中的每个节点保存各记录的基本信息以及子链表的起始位置；第二组链表一子链表的数目与数据库中包含的记录数目相同，这些链表上所有的节点都是一个大小固定的“数据块”，属于一个记录的不同属性是按照“标识－长度－值”的结构存放在子链表中。本方法配合硬件方面的相应升级，可以极大地扩展现有智能卡的功能，使之成为新一代数据存储与管理平台。

Description

一种智能卡的海量数据存储与管理方法

技术领域

本发明涉及微电子领域中的智能卡设计与应用技术，具体涉及一种智能卡的海量数据存储与管理方法。

背景技术

随着社会发展的进步，人们对信息安全性的要求越来越高，而智能卡作为一种特殊的电子设备，因为其具有优异的安全性和可靠性，越来越多的成为现代社会中敏感信息的载体。目前，智能卡已经广泛应用于移动通信、银行、社保、公共交通、市政管理等各种领域，在整个社会生活中发挥着越来越大的作用。

智能卡之所以可以成为敏感信息的载体，是因为在其内部集成了具备计算功能的CPU和具备存储功能的数据存储区，其结构如附图1所示。智能卡的硬件平台由中央处理器110，数据存储区120和其它硬件模块130构成，在智能卡数据存储区中存储的数据可以是经过加密的，而且只能通过特定的方式读取出来，智能卡中的CPU可以对存储于数据存储区中的数据按照特定算法进行加密和分析，从而可以保证数据的安全性。同时，由于智能卡本身具有长时间保存数据的特性，使用智能卡可以方便、持久、安全的保存数据。

但是使用传统智能卡进行数据存储也有自身的缺点。一方面，传统智能卡数据存储区的空间非常有限，无法进行大量数据的存储；另一方面，在传统智能卡上，由于CPU处理能力有限，无法进行大量数据的管理。一般来说，传统智能卡的存储空间在K Bytes的量级，这样的存储空间只能存放很少的数据，不利于智能卡的进一步推广和应用。

随着微电子技术的进步，集成电路的集成度越来越高，这就为在智能卡上实现大规模的数据存储实现了可能。目前，已经出现了存储空间达到4MBytes甚至512M Bytes的可以集成到智能卡上的Flash存储器件，如果将这种器件集成到智能卡上，即可得到大容量的智能卡。同时，仅仅依靠硬件的升级是不够的，如果在智能卡软件方面不进行升级，将无法充分利用存储空间，或者无法对数据进行便捷的管理，将会影响大容量智能卡的应用。在将软件、硬件进行升级之后的智能卡，可以存放大量的数据，将会极大地促进智能卡的应用。例如，可以将高考试题、机密文件、秘密联系号码等敏感信息存入智能卡中，就可以提高这些信息的安全性，避免机密信息的遗失。

在传统智能卡上，所有的信息是以记录或者普通文件的形式存储的，这些记录或者文件可以保存的数据非常有限，而且每个文件只能存放一种数据，这都限制了智能卡对数据进行操作。因此使用传统智能卡的结构无法实现海量数据的存储和管理，必须考虑软件的升级。

但是，由于智能卡本身的使用环境、使用条件具有自身的特点，不能简单的采用普通PC上的数据库进行数据管理。这是因为：第一，智能卡的CPU即使进行升级，仍然无法与PC上主频达到“G Hz”量级的CPU相比，这就意味着智能卡上的数据处理绝对无法达到PC端的级别；第二，一般来说，智能卡都是应用在手机等手持或移动设备中，这些设备电源的能量非常有限，因此智能卡上的数据库不能进行大量过于复杂、漫长的操作，否则将会极大影响电池寿命，缩短手持设备的待机时间；第三，即使扩大智能卡的存储空间达到M Bytes的量级，这一数据空间仍然远远小于PC上数据库的尺寸(10²M Bytes甚至更高)。因此，在实现智能卡数据库软件的时候，不能直接将PC端的数据库软件进行简化、删减后实施，而必须重新设计整个数据库***，使之适应智能卡环境。

在目前，尚没有一种智能卡在硬件和软件上可以实现海量数据的存储与管理。

发明内容

本发明的目的是为了扩展智能卡在安全领域的应用，提高智能卡的数据处理能力，而提出的一种智能卡的海量数据存储与管理方法，该方法可以极大的扩展现有智能卡的功能，使之成为新一代数据存储与管理平台。

本发明的技术方案如下：一种智能卡的海量数据存储与管理方法，该方法在智能卡上建立一个具有基本存储、查询、比较、排序功能的数据库，该数据库的基本结构是两组链表，第一组只包括一个主链表，主链表由数据库中的所有记录按照一定的排序方式组成，使用该链表中的每个节点保存各记录的基本信息和储存各记录详细信息的子链表的起始位置，并将数据库中最重要的信息设定为每条记录的主名称，每个节点都是一个大小相同的“数据块”；第二组链表是子链表，子链表的数目与数据库中包含的记录数目相同，每个记录的数据都占用一个单独的“子链表”，这些子链表上所有的节点都是一个大小固定的“数据块”，属于一个记录的不同属性是按照“标识-长度-值”的结构存放在子链表中。

进一步来说，在上述智能卡的海量数据存储与管理方法中，数据库结构由配置文件、属性文件、分配文件以及记录文件四个文件组成。

其中，配置文件所存储的内容包括主名称长度、主名称的存储类型、数据库属性文件的文件ID、数据库分配文件的文件ID、数据库记录文件的文件ID，以及排序时排列在第一位的数据在数据库分配文件中的记录号。

属性文件按照记录的格式保存数据库中各组数据的属性信息，内容包括属性名称、存储此属性所需的最大尺寸、此属性的类型、此属性的相关参数，以及为此属性分配的标识。

分配文件按照固定的排列方式构成一个完整的链表，链表中的每个节点是一个长度相同的数据块，每个数据块对应数据库中的一组数据，内容包括此组数据的主名称、主检索信息、此组数据中的一些重要信息，以及此组数据在数据库中起始数据块的编号和数据库主链表中的下一个记录的记录号。

记录文件存储数据库的大批数据文件，采用数据块+链表的结构进行存储，将每个数据块结合起来，构成一个完整的数据记录。

进一步，如上所述的一种智能卡的海量数据存储与管理方法，当向数据库中增加一组数据时，首先在记录文件中找到一个空闲的数据块，获得该数据块的数据块编号，并在记录文件中写入该组数据的信息；然后将该数据块编号写入分配文件中；最后根据这组新增数据的相关内容更新分配文件，从而使分配文件被更新为新的完整的数据库链表。

进一步，如上所述的一种智能卡的海量数据存储与管理方法，当向数据库中的数据更新属性时，首先根据需要更新的数据属性的大小判断当前是否有足够空间存储相关信息，并在记录文件中分配足够的数据块并且构建新的数据记录链表，然后将新的属性写入到记录文件中的这些数据块中。

进一步，如上所述的一种智能卡的海量数据存储与管理方法，当进行数据库的记录查询时，首先通过数据库配置文件获得数据库主链表中的第一记录的记录号，然后根据此记录号对应的数据分配文件中的记录信息获取下一记录的记录号，从而获得数据库主链表，最后根据该记录在数据分配文件中指明的“记录文件中的数据块编号”获取此记录在数据记录文件中保存的所有信息。

本发明的优点在于：

1.通过使用数据库配置文件和数据库属性文件，将数据库中所需的所有信息都保存在文件中，这样，用户在使用数据库的时候，只需要对这些文件进行操作就可以，而不必更改数据库底层的操作函数。

2.在数据库操作过程中，绝大多数操作是对名称、主要检索信息等常用信息的操作，使用数据库分配文件保存这些常用信息，可以减少对文件***的读写，提高程序的运行速度。

3.使用数据块+链表的结构保存属于该记录的所有信息，这种结构既可以保证在使用的过程中顺利地对数据进行读写和检索，又可以避免使用普通记录文件进行数据存储造成空间的浪费。

4.本数据库使用两层链表的结构，从数据库配置文件中可以找到第一层链表中的首组记录，进而建立起数据库主链表。在需要显示属于某组记录的详细信息时，使用第二层链表，获取该记录的全部信息。这样的数据组织方式可以提高在遍历、检索、列表过程中的运行速度。

附图说明

图1为智能卡的基本硬件结构图。

图2为智能卡数据库的组成结构图。

图3为在基于本发明的数据库中新增一组数据的工作流程图。

图4为在基于本发明的数据库中新增数据属性的工作流程图。

具体实施方式

下面结合附图和实施例对本发明作进一步详细描述。本具体实施方式是一种智能卡对海量电话簿信息进行存储和管理的方法。

为了实现该方法，在硬件方面，需使用具有高性能、高速度的CPU作为中央处理器，使用容量达到M级的FLASH器件作为数据存储器。高性能的重要处理器可以进行大量数据的加解密处理以及快速查询，提供了进行大量数据管理及查询的基本条件；大容量的数据存储器可以为用户提供足够的数据存储空间。如图1所示，实现本发明的智能卡的硬件平台包括中央处理器110，数据存储器120和其它硬件模块130。在本实施例实现的智能卡100中，中央处理器110是一个基于ARM7的CPU，其工作频率最高可达40M Hz。本实施例中使用的数据存储器120是一块具有4M Bytes存储空间的Flash。这些硬件资源可以满足海量数据存储和管理对硬件的要求。

在软件方面，需要实现一个具备基本存储、查询、比较、排序功能的数据库。数据库的基本结构是两组链表。第一组链表只有一个，数据库中所有的记录按照一定的排序方式(如按拼音排序)排成这个“链”，这个链中的每个节点保存了各记录的基本信息，以及保存了储存各记录详细信息的“子链”的起始位置，并将数据库中最重要的信息设定为每条记录的主名称。每个节点都是一个长度相同的“数据块”。第二组链表有若干个，其数目与数据库中包含的记录数目相同，每个记录的数据都占用一个单独的“链”。这些链上所有的节点都是一个大小固定的“数据块”，属于一个记录的不同属性是按照“标识-长度-值”的结构存放在链表中。在数据库中，最重要的信息是每条记录的主名称。

所谓“链表”是由一系列节点组成的数据结构，每个节点有两个域组成：一个是数据域，在本发明中用来存放各种数据；一个是地址域，在本发明中用来存放下一节点的“数据块编号”。

本发明实现的智能卡数据库结构由配置文件、属性文件、分配文件以及核心记录文件四个文件组成。这些文件之间的关系如图2所示。

各文件的结构如下：

1.配置文件：

配置文件存储如下内容：主名称长度，主名称的存储类型(UCS2编码，GB2312编码，ASCII编码，二进制数等)，数据库属性文件的文件ID，数据库分配文件的文件ID，数据库记录文件的文件ID。同时，本文件中还保存在排序时排列在第一位的数据在数据库分配文件中的记录号。

配置文件是一个数据库的核心文件，通过这个文件，就可以找到与此数据库相关的所有文件，进而对所有信息进行管理。

2.属性文件：

数据库属性文件按照记录的格式保存此数据库中各组数据的属性信息，包括：属性名称、存储此属性所需的最大尺寸、此属性的类型(UCS2编码，GB2312编码，ASCII编码，二进制数等)、此属性的相关参数(是否支持查询、长度是否可能更改等)，以及为此属性分配的标识--Tag。其中“属性名称”是指在用户操作数据库属性时显示的名称。本文件中的信息对数据库中的所有信息均有效，换句话说，在整个数据库中，所有的记录使用相同的属性信息。

属性文件决定了一个数据库的外观，例如：如果要将数据库中的属性进行个性化，只需更改此属性文件就可以，而不必更改数据库中的相关代码。

3.分配文件：

数据库分配文件是按照记录的格式进行组织的，文件中的每条记录都是一个“数据块”，构成了链表中的一个节点，保存数据库中的一组数据。包括此组数据的主名称、主检索信息、此组数据中的某些重要信息，以及此组数据在数据库“数据文件”中起始“数据块”的编号。同时，在每一记录中还保存了在排序时排列在下一位的“数据块”数据的编号，这样就构成了数据库的主链表。

分配文件中的信息是整个数据库中最重要的信息，在数据库进行操作的时候，都是通过数据分配文件中的信息进行检索的。通过将这些基本的数据信息保存在这同一个文件中，可以减少数据库运行过程中对文件***的访问，提高程序运行速度。

4.记录文件

数据库记录文件是数据库中实际存放大批数据的文件，采用数据块+链表的结构进行存储，按照链表的格式将每个数据块结合起来，就可构成一个完整的数据记录。对于不同的数据库(例如电话簿库、短信库等)，每个数据块的长度都可以是不相同的，但是一个数据库内部，所有数据块的长度必须是相同的。在设计数据块的长度的时候应当仔细考虑，必须保证：1.每个数据块的长度不能太小，否则会增加搜索时间。2.每个数据块的长度不能太大，否则浪费的空间较多。

一般来说，数据记录文件只与数据分配文件有直接的数据交互。数据库根据数据分配文件中记录的“首数据块编号”找到数据记录文件中保存的信息，通过将所有数据组织为一个链表进行管理。

基于这种设计的数据库其实是两类链表组成了完整的数据库。第一类链表为数据分配文件中的记录构成的链表，即数据库的主链表。这个链表串起了数据分配文件中所有的记录，也就构成了整个数据库的主体。在整个数据库中这类链表只有一张，可以将整个数据库中的信息串起来。在显示数据库的全部信息时，就通过这张链表进行遍历和检索。第二类链表为数据记录文件中存在的链表。数据库中存在多少组数据，这一类链表就有多少张。每张链表包含了属于每组数据的完整信息。

本实施例的数据库功能是处理各联系人的各种信息。包括联系人的姓名(数据库主名称)、手机号码、公司联系电话、家庭联系电话、电子邮件地址等。

数据库配置文件的结构如下表所示：

文件ID：  6F01h
				字符顺序	值	描述	长度

0x00	(0Eh)主名称长度	主名称的全部长度(Bytes)，在本实施例中，主名称的长度为14字节	1
				0x01	(01h)主名称的类型	主名称的类型，在本实施例中，主名称的类型必须为UCS2，因此这一字节为01h，代表为“UCS2”类型	1
0x02	(6Fh  02h)数据库属性文件ID	本数据库属性文件的FID。此“属性文件”和本“配置文件”都位于内部D-Flash的7F30目录下	2
				0x04	(6Fh 03h)数据库分配文件ID	本数据库分配文件的FID。此“分配文件”位于外部D-Flash中	2
0x06	(6Fh  04h)数据库记录文件ID	本数据库记录文件的FID。此“记录文件”位于外部D-Flash中	2
				0x08	(00h 01h)	链表中第一组数据在数据分配文件中的记录号通过本记录号信息，得到了链表的第一个数据块的记录号，从而可以构建数据库链表	2

在本实施例中，数据库属性文件保存属于每个联系人的属性信息，例如“移动电话”、“公司电话”等。通过访问本文件，可以获知本数据库中保存的属性类型。在用户使用本数据库的时候，如果希望将数据库中保存的“移动电话”改为“手机”，只需修改本文件即可，而不需要修改内部程序。

数据库属性文件是一个记录文件，每个记录的结构如下表所示：

字符顺序	值	描述	长度
				0x00	属性名称(LV结构)	一般来说，这里保存的是汉字“移动电话”或者“公司电话”等的UCS2编码	X
X	存放此属性的最大尺寸	存放此属性所需的最大空间(Bytes)一般来说，对于存放电话类型的属性，这里的值为20，因为电话号码的长度不会超过20字节	1
				X+1	此属性的类型	表明此属性是一组数字(例如电话号码)还是一组汉字(例如联系地址)等	1

X+2

分配给此属性的TAG

各个属性有自己的TAG，以便在数据库记录文件中安装T-L-V的结构进行组织

1

在本实施例中，数据库分配文件保存各联系人的基本信息，例如姓名、姓名的英文首字母索引等，还保存了属于本联系人的数据在数据记录文件中的首数据块编号，此外，还保存了数据库主链表中的下一个记录的记录号，从而构成整个数据库的主链表。

数据库分配文件是按照数据块的格式进行存储的，每个数据块的结构如下表所示：

字符顺序	值	描述	长度
				0x00	联系人姓名	按照L-V结构组织的联系人姓名，“L”显示后续“姓名”的长度	15
0x0F	联系人姓氏声母的ASCii码	为了便于进行快速检索，在这里记录联系人姓氏的声母	1
				0x10	数据记录文件中的起始数据块编号	存放属于此记录的各属性构成的链表在数据记录文件中起始数据块的编号所有这些属性都保存在数据记录文件中，通过这个编号可以获取数据记录链表进而获取所有相关信息	2
0x12	该记录的数据的总长度	存放该记录各个属性在数据库记录文件中的总长度	2
				0x14	下一数据块的编号	进行排序时，下一数据块在本文件中的编号这个编号是构成数据库主链表的核心	2

在本实施例中，数据库记录文件也是按照数据块的格式进行存储的，每个数据块的结构如下表所示。若干个数据块构成一个链表，储存属于某联系人的全部信息。在本实施例中，一个数据决有64个字节，前两个字节保存了与链表相关的信息。

数据记录文件中每条记录的结构如下：

字符顺序

值

描述

长度

0x00	下一数据块的编号	如果为0xFFFF，表明此数据块没有用到0x0000表明本数据块是一个链表的最后一个	2
				0x02	保存的数据		62

通过本实施例可以看到，使用本发明提出的数据库结构，可以轻易的管理与电话号码相关的全部信息。在用户使用本数据库查看联系人信息的时候，首先通过数据库配置文件获得数据库主链表中的第一记录的记录号，然后根据此记录号对应的数据分配文件中的记录信息获取下一记录的记录号，从而获得数据库主链表，这样，就可以方便地按照顺序列出数据库中所有联系人的姓名。如果用户希望选择某个联系人，则可以根据该联系人在数据分配文件中指明的“记录文件中的数据块编号”获取此联系人在数据记录文件中保存的所有信息，从而完成数据的检索。在进行数据库查询时，可以采用类似的方法，顺利的检索到全部信息。而且使用本发明的数据库结构，每组数据占用的空间完全由数据量本身的大小决定，可以节约大量的数据存储空间。

为更加详细地说明本发明的思想，这里以更加具体的事例进行说明：

假设号簿数据库中有很多联系人，按顺序排列的第一位是“阿龙”，第二位是“陈虎”，“阿龙”的姓名等基本信息在“分配文件”中保存在第0x10号数据块，“陈虎”的姓名等基本信息在“分配文件”中保存在第0x17号数据块。再假设“阿龙”所具有的属性包括“手机号码”、“公司电话”、“邮件地址”、“家庭电话”等信息。所有信息按照“标识-长度-值”的格式整理到一起后，共有0x53个字节。

则分配文件中0x10号数据块中的内容应该为：

字符顺序	值	描述	长度
				0x00	联系人姓名	按照长度-值结构组织的联系人姓名，其中长度为4，“值”的内容为“阿龙”，后续空间无用。	15
0x0F	联系人姓氏声母的ASCii码	即“A”的Ascii码	1

0x10	数据记录文件中的起始数据块编号	存放属于“阿龙”的所有信息的链表在数据记录文件中的起始块的编号，假设为“0x0004”。	2
				0x12	该记录的数据的总长度	存放属于“阿龙”的所有信息的总长度，为0x53	2
0x14	下一数据块的编号	进行排序时，下一数据块在本文件中的编号，即“陈虎”所在的数据库的编号，即“0x0017”因此这里这个编号是构成数据库主链表的核心	2

属于“阿龙”的0x53个字节的数据格式如下：

0x01(“手机号码”的标识)

0x0B(“手机”号码的长度)

0x31

0x33

0x39(这些是按照ASCii格式保存的手机号码的“值”)

0x05(“公司电话”的标识)

0x0B(“公司电话”的长度)

0x30

0x31

0x35

(按照ASCii格式保存的公司电话的“值”)

以此类推，所有信息按照“标识-长度-值”的格式整理到一起，共有0x53个字节。

在记录文件中，第0x0004号数据块中的内容如下：

字符顺序

值

描述

长度

0x00	下一数据块的编号	0x0013(由于“阿龙”的总数据有0x53，超过了一个“数据块”中可以容纳的上限“62”个，因此需要有两个数据块构成一个链表，共同存放属于“阿龙”的0x53个字节的数据，下一数据块的编号是0x0013)	2
				0x02	属于“阿龙”信息的前62个字节		62

同时，在记录文件中，第0x0013号数据块中的内容如下：

字符顺序	值	描述	长度
				0x00	下一数据块的编号	0x0000(由于“阿龙”的总数据有0x53，超过了一个“数据块”中可以容纳的上限“62”个，因此需要有两个数据块构成一个链表，共同存放属于“阿龙”的0x53个字节的数据。这里已经是第二块了，不需要后续数据块，因此这里使用“0x0000”代表链表到达结尾。)	2
0x02	属于“阿龙”信息的剩余	用不到的位置空闲下来	62

考虑到在此公开的对本发明的描述和特殊的实施例，本发明的其他实施例对于本领域的技术人员来说是显而易见的。这些说明和实施例仅作为例子来考虑，它们都属于由所附权利要求所指示的本发明的保护范围和精神之内。

Claims (10)

1.一种智能卡的海量数据存储与管理方法，该方法在智能卡上建立一个具有基本存储、查询、比较、排序功能的数据库，其特征在于：该数据库的基本结构是两组链表，第一组只包括一个主链表，主链表由数据库中的所有记录组成，使用该链表中的每个节点保存各记录的基本信息和储存各记录详细信息的子链表的起始位置，并将数据库中最重要的信息设定为每条记录的主名称，每个节点都是一个大小相同的“数据块”；第二组链表是子链表，子链表的数目与数据库中包含的记录数目相同，每个记录的数据都占用一个单独的“子链表”，这些子链表上所有的节点都是一个大小固定的“数据块”，属于一个记录的不同属性是按照“标识-长度-值”的结构存放在子链表中。

2.如权利要求1所述智能卡的海量数据存储与管理方法，其特征在于：所述的数据库结构由配置文件、属性文件、分配文件以及记录文件四个文件组成。

3.如权利要求2所述智能卡的海量数据存储与管理方法，其特征在于：所述的配置文件存储的内容包括主名称长度、主名称的存储类型、数据库属性文件的文件ID、数据库分配文件的文件ID、数据库记录文件的文件ID，以及排序时排列在第一位的数据在数据库分配文件中的记录号。

4.如权利要求2所述智能卡的海量数据存储与管理方法，其特征在于：所述的属性文件按照记录的格式保存数据库中各组数据的属性信息，内容包括属性名称、存储此属性所需的最大尺寸、此属性的类型、此属性的相关参数，以及为此属性分配的标识。

5.如权利要求2所述智能卡的海量数据存储与管理方法，其特征在于：所述的分配文件按照固定的排列方式构成一个完整的链表，链表中的每个节点是一个长度相同的数据块。

6.如权利要求5所述智能卡的海量数据存储与管理方法，其特征在于：所述的分配文件的每个数据块对应数据库中的一组数据，内容包括此组数据的主名称、主检索信息，以及此组数据在数据库中起始数据块的编号和数据库主链表中的下一个记录的记录号。

7.如权利要求2所述智能卡的海量数据存储与管理方法，其特征在于：所述的记录文件存储数据库的大批数据文件，采用数据块+链表的结构进行存储，将每个数据块结合起来，构成一个完整的数据记录。

8.如权利要求2或3或4或5或6或7所述智能卡的海量数据存储与管理方法，其特征在于：当向数据库中增加一组数据时，首先在记录文件中找到一个空闲的数据块，获得该数据块的数据块编号，并在记录文件中写入该组数据的信息；然后将该数据块编号写入分配文件中；最后根据这组新增数据的相关内容更新分配文件，从而使分配文件被更新为新的完整的数据库链表。

9.如权利要求2或3或4或5或6或7所述智能卡的海量数据存储与管理方法，其特征在于：当向数据库中的数据更新属性时，首先根据需要更新的数据属性的大小判断当前是否有足够空间存储相关信息，并在记录文件中分配足够的数据块并且构建新的数据记录链表，然后将新的属性写入到记录文件中的这些数据块中。

10.如权利要求2或3或4或5或6或7所述智能卡的海量数据存储与管理方法，其特征在于：当进行数据库的记录查询时，首先通过数据库配置文件获得数据库主链表中的第一记录的记录号，然后根据此记录号对应的数据分配文件中的记录信息获取下一记录的记录号，从而获得数据库主链表，最后根据该记录在数据分配文件中指明的“记录文件中的数据块编号”获取此记录在数据记录文件中保存的所有信息。

Images