日志文件的编码、解析、存储方法和装置与流程

本申请涉及计算机技术领域，特别是涉及一种日志文件的编码方法、一种日志文件的编码装置、一种日志文件的存储方法、一种日志文件的存储装置、一种日志文件的解析方法和一种日志文件的解析装置。

背景技术：

客户端(client)也称为用户端，是指与服务器相对应、为客户提供本地服务的一种应用程序。较常用的客户端包括万维网使用的网页浏览器、收寄电子邮件时的电子邮件客户端，以及，用于即时通讯的聊天软件等等。

用户在使用客户端应用程序的过程中，经常会因为各种原因导致出现如应用程序崩溃等业务异常或系统异常。为了改进客户端应用程序的系统性能，开发人员通常需要对出现的异常进行排查、复现。在排查、复现出现的异常时，便需要客户端应用程序提供尽量充分和完整的异常事件信息。

但是，异常事件发生的频率高、数据量大，经常会由于内存数据丢失、文件写入失败、网络请求失败等等原因导致异常事件的数据无法完整的记录。在记录数据时，如果数据处理的性能不够高，也会对应用程序的使用性能造成巨大的影响。此外，随着需要记录的数据量的急速膨胀，按照现有的数据存储方式，还会消耗掉用户终端大量的存储空间以及网络流量。

技术实现要素：

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种日志文件的编码方法、一种日志文件的编码装置、一种日志文件的存储方法、一种日志文件的存储装置、一种日志文件的解析方法和相应的一种日志文件的解析装置。

为了解决上述问题，本申请公开了一种日志文件的编码方法，包括：

获取客户端的事件数据，所述事件数据包括客户端描述信息、事件描述信息，以及，事件记录数据；

依据所述客户端描述信息和事件描述信息生成文本描述段；

依据所述事件记录数据生成事件数据体；

将所述文本描述段和事件数据体编码为日志文件。

为了解决上述问题，本申请公开了一种日志文件的存储方法，包括：

获取客户端的事件数据；

将所述事件数据编码为日志文件；

确定内存地址空间；

存储所述日志文件至所述内存地址空间。

为了解决上述问题，本申请公开了一种日志文件的解析方法，包括：

获取日志文件，所述日志文件包括文本描述段和事件数据体；

读取所述文本描述段中的事件描述信息；

根据所述事件描述信息对所述事件数据体进行解析。

为了解决上述问题，本申请公开了一种日志文件的编码装置，包括：

事件数据获取模块，用于获取客户端的事件数据，所述事件数据包括客户端描述信息、事件描述信息，以及，事件记录数据；

文本描述段生成模块，用于依据所述客户端描述信息和事件描述信息生成文本描述段；

事件数据体生成模块，用于依据所述事件记录数据生成事件数据体；

日志文件编码模块，用于将所述文本描述段和事件数据体编码为日志文件。

为了解决上述问题，本申请公开了一种日志文件的存储装置，包括：

事件数据获取模块，用于获取客户端的事件数据；

日志文件编码模块，用于将所述事件数据编码为日志文件；

内存地址空间确定模块，用于确定内存地址空间；

日志文件存储模块，用于存储所述日志文件至所述内存地址空间。

为了解决上述问题，本申请公开了一种日志文件的解析装置，包括：

日志文件获取模块，用于获取日志文件，所述日志文件包括文本描述段和事件数据体；

事件描述信息读取模块，用于读取所述文本描述段中的事件描述信息；

事件数据体解析模块，用于根据所述事件描述信息对所述事件数据体进行解析。

与背景技术相比，本申请实施例包括以下优点：

本申请实施例，通过获取客户端的事件数据，并依据该事件数据中的客户端描述信息和事件描述信息生成文本描述段，依据事件记录数据生成事件数据体，从而可以将文本描述段和事件数据体编码为日志文件。本实施例通过提供一种日志文件的编码协议，从而可以按照该编码协议统一地对客户端的各类数据进行编码，在压缩比上，本实施例的编码协议比现在广泛使用的json数据协议提高了5倍以上，解决了现有技术中客户端的数据膨胀对设备或客户端造成的影响。同时，本实施例通过将事件数据中类型、数据结构及编码信息通过流式数据体的描述信息写入数据文件，对于任何平台的数据都可以通过流式数据体中每个记录类型代表的含义和格式进行数据解析，由于数据文件本身就带有对数据体的解释信息，这样在进行数据解析的过程中就无需依赖数据之外的其他信息，极大的保证了数据的可扩展性和灵活性，方便了编码后的日志文件在多个不同的平台中进行使用，提高了数据的跨平台兼容性，极大地减轻了数据频繁变化、扩展给数据解析带来的复杂性。

附图说明

图1是本申请的一种日志文件的编码方法实施例的步骤流程图；

图2是本申请的一种二进制数据体的示意图；

图3是本申请的一种日志文件的编码结构图；

图4是本申请的一种日志文件的存储方法实施例的步骤流程图；

图5是本申请的一种日志文件的存储方法的设计框图；

图6是本申请的一种日志文件的解析方法实施例的步骤流程图；

图7是本申请的一种日志文件的解析方法的示意图；

图8是本申请的一种日志文件的编码装置实施例的结构框图；

图9是本申请的一种日志文件的存储装置实施例的结构框图；

图10是本申请的一种日志文件的解析装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，示出了本申请的一种日志文件的编码方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，获取客户端的事件数据，所述事件数据包括客户端描述信息、事件描述信息，以及，事件记录数据；

需要说明的是，客户端可以是指安装在手机、平板电脑等各类终端设备上的应用程序。例如，安装在手机上的手机淘宝app、支付宝app等等。本实施例对终端设备及客户端的类型不作限定。

在本申请实施例中，事件数据可以包括客户端描述信息、事件描述信息，以及，事件记录数据等等。

其中，客户端描述信息可以包括客户端信息(即客户端或应用程序本身的信息)、设备信息(即安装该客户端或应用程序的终端设备的信息)，以及，环境信息(即用户在使用该客户端或应用程序时的网络状态等信息)。

在具体实现中，客户端信息可以包括如下各种信息中的至少一种：

协议版本号、应用版本号、设备标识信息。

设备信息可以包括如下各种信息中的至少一种：

设备硬件类型、cpu核数、cpu主频、显示器参数、操作系统版本、设备支持的传感器类型。

环境信息可以包括如下各种信息中的至少一种：

设备网络状态、运营商信息。

当然，以上仅为一种示例，根据实际需要的不同，上述各类信息还可以包括其他不同的信息或数据，本实施例对此不作限定。

在本申请实施例中，事件描述信息可以包括各个事件对应的事件记录数据的事件信息和格式信息。

各个事件可以是客户端自身产生的事件，或者用户在使用该客户端时产生的事件。例如，系统事件、用户操作事件、应用程序执行事件、网络事件等等。

事件信息可以是在上述各类事件发生时所记录的该事件的相关信息或数据，格式信息则表示了在记录上述事件时所采用的记录格式或参数的信息。

在本申请实施例中，事件记录数据可以是完整地记录的发生上述各类事件时的信息或数据。

步骤102，依据所述客户端描述信息和事件描述信息生成文本描述段；

在本申请实施例中，可以依据获得的客户端描述信息和事件描述信息生成日志文件的文本描述段。

因此，一份日志文件的文本描述段可以包括客户端信息(协议版本号、应用版本号、设备标识信息等)、设备信息(设备硬件类型、cpu核数、cpu主频、显示器参数、操作系统版本、设备支持的传感器类型等)、环境信息(设备网络状态、运营商信息等)，以及，事件描述信息。

步骤103，依据所述事件记录数据生成事件数据体；

在本申请实施例中，事件数据体可以是二进制数据体，该二进制数据体可以串行记录客户端或应用程序的各个事件。

在具体实现中，二进制数据体可以包括多条记录，每条记录可以包括有文本头header和文本体body，分别记录客户端或应用程序发生的一个事件。

在生成二进制数据体时，可以首先确定各个事件的事件类型、发生时间，以及，事件记录数据的大小，并分别将上述各个事件的事件类型、发生时间，以及，事件记录数据的大小写入二进制数据体的文本头。然后，按照文本头的顺序，将各个事件的事件记录数据写入二进制数据体的文本体，从而得到二进制数据体。

如图2所示，本申请的一种二进制数据体的示意图。在图2中，可以使用2字节记录事件类型(recordtype)，使用4字节记录事件发生时间(time)，使用4字节记录数据体大小(bodysize)，然后，记录符合相应数据体大小的文本体body。

在本申请实施例中，事件数据体还可以包括有二进制数据头，该二进制数据头可以具有固定的字节长度，用于记录对应的事件数据体的各类属性信息。

在具体实现中，在生成二进制数据头时，可以首先确定事件数据体的属性信息，上述属性信息可以包括协议魔数magicnumber、协议版本、数据体生成时间，以及，时间偏差值等信息。然后，可以将上述协议魔数magicnumber、协议版本、数据体生成时间，和/或，时间偏差值等信息写入二进制数据头。

例如，可以使用4字节记录协议魔数magicnumber，使用2字节记录二进制头的长度，使用8字节记录日志记录的开始时间，然后将剩余字节记为0。

当然，写入二进制数据头的信息还可以包括其他信息，例如，文件是否溢出等等，本实施例对此不作限定。

步骤104，将所述文本描述段和事件数据体编码为日志文件。

在本申请实施例中，在获取客户端的事件数据，并据此得到要生成的日志文件的文本描述段和事件数据体后，可以将该文件描述段和事件数据体编码为日志文件，以便对上述日志文件进行存储。

如图3所示，是本申请的一种日志文件的编码结构图。在图3中，包括文本描述段textheader、二进制数据头binaryheader，以及二进制数据体。其中，文本描述段textheader包括有数据自描述信息type-descriptors等信息，二进制数据头binaryheader又进一步包括协议魔数magicnumber、二进制头的长度headerlength，日志记录的开始时间recordstarttime等信息。而对于二进制数据体，其各部分与图2中所示的二进制数据类似。

数据自描述信息type-descriptors记录有服务端应当按照何种规则或格式解读该数据。

通常，在客户端与服务端的交互过程中，服务端按照约定的格式对客户端上报的数据进行解析。但是，数据的内容、格式经常会发生变化，例如，当客户端发生版本迭代，服务端就不能很好地兼容不同版本或格式的数据，从而需要重新对上述约定进行修订，推高了二者之间的通信成本，开发人员维护起来也比较麻烦。本实施例为了减轻维护负担，通过在日志文件的编码过程中，将数据自描述信息写入文本描述段，使得数据本身就带有对数据体的解释信息，这样在进行数据解析的过程中就无需依赖数据之外的其他信息，极大的保证了数据的可扩展性和灵活性。

在本申请实施例中，通过获取客户端的事件数据，并依据该事件数据中的客户端描述信息和事件描述信息生成文本描述段，依据事件记录数据生成事件数据体，从而可以将文本描述段和事件数据体编码为日志文件。本实施例通过提供一种日志文件的编码协议，从而可以按照该编码协议统一地对客户端的各类数据进行编码，在压缩比上，本实施例的编码协议比现在广泛使用的json数据协议提高了5倍以上，解决了现有技术中客户端的数据膨胀对设备或客户端造成的影响。同时，本实施例通过将事件数据中类型、数据结构及编码信息通过流式数据体的描述信息写入数据文件，对于任何平台的数据都可以通过流式数据体中每个记录类型代表的含义和格式进行数据解析，由于数据文件本身就带有对数据体的解释信息，这样在进行数据解析的过程中就无需依赖数据之外的其他信息，极大的保证了数据的可扩展性和灵活性，方便了编码后的日志文件在多个不同的平台中进行使用，提高了数据的跨平台兼容性，极大地减轻了数据频繁变化、扩展给数据解析带来的复杂性。

参照图4，示出了本申请的一种日志文件的存储方法实施例的步骤流程图，具体可以包括如下步骤：

步骤401，获取客户端的事件数据；

需要说明的是，客户端可以是指安装在手机、平板电脑等各类终端设备上的应用程序。例如，安装在手机上的手机淘宝app、支付宝app等等。本实施例对终端设备及客户端的类型不作限定。

在本申请实施例中，事件数据可以包括客户端描述信息、事件描述信息，以及，事件记录数据等等。

其中，客户端描述信息可以包括客户端信息(即客户端或应用程序本身的信息)、设备信息(即安装该客户端或应用程序的终端设备的信息)，以及，环境信息(即用户在使用该客户端或应用程序时的网络状态等信息)。

在具体实现中，客户端信息可以包括如下各种信息中的至少一种：

协议版本号、应用版本号、设备标识信息。

设备信息可以包括如下各种信息中的至少一种：

设备硬件类型、cpu核数、cpu主频、显示器参数、操作系统版本、设备支持的传感器类型。

环境信息可以包括如下各种信息中的至少一种：

设备网络状态、运营商信息。

当然，以上仅为一种示例，根据实际需要的不同，上述各类信息还可以包括其他不同的信息或数据，本实施例对此不作限定。

在本申请实施例中，事件描述信息可以包括各个事件对应的事件记录数据的事件信息和格式信息。

各个事件可以是客户端自身产生的事件，或者用户在使用该客户端时产生的事件。例如，系统事件、用户操作事件、应用程序执行事件、网络事件等等。

事件信息可以是在上述各类事件发生时所记录的该事件的相关信息或数据，格式信息则表示了在记录上述事件时所采用的记录格式或参数的信息。

在本申请实施例中，事件记录数据可以是完整地记录的发生上述各类事件时的信息或数据。

步骤402，将所述事件数据编码为日志文件；

在本申请实施例中，在将事件数据编码为日志文件时，可以首先依据客户端描述信息和事件描述信息生成文本描述段，依据事件记录数据生成事件数据体，然后将上述文本描述段和事件数据体编码为日志文件。

由于本实施例中步骤402与上述实施例中步骤102至步骤104类似，可以相互参阅，本实施例对此不再赘述。

步骤403，确定内存地址空间；

在本申请实施例中，内存地址空间可以是指用户存储生成的日志文件的地址空间，该内存地址空间可以固定的大小。

在具体实现中，在确定内存地址空间后，还可以采用预设方法对该内存地址空间进行初始化。例如，可以采用mmap方法。

mmap是一种内存映射文件的方法，即将一个文件或者其他对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对应关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read、write等系统调用函数。相反，内存空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

步骤404，存储所述日志文件至所述内存地址空间。

在本申请实施例中，在将日志文件存储至内存地址空间时，可以首先确定该内存地址空间是否溢出，若是，则可以获取该内存地址空间中的数据，并将上述数据写入磁盘；若否，则可以执行存储日志文件至该内存地址空间的步骤。

在具体实现中，使用mmap映射的内存地址空间大小有限，当对应空间已使用的大小超过阈值之后，子线程可以将映射的内存地址空间内存储的数据拷贝写入磁盘文件。

如图5所示，是本申请的一种日志文件的存储方法的设计框图。在图5中，对于需要存储的客户端的事件数据(如系统事件、用户操作事件、应用程序执行事件、网络事件等等)，可以首先对客户端进行初始化，然后采用mmap方法初始化确定的内存地址空间，并在生成日志文件的文本描述段和事件数据体后，通过检查内存地址空间是否溢出，从而实现对日志文件的存储。如果内存地址空间溢出，则可以通过子线程，将该内存地址空间内的数据写入磁盘，然后将指针移回初始值。如果内存地址空间未溢出，则表示该地址还可以存储日志文件，则可以将日志文件写入该内存地址空间。

在本申请实施例中，通过获取客户端的事件数据，可以将该事件数据编码为日志文件，然后在确定内存地址空间后，可以存储上述日志文件至该内存地址空间。本实施例可以使用mmap方法将日志文件映射到固定大小的内存地址空间，通过操作内存并由系统内核将数据同步到日志文件，可以避免直接操作文件带来的性能损耗；同时在发生客户端或应用程序崩溃等极端情时，即使用户进程被杀死，子进程仍会将mmap地址空间中的数据写入文件，从而最大程度保证了日志文件的数据完整性。

参照图6，示出了本申请的一种日志文件的解析方法实施例的步骤流程图，具体可以包括如下步骤：

步骤601，获取日志文件，所述日志文件包括文本描述段和事件数据体；

需要说明的是，本实施例中的日志文件可以是指按照上述日志文件的编码方法或日志文件的存储方法中所示的编码协议进行编码或存储得到的日志文件，每份日志文件可以包括有文本描述段和事件数据体。

步骤602，读取所述文本描述段中的事件描述信息；

在本申请实施例中，事件描述信息可以包括各个事件对应的事件记录数据的事件信息和格式信息。

各个事件可以是客户端自身产生的事件，或者用户在使用该客户端时产生的时间。例如，系统事件、用户操作事件、应用程序执行事件、网络事件等等。

事件信息可以是在上述各类事件发生时所记录的该事件的相关信息或数据，格式信息则表示了在记录上述事件时所采用的记录格式或参数的信息。

例如，对于打开页面(openpage)事件，相应的事件描述信息可以表示为：

openpage:u4:u1*,freememory:f,residentmemory:f,virtualmemory:f,cpuusageofapp:f,cpuusageofdevice:f

步骤603，根据所述事件描述信息对所述事件数据体进行解析。

在本申请实施例中，在读取到文本描述段中的事件描述信息后，可以首先确定读取的事件描述信息对应的事件数据体，然后再对事件数据体进行解析。

在具体实现中，由于事件数据体包括二进制数据头和二进制数据体。因此，在解析时，可以首先读取二进制数据头，获得该事件数据体的协议魔数magicnumber、协议版本、数据体生成时间，以及，时间偏差值等属性信息。然后，再对二进制数据体进行解析。

如图7所示，是本申请的一种日志文件的解析方法的示意图，可以首先读取10个字节，其中1-2字节解析为short事件类型(图7中openpage)，并根据事件类型从文本描述段中查找对应的事件描述信息，以确定用哪种数据格式解析当前事件；3-6字节解析为整型，作为事件发生的时间；7-10字节解析为整型，记录为事件body长度。

然后，根据事件描述信息解析事件body。以openpage事件为例：读取4字节解析为无符号整型，并继续读取该整型值对应的长度字节解析为字符串，记录为page；读取4字节解析为float型，记录为freememory；读取4字节解析为float型，记录为virtualmemory，直到解析完图7中所示的全部的其他字段。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图8，示出了本申请的一种日志文件的编码装置实施例的结构框图，具体可以包括如下模块：

事件数据获取模块801，用于获取客户端的事件数据，所述事件数据包括客户端描述信息、事件描述信息，以及，事件记录数据；

文本描述段生成模块802，用于依据所述客户端描述信息和事件描述信息生成文本描述段；

事件数据体生成模块803，用于依据所述事件记录数据生成事件数据体；

日志文件编码模块804，用于将所述文本描述段和事件数据体编码为日志文件。

在本申请实施例中，所述客户端描述信息可以包括客户端信息、设备信息，以及，环境信息；

所述事件描述信息可以包括各个事件对应的事件记录数据的事件信息和格式信息。

在本申请实施例中，所述客户端信息可以包括如下的至少一种：

协议版本号、应用版本号、设备标识信息；

所述设备信息可以包括如下的至少一种：

设备硬件类型、cpu核数、cpu主频、显示器参数、操作系统版本、设备支持的传感器类型；

所述环境信息可以包括如下的至少一种：

设备网络状态、运营商信息。

在本申请实施例中，所述事件数据体可以为二进制数据体，所述事件数据体生成模块803具体可以包括如下子模块：

确定子模块，用于确定各个事件的事件类型、发生时间，以及，事件记录数据的大小；

文本头写入子模块，用于分别将所述各个事件的事件类型、发生时间，以及，事件记录数据的大小写入二进制数据体的文本头；

文本体写入子模块，用于按照所述文本头的顺序，将所述各个事件的事件记录数据写入二进制数据体的文本体。

在本申请实施例中，所述事件数据体还可以包括二进制数据头，所述事件数据体生成模块803还可以包括如下子模块：

属性信息确定子模块，用于确定所述事件数据体的属性信息，所述属性信息可以包括协议魔数、协议版本、数据体生成时间，以及，时间偏差值；

二进制数据头写入子模块，用于将所述协议魔数、协议版本、数据体生成时间，和/或，时间偏差值写入二进制数据头，所述二进制数据头具有固定的字节长度。

参照图9，示出了本申请的一种日志文件的存储装置实施例的结构框图，具体可以包括如下模块：

事件数据获取模块901，用于获取客户端的事件数据；

日志文件编码模块902，用于将所述事件数据编码为日志文件；

内存地址空间确定模块903，用于确定内存地址空间；

日志文件存储模块904，用于存储所述日志文件至所述内存地址空间。

在本申请实施例中，所述事件数据可以包括客户端描述信息、事件描述信息，以及，事件记录数据；所述日志文件编码模块902具体可以包括如下子模块：

文本描述段生成子模块，用于依据所述客户端描述信息和事件描述信息生成文本描述段；

事件数据体生成子模块，用于依据所述事件记录数据生成事件数据体；

日志文件编码子模块，用于将所述文本描述段和事件数据体编码为日志文件。

在本申请实施例中，所述装置还可以包括如下模块：

初始化模块，用于采用预设方法对所述内存地址空间进行初始化，所述预设方法可以包括mmap方法。

在本申请实施例中，所述日志文件存储模块904具体可以包括如下子模块：

确定子模块，用于确定所述内存地址空间是否溢出；

写入子模块，用于在所述内存地址空间溢出时，获取所述内存地址空间中的数据，将所述数据写入磁盘；

存储子模块，用于在所述内存地址空间未溢出时，调用所述日志文件存储模块904。

参照图10，示出了本申请的一种日志文件的解析装置实施例的结构框图，具体可以包括如下模块：

日志文件获取模块1001，用于获取日志文件，所述日志文件可以包括文本描述段和事件数据体；

事件描述信息读取模块1002，用于读取所述文本描述段中的事件描述信息；

事件数据体解析模块1003，用于根据所述事件描述信息对所述事件数据体进行解析。

在本申请实施例中，所述事件数据体解析模块1003具体可以包括如下子模块：

确定子模块，用于确定所述事件描述信息对应的事件数据体，所述事件数据体可以为二进制数据体；

解析子模块，用于对所述二进制事件数据体进行解析。

在本申请实施例中，所述事件数据体还可以包括二进制数据头，所述事件数据体解析模块1003还可以包括如下子模块：

读取子模块，用于读取所述二进制数据头，获取所述事件数据体的属性信息，所述属性信息可以包括协议魔数、协议版本、数据体生成时间，以及，时间偏差值。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种日志文件的编码方法、一种日志文件的编码装置、一种日志文件的存储方法、一种日志文件的存储装置、一种日志文件的解析方法和一种日志文件的解析装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。