SQLiteの.dbファイルを開いて中身を見る方法｜ブラウザでTableを確認

結論：File形式とToolの対応範囲を確定してから開く

元FileのCopyを1件読み込み、SQLite 3 Header、Table数、View数、Schema、Rowsを確認します。対応対象は標準SQLite 3であり、あらゆる`.db`やServer型DBを開くToolではありません。

WAL Sidecar、SQLCipher、破損修復には未対応です。Main DB単独で得られる内容だけを表示します。

最小例で確認する

example.db
SQLite format 3\0
  ├─ users
  ├─ orders
  └─ user_summary (view)

Header一致後にTable・View一覧を読み、対象Objectを選んでSchemaとRowsへ進みます。

SQLite DBを開く最短手順

• 調査用Copyを用意する
• Fileを選択またはDropする
• 読込成功とTable・View数を確認する
• Schema Tabで列定義を見る
• Data Tabで検索・Sort・Pagingする

拡張子ではなくSQLite 3のFile Headerを確認する

Offset 0, 16 bytes
SQLite format 3\0

Hex
53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00

`.db`は汎用拡張子です。現行ViewerはFile名ではなく先頭16bytesを確認し、標準SQLite 3 Headerと一致したFileだけをsql.jsへ渡します。0byte File、Textを`.db`へRenameしたFile、暗号化されHeaderが平文でないFileは標準SQLiteとして開きません。

Table・Schema・Rowsを順番に確認する

• File読込後にFile名・File Size・Table数・View数を確認します。
• 左側でTableまたはViewを選び、まずSchema Tabで列名、Declared Type、NOT NULL、Default、Primary Key、CREATE SQLを確認します。
• Data Tabで全列検索、列Header Sort、25～200行のPagingを使い、必要なRowだけを表示します。
• Index・Foreign Keyを調べる場合は、Read-only SQL欄でPRAGMA index_list(table)、PRAGMA index_info(index)、PRAGMA foreign_key_list(table)を個別に実行します。
• Index・Trigger・Viewをまとめて調べる場合はsqlite_schemaをSELECTします。専用のObject Treeがあるとは案内しません。

SELECT type, name, tbl_name, sql
FROM sqlite_schema
WHERE type IN ('table', 'index', 'view', 'trigger')
ORDER BY type, name;

Table名・列名・値は画面へTextとして描画します。`<script>`をDatabase Valueとして含めてもHTMLとして実行しません。

WAL ModeのMain DB・-wal・-shmを分けて考える

WAL Modeでは未Checkpointの変更が`app.db-wal`へ残る場合があります。`-wal`は古いBackupではなくDatabase Stateの一部になり得ます。`-shm`はWAL Index用のShared-memory Fileです。稼働中ApplicationからMain DBだけをCopyすると、最新Rowが見えない、またはConsistentでないSnapshotになる可能性があります。

app.db       Main database
app.db-wal   Write-ahead log
app.db-shm   Shared-memory / WAL index

• 現行ViewerはMain DBを1件だけ読み込み、-wal・-shmを適用しません。
• 不足RowをViewerが復元したり、-walをMain DBへMergeしたりはしません。
• 取得元Applicationを安全に停止するか、SQLiteのBackup機構で一貫したCopyを作成します。
• -walを単独で削除する手順は案内しません。元Fileを保全して作成元の運用を確認します。

Declared Type・Storage Class・BLOBを混同しない

Schema Tabの「型」はDeclared Typeです。現行ViewerはValueごとの`typeof(value)`やAffinityを表示しないため、Actual Storage Classが必要ならRead-only SQLで`typeof(column)`を明示します。空文字、NULL、0byte BLOBは同じ「空」ではありません。Boolean専用・Date専用のStorage Classもなく、0/1、TEXT、Unix Timestamp、Julian Day等の意味はSchemaとApplication仕様で判断します。

SELECT
  value,
  typeof(value) AS storage_class,
  length(value) AS value_length,
  quote(value) AS sql_literal
FROM sample
LIMIT 100;

BLOBを文字化けしたTEXTと断定しません。現行ViewerはByte Lengthだけを示し、画像判定・Hex Dump・Downloadは行いません。

現在のSQL DBファイル閲覧ツールで確認できること

画面にない機能を前提に原因を断定しません。WAL適用、暗号化解除、破損修復、BLOB Preview、Integrity Checkは現在のViewerでは行えません。

Read-only・Browser処理・Privacyの境界

File Binary、File名、Table・Column・Row、BLOB、検索語、SQL QueryはBrowser Memory内で処理し、Viewer本体にはfetch、sendBeacon、localStorageへの保存処理がありません。sql.jsのJavaScriptとWASMもSite内の同一Originから読み込みます。PageをReloadするとDB内容は復元されません。

DBを開いた直後に`PRAGMA query_only = ON`を設定し、UIでもSELECT・WITH・EXPLAINと限定PRAGMAだけを許可します。ただしBrowser、Extension、Site共通の広告・Analytics、組織Networkを含めて「通信が一切ない」と保証する表現は避けます。DBにはToken・Session・個人情報が含まれ得るため、組織Policyを優先します。

Viewerは元Fileを修復・更新・Exportしません。調査用Copyを使い、元Fileを保全してください。

大容量DBはFile読込・Query・DOM描画を分けて測る

sql.jsはDatabase FileをUint8ArrayとしてBrowser Memoryへ読み込み、WebAssembly内でも扱います。画面のPagingはSELECTにLIMIT/OFFSETを付けてDOM行数を抑えますが、File全体をStreamingで読む方式ではありません。File Size上限はUIで固定していなくても、Browser・端末Memory・WASMに実用上の限界があります。

• 元FileのCopyを1MB、10MBなど小さい段階から開き、Load TimeとMemoryを実測します。
• 最初にTable・Schemaだけを確認し、Dataは25～200行でPagingします。
• 全列検索は各列をTEXTへCASTしてLIKEするため、大きなTableではCostが高くなり得ます。
• 列SortとRead-only SQLはSQLite側で実行されます。Index・Query Plan・Data Typeを確認します。
• 数GBや数百万Rowを必ず快適に開けるとは案内しません。

開けない・壊れて見える場合の切り分け

現行UIでは`PRAGMA quick_check`と`PRAGMA integrity_check`を許可していません。破損疑いでは元Fileへ書き込まずCopyを作り、SQLite公式CLI等の管理された環境で検査します。修復結果は別Fileへ出し、元Fileを残します。

DevelopTools内で次の確認へ進む

• CSVへExport済みのTableをCSV・TSV Viewerで確認する
• CREATE TABLE・SELECTをSQL Formatterで整形する
• INTEGER日時をUnix Timestamp Converterで確認する
• DB FileがBinary一致するかHashで確認する
• Schema SQLをテキスト差分比較する

CSV Dataの閲覧、SQL Textの整形、Unix時刻変換、Binary一致、Schema Text差分は別目的です。SQLite DB自体の内容比較やBackup・Repairができるとは案内しません。

SQLite・sql.js・SQLCipherの一次資料を確認する

• SQLite: Database File Format
• SQLite: The Schema Table
• SQLite: Datatypes In SQLite
• SQLite: Date And Time Functions
• SQLite: Write-Ahead Logging
• SQLite: PRAGMA Statements
• SQLite: How To Corrupt An SQLite Database File
• sql.js: SQLite compiled to JavaScript
• Zetetic: About SQLCipher

Database Header、Schema Table、Storage Class、WAL、PRAGMAはSQLite公式、Browser Engineは実際に利用しているsql.js公式、暗号化DatabaseはSQLCipher提供元の説明を優先します。Community記事は検索意図や実務例の補助に留めます。

まとめ

• SQLite format 3 Headerを確認する
• Table・Schema・Rowsの順に見る
• 元Fileを変更せずBrowser Memoryで読み取り専用に扱う

File Header、Schema、Rows、Sidecar、Storage Classを順番に確認し、標準SQLiteの閲覧、暗号化、破損、Backup・Repairを別作業として扱うと、推測によるFile操作を避けられます。

具体例：SQLiteの.dbファイルを開いて中身を見る方法を確認する

元Fileを上書きせず調査用Copyを作り、「example.db / SQLite format 3\0 / ├─ users / ├─ orders / └─ user_summary (view)」の状態を確認します。

Header一致後にTable・View一覧を読み、対象Objectを選んでSchemaとRowsへ進みます。 Viewerの結果と作成元Application、SQLite公式仕様を照合して原因を確定します。

1. 作成元、File名、File Size、取得日時、同名の-wal・-shmの有無を記録します。
2. 元Fileを保全し、標準SQLite 3のMain DB Copyを1件読み込みます。
3. Table・View数、Schema、CREATE SQL、NULL・BLOBを先に確認します。
4. Dataは少ないPage Sizeから開き、検索・Sort・Read-only SQLを必要な範囲で使います。
5. 暗号化・破損・WAL・大容量の問題はViewerの未対応範囲と分けて次の作業を決めます。

Viewerの表示結果だけでRepairや削除を行いません。元FileとSidecarを保全し、変更作業は別Copyと管理されたSQLite環境で実施してください。

よくある質問

.dbファイルならすべて開けますか？

開けません。現行Viewerは先頭にSQLite format 3 Headerを持つ標準SQLite 3だけを対象にします。SQLCipher、Access、DuckDB、MySQL・PostgreSQL Data File、独自Formatには対応しません。

-wal・-shmも一緒に読み込めますか？

読み込めません。Main DBを1件だけ扱います。WAL ModeのDatabaseは作成元を安全に停止するかSQLiteのBackup機構で一貫したSnapshotを用意してください。

DBを修復したりBLOBを画像として保存できますか？

できません。quick_check・integrity_check、自動Repair、BLOB Preview・Hex・Downloadは未対応です。BLOBはByte Lengthだけを表示します。