fileformat.html

sqlite3源码,适合作为嵌入式（embedded）

          <cite>record_format</cite>) is stored along with each entry. Table
          B-Tree structures are described in detail in section 
          <cite>table_btrees</cite>.
      <li>The <b>index B-Tree</b>, which uses database records as keys. Index
          B-Tree structures are described in detail in section 
          <cite>index_btrees</cite>.
    </ul>

    <p class=req id=H30500>
          As well as the <i>schema table</i>, a <i>well-formed database file</i>
contains <i>N</i> table B-Tree structures, where <i>N</i> is the
number of non-virtual tables in the logical database, excluding the
sqlite_master table but including sqlite_sequence and other system
tables.
    <p class=req id=H30510>
          A well-formed database file contains <i>N</i> table B-Tree structures,
where <i>N</i> is the number of indexes in the logical database,
including indexes created by UNIQUE or PRIMARY KEY clauses in the
declaration of SQL tables.

    <h3 id="varint_format">Variable Length Integer Format</h3>
      <p>
	In several parts of the B-Tree structure, 64-bit twos-complement signed
	integer values are stored in the "variable length integer format"
	described here.
      <p>
        A variable length integer consumes from one to nine bytes of space,
        depending on the value stored. Seven bits are used from each of
        the first eight bytes present, and, if present, all eight from
	the final ninth byte. Unless the full nine byte format is used, the
	serialized form consists of all bytes up to and including the first
	byte with the 0x80 bit cleared.
      <p>
	The number of bytes present depends on the position of the most
	significant set bit in the 64-bit word. Negative numbers always have
	the most significant bit of the word (the sign bit) set and so are
	always encoded using the full nine bytes. Positive integers may be
	encoded using less space. The following table shows the 9 different
	length formats available for storing a variable length integer
	value.

      <table class=striped>
        <tr><th>Bytes<th>Value Range<th>Bit Pattern
        <tr><td>1<td>7 bit<td>0xxxxxxx
        <tr><td>2<td>14 bit<td>1xxxxxxx 0xxxxxxx
        <tr><td>3<td>21 bit<td>1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>4<td>28 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>5<td>35 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>6<td>42 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>7<td>49 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>8<td>56 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 0xxxxxxx
        <tr><td>9<td>64 bit<td>1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx 1xxxxxxx xxxxxxxx
      </table>
      <p>
        When using the full 9 byte representation, the first byte contains
        the 7 most significant bits of the 64-bit value. The final byte of
        the 9 byte representation contains the 8 least significant bits of
        the 64-bit value. When using one of the other representations, the
        final byte contains the 7 least significant bits of the 64-bit value.
        The second last byte, if present, contains the 7 next least signficant
	bits of the value, and so on. The significant bits of the 64-bit
	value for which no storage is provided are assumed to be zero.
      <p>
	When encoding a variable length integer, SQLite usually selects the
        most compact representation that provides enough storage to accomadate
	the most significant set bit of the value. This is not required
        however, using more bytes than is strictly necessary when encoding
        an integer is valid.

      <table class=striped>
	<tr><th>Decimal<th>Hexadecimal        <th>Variable Length Integer
	<tr><td>43     <td>0x000000000000002B <td>0x2B
	<tr><td>200815 <td>0x000000000003106F <td>0x8C 0xA0 0x6F
        <tr><td>-1     <td>0xFFFFFFFFFFFFFFFF 
            <td>0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
        <tr><td>-78056 <td>0xFFFFFFFFFFFECD56
            <td>0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFD 0xCD 0x56
      </table>

    <p class=req id=H30520>
          A 64-bit signed integer value stored in <i>variable length integer</i>
format consumes from 1 to 9 bytes of space.

    <p class=req id=H30530>
          The most significant bit of all bytes except the last in a serialized
<i>variable length integer</i> is always set. Unless the serialized
form consumes the maximum 9 bytes available, then the most significant
bit of the final byte of the representation is always cleared.

    <p class=req id=H30540>
          The eight least significant bytes of the 64-bit twos-compliment
representation of a value stored in a 9 byte <i>variable length
integer</i> are stored in the final byte (byte offset 8) of the
serialized <i>variable length integer</i>. The other 56 bits are
stored in the 7 least significant bits of each of the first 8 bytes
of the serialized <i>variable length integer</i>, in order from
most significant to least significant.

    <p class=req id=H30550>
          A <i>variable length integer</i> that consumes less than 9 bytes of
space contains a value represented as an <i>N</i>-bit unsigned
integer, where <i>N</i> is equal to the number of bytes consumed by
the serial representation (between 1 and 8) multiplied by 7. The
<i>N</i> bits are stored in the 7 least significant bits of each
byte of the serial representation, from most to least significant.
      

    <h3 id="record_format">Database Record Format</h3>
      <p>
        A database record is a blob of data that represents an ordered
        list of one or more SQL values. Database records are used in two
        places in SQLite database files - as the associated data for entries
        in table B-Tree structures, and as the key values in index B-Tree
        structures. The size (number of bytes consumed by) a database record
        depends on the values it contains.
      <p>
        Each database record consists of a short record header followed by 
        a data area. The record header consists of <i>N+1</i> variable
        length integers (see section <cite>varint_format</cite>), where
        <i>N</i> is the number of values stored in the record.
      <p>
        The first variable length integer in a record header contains the
        size of the record header in bytes. The following <i>N</i> variable
        length integer values each describe the type and size of the 
        records corresponding SQL value (the second integer in the record
        header describes the first value in the record, etc.). Integer
        values are interpreted according to the following table:
      <table class=striped>
        <tr><th>Header Value <th>Data type and size
        <tr><td>0 
            <td>An SQL NULL value (type SQLITE_NULL). This value
                consumes zero bytes of space in the record's data area.
        <tr><td>1
            <td>An SQL integer value (type SQLITE_INTEGER), stored as a
                big-endian 1-byte signed integer.
        <tr><td>2
            <td>An SQL integer value (type SQLITE_INTEGER), stored as a
                big-endian 2-byte signed integer.
        <tr><td>3
            <td>An SQL integer value (type SQLITE_INTEGER), stored as a
                big-endian 3-byte signed integer.
        <tr><td>4
            <td>An SQL integer value (type SQLITE_INTEGER), stored as a
                big-endian 4-byte signed integer.
        <tr><td>5
            <td>An SQL integer value (type SQLITE_INTEGER), stored as a
                big-endian 6-byte signed integer.
        <tr><td>6
            <td>An SQL integer value (type SQLITE_INTEGER), stored as an
                big-endian 8-byte signed integer.
        <tr><td>7
            <td>An SQL real value (type SQLITE_FLOAT), stored as an
                8-byte IEEE floating point value.
        <tr><td>8
            <td>The literal SQL integer 0 (type SQLITE_INTEGER). The value 
                consumes zero bytes of space in the record's data area.
                Values of this type are only present in databases with
                a schema file format (the 32-bit integer at byte offset 44
                of the database file header) value of 4 or greater.

        <tr><td>9
            <td>The literal SQL integer 1 (type SQLITE_INTEGER). The value
                consumes zero bytes of space in the record's data area.
                Values of this type are only present in databases with
                a schema file format (the 32-bit integer at byte offset 44
                of the database file header) value of 4 or greater.

        <tr><td style="white-space:nowrap"><i>bytes</i> * 2 + 12
            <td>Even values greater than 12 are used to signify a blob of
                data (type SQLITE_BLOB) (<i>n</i>-12)/2 bytes in length, where
                <i>n</i> is the integer value stored in the record header.
                
        <tr><td style="white-space:nowrap"><i>bytes</i> * 2 + 13
            <td>Odd values greater than 12 are used to signify a string
                (type SQLITE_TEXT) (<i>n</i>-13)/2 bytes in length, where
                <i>n</i> is the integer value stored in the record header.
      </table>
      <p>
        Immediately following the record header is the data for each
        of the record's values. A record containing <i>N</i> values is
        depicted in figure <cite>figure_recordformat</cite>.
      <center><img src="images/fileformat/recordformat.gif">
      <p><i>Figure <span class=fig id=figure_recordformat></span> - Database Record Format.</i>
      </center>
      
      <p>
        For each SQL value in the record, there is a blob of data stored
        in the records data area. If the corresponding integer type value
        in the record header is 0 (NULL), 8 (integer value 0) or 9 (integer
        value 1), then the blob of data is zero bytes in length. Otherwise,
        the length of the data field is as described in the table above.
      <p>
        The data field associated with a string value contains the string
        encoded using the database encoding, as defined in the database
        file header (see section <cite>file_header</cite>). No 
        nul-terminator character is stored in the database.

      <p class=req id=H30560>
          A <i>database record</i> consists of a <i>database record header</i>,
followed by <i>database record data</i>. The first part of the
<i>database record header</i> is a <i>variable length integer</i>
containing the total size (including itself) of the header in bytes.

      <p class=req id=H30570>
          Following the length field, the remainder of the <i>database record
header</i> is populated with <i>N</i> <i>variable length integer</i>
fields, where <i>N</i> is the number of database values stored in
the record.

      <p class=req id=H30580>
          Following the <i>database record header</i>, the <i>database record
data</i> is made up of <i>N</i> variable length blobs of data, where
<i>N</i> is again the number of database values stored in the record.
The <i>n</i> blob contains the data for the <i>n</i>th value in
the database record. The size and format of each blob of data is
encoded in the corresponding <i>variable length integer</i> field
in the <i>database record header</i>.

      <p class=req id=H30590>
          A value of 0 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL NULL. In this case
the blob of data in the data area is 0 bytes in size.

      <p class=req id=H30600>
          A value of 1 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 1-byte
big-endian signed integer.
      <p class=req id=H30610>
          A value of 2 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 2-byte
big-endian signed integer.
      <p class=req id=H30620>
          A value of 3 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 3-byte
big-endian signed integer.
      <p class=req id=H30630>
          A value of 4 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 4-byte
big-endian signed integer.
      <p class=req id=H30640>
          A value of 5 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 6-byte
big-endian signed integer.
      <p class=req id=H30650>
          A value of 6 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer. In this case
the blob of data contains the integer value, formatted as a 8-byte
big-endian signed integer.

      <p class=req id=H30660>
          A value of 7 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL real (floating
point number). In this case the blob of data contains an 8-byte
IEEE floating point number, stored in big-endian byte order.

      <p class=req id=H30670>
          A value of 8 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer, value 0.
In this case the blob of data in the data area is 0 bytes in size.

      <p class=req id=H30680>
          A value of 9 stored within the <i>database record header</i> indicates
that the corresponding database value is an SQL integer, value 1.
In this case the blob of data in the data area is 0 bytes in size.

      <p class=req id=H30690>
          An even value greater than or equal t