?? fileformat.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head><title>No Title</title><style type="text/css">body { margin: auto; font-family: "Verdana" "sans-serif"; padding: 8px 1%;}a { color: #45735f }a:visited { color: #734559 }.logo { position:absolute; margin:3px; }.tagline { float:right; text-align:right; font-style:italic; width:240px; margin:12px; margin-top:58px;}.toolbar { font-variant: small-caps; text-align: center; line-height: 1.6em; margin: 0; padding:1px 8px;}.toolbar a { color: white; text-decoration: none; padding: 6px 12px; }.toolbar a:visited { color: white; }.toolbar a:hover { color: #80a796; background: white; }.content { margin: 5%; }.content dt { font-weight:bold; }.content dd { margin-bottom: 25px; margin-left:20%; }.content ul { padding:0px; padding-left: 15px; margin:0px; }/* rounded corners */.se { background: url(images/se.png) 100% 100% no-repeat #80a796}.sw { background: url(images/sw.png) 0% 100% no-repeat }.ne { background: url(images/ne.png) 100% 0% no-repeat }.nw { background: url(images/nw.png) 0% 0% no-repeat }</style><meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head><body><div><!-- container div to satisfy validator --><a href="index.html"><img class="logo" src="images/SQLite.gif" alt="SQLite Logo" border="0"></a><div><!-- IE hack to prevent disappearing logo--></div><div class="tagline">Small. Fast. Reliable.<br>Choose any three.</div><table width=100% style="clear:both"><tr><td> <div class="se"><div class="sw"><div class="ne"><div class="nw"> <div class="toolbar"> <a href="about.html">About</a> <a href="sitemap.html">Sitemap</a> <a href="docs.html">Documentation</a> <a href="download.html">Download</a> <a href="copyright.html">License</a> <a href="news.html">News</a> <a href="http://www.sqlite.org/cvstrac/index">Developers</a> <a href="support.html">Support</a> </div></div></div></div></div></td></tr></table> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><html><head> <link type="text/css" rel="stylesheet" href="images/fileformat/rtdocs.css"> <script type="text/javascript" src=images/fileformat/rtdocs.js></script></head><body><div id=document_title>SQLite Database File Format</div><div id=toc_header>Table Of Contents</div><div id=toc> <b>Javascript is required for some features of this document, including table of contents, figure numbering and internal references (section numbers and hyper-links. </b></div><!-- End of standard rt docs header --><h1>Document Overview</h1> <h2>Scope and Purpose</h2> <p> This document is designed to serve two purposes: <ul> <li>to provide an engineering guide to the file format used by SQLite, and <li>to provide system requirements specifying the behaviour of the SQLite software modules responsible for creating and manipulating the formatted database files. </ul> <p> Exactly how the database file is created and safely updated on the persistent media is outside the scope of this document. As such no mention of journal or statement files is made. Database transactions are referred to only with respect to those file manipulation operations (i.e. change-counter management and database reorganization in auto-vacuum mode) that occur once per transaction. Here we are concerned solely with the arrangement of bytes in the database file, not the interactions between the SQLite library and the VFS (Virtual File System) interface. <p> Similarly, the various interfaces and SQL language features that may be used to manipulate the contents of a database are not dealt with here. This document describes the effect of various operations on the database, such as creating a table or inserting a new record. The myriad of ways that these operations or sets of these operations may be achieved using SQLite are dealt with elsewhere. <p class=todo> Add references to the documents that do describe these things. One other document will concentrate on the pager module and the way it uses the VFS interface to safely create and update database files. The other will be the document that describes the supported SQL language and capabilities. <h2>Document and Requirements Organization</h2> <p> Section <cite>sqlite_database_files</cite> contains simple requirements describing the relationship between SQLite and the definition of a <i>well-formed SQLite database file</i>. <p> Section <cite>database_file_format</cite> describes the various fields and sub-structures that make up the SQLite database file format.<!-- <p> Section <cite>database_file_manipulation</cite> describes the way in which these fields and data structures are created, initialized and updated. --> <h2>Glossary</h2> <table id=glossary> <tr><td>Auto-vacuum last root-page<td> A page number stored as 32-bit integer at byte offset 52 of the database file header (see section <cite>file_header</cite>). In an auto-vacuum database, this is the numerically largest <i>root-page</i> number in the database. Additionally, all pages that occur before this page in the database are either B-Tree <i>root pages</i>, <i>pointer-map pages</i> or the <i>locking page</i>. <tr><td>Auto-vacuum database <td> Each database is either an auto-vacuum database or a non auto-vacuum database. Auto-vacuum databases feature pointer-map pages (section <cite>pointer_map_pages</cite>) and have a non-zero value stored as a 4-byte big-endian integer at offset 52 of the file header (section <cite>file_header</cite>). <tr><td>B-Tree <td> A B-Tree is a tree structure optimized for offline storage. The table and index data in an SQLite database file is stored in B-Tree structures. <tr><td>B-Tree cell <td> Each database page that is part of a B-Tree structure contains zero or more B-Tree cells. A B-Tree cell contains a single B-Tree key value (either an integer or database record) and optionally an associated database record value. <tr><td>B-Tree page <td> A database page that is part of a B-Tree tree structure (not an overflow page). <tr><td>(B-Tree) page header <td> The 8 (leaf pages) or 12 (internal node pages) byte header that occurs at the start of each B-Tree page. <tr><td>Cell content area <td> The area within a B-Tree page in which the B-Tree cells are stored. <tr><td>(Database) text encoding <td> The text encoding used for all text values in the database file. One of UTF-8, big-endian UTF-16 and little-endian UTF-16. The database text encoding is defined by a 4 byte field stored at byte offset 56 of the database file header (see section <cite>file_header</cite>). <tr><td>(Database) file header <td> The first 100 bytes of an SQLite database file constitute the database file header. <tr><td>(Database) page size <td> An SQLite database file is divided into one or more pages of page-size bytes each. <tr><td>Database record <td> A database record is a blob of data containing the serialized representation of an ordered list of one or more SQL values. <tr><td>Database record header <td> The first part of each database record contains the database record header. It encodes the types and lengths of values stored in the record (see section <cite>record_format</cite>). <tr><td>Database record data area <td> Following the database record header in each database record is the database record data area. It contains the actual data (string content, numeric value etc.) of all values in the record (see section <cite>record_format</cite>). <tr><td>Default pager cache size <td> A 32-bit integer field stored at byte offset 48 of the database file header (see section <cite>file_header</cite>). <tr><td style="white-space:nowrap">(Database) usable page size <td> The number of bytes of each database page that is usable. This is the page-size less the number of bytes left unused at the end of each page. The number of bytes left unused is governed by the value stored at offset 20 of the file header (see section <cite>file_header</cite>). <tr><td>File format read version <td> Single byte field stored at byte offset 20 of the database file header (see section <cite>file_header</cite>). <tr><td>File format write version <td> Single byte field stored at byte offset 19 of the database file header (see section <cite>file_header</cite>). <tr><td>File change counter <td> A 32-bit integer field stored at byte offset 24 of the database file header (see section <cite>file_header</cite>). Normally, SQLite increments this value each time it commits a transaction. <tr><td>Fragment <td> A block of 3 or less bytes of unused space within the cell content area of a B-Tree page. <tr><td>Free block <td> A block of 4 or more bytes of unused space within the cell content area of a B-Tree page. <tr><td>Free block list <td> The linked list of all free blocks on a single B-Tree page (see section <cite>index_btree_page_format</cite>). <tr><td>Free page <td> A page that is not currently being used to store any database data or meta data. Part of the free-page list. <tr><td>Free page list <td> A data structure within an SQLite database file that links all the free-pages together. <tr><td>Index B-Tree <td> One of two variants on the B-Tree data structure used within SQLite database files. An index B-Tree (section <cite>index_btrees</cite>) uses database records as keys. <tr><td>Incremental Vacuum flag <td> A 32-bit integer field stored at byte offset 64 of the database file header (see section <cite>file_header</cite>). In auto-vacuum databases, if this field is non-zero then the database is not automatically compacted at the end of each transaction. <tr><td>Locking page <td> The database page that begins at the 1GB (2<sup>30</sup> byte) boundary. This page is always left unused. <tr><td>Logical database <td> An SQLite database file is a serialized representation of a logical database. A logical database consists of the SQL database schema, the content of the various tables in the database, and assorted database properties that may be set by the user (auto-vacuum,?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -