SQLite Literal Insert Data Extractor

How to use SQLite Literal Insert Data Extractor

Recover reviewable table data from explicit-column literal INSERT statements while retaining the distinction between NULL, empty text, numbers and blob bytes. Repeated target statements may reorder the same column set, and every exported cell retains its original SQL spelling and source offsets. This is an atomic source-data extractor: it never opens a database, evaluates an expression or pretends that stored SQLite values have been recalculated.

1. Paste source containing only supported INSERT INTO table (explicit columns) VALUES literal rows; remove unsupported statements yourself rather than asking the tool to skip them.
2. Choose typed JSON or a CSV ZIP bundle and run the complete parse.
3. Review original numeric spellings, literal types, source offsets and table mappings. Prefer the JSON manifest whenever NULL/empty text or exact type distinctions matter.

Good to know

• At most 200,000 UTF-16 source characters, 10 target tables, 200 statements, 1,000 rows, 100 columns per table and 20,000 cells. Literal spellings/decoded text are capped at 10,000 characters; identifier names at 100. Well-formed Unicode is required and literal NUL is refused. One initial BOM is ignored; offsets still refer to the original source.
• Only explicit INSERT INTO table (column, ...) VALUES (literal, ...), (...) is supported. Statements may end at EOF or use semicolons. ASCII spaces, tabs, CR/LF and form feed, -- comments and closed /* comments */ are accepted between tokens. Any unsupported syntax rejects the whole operation, including earlier valid statements.
• Identifiers are double-quoted with doubled quote escaping, or bare ASCII letters/underscore followed by ASCII letters, digits, underscore or dollar sign. All 147 published SQLite keywords require quoting in this conservative profile. Schema qualifiers, backticks, bracket names, single-quoted identifiers and embedded control characters are refused. Target and column identities use ASCII-only case comparison; repeated tables must declare exactly the same column set.
• Literals are single-quoted text with doubled apostrophes, contiguous signed decimal/exponent spellings, NULL and even-length hexadecimal X blobs. Backslashes in strings stay literal. No hex integers, numeric underscores, parameters, expressions, functions, booleans, CURRENT values, OR clauses, SELECT, DEFAULT, CREATE/transactions, upserts or RETURNING. This is a selected source grammar, not full SQLite or SQL-dump compatibility.
• Numbers remain source spelling strings without JavaScript numeric conversion. No SQLite schema, affinity, defaults, constraints, triggers, expression evaluation or stored-value prediction is attempted; even an overflowing numeric spelling remains evidence, not a computed numeric value. JSON keeps NULL/text/blob/number distinctions and original UTF-16 end-exclusive offsets.
• CSV values use empty fields for NULL and empty text, so CSV alone loses that distinction. Blob cells use lowercase hex; number cells retain their spelling. Formula-like headers/cells are prefixed with an apostrophe for spreadsheet exposure reduction; the typed JSON manifest remains authoritative. ZIP names are generated table-NNN.csv, never table-derived paths. Readable JSON is capped at 1,000,000 characters and archive text at 2,000,000 UTF-8 bytes.
• Processing is local. Output is limited to 1,000,000 text characters unless a stricter file limit is stated.