So zeigst du eine SQLite-Datenbankdatei auf dem Mac an

Du hast irgendwo auf deinem Mac eine .sqlite-, .db- oder .sqlite3-Datei gefunden, im Support-Ordner einer App, in einem Backup, in einem Projekt, das du debuggst, und du willst wissen, was tatsächlich darin steckt. Ein Doppelklick bewirkt nichts Brauchbares. Quick Look zeigt dir eine leere Vorschau oder Zeichensalat. Du brauchst einen echten SQLite-Datei-Betrachter, und es ist nicht offensichtlich, zu welchem Werkzeug du greifen sollst.

Warum du sie nicht einfach wie eine normale Datei öffnen kannst

SQLite-Datenbanken sind Binärdateien, kein Text. Die ersten 100 Bytes sind ein fester Header: ein Magic-String, der SQLite format 3 lautet, gefolgt von Feldern wie Seitengröße, Textkodierung und einem Schema-Cookie, das sich jedes Mal ändert, wenn die Tabellenstruktur geändert wird. Nach diesem Header kommen die eigentlichen Seitendaten, als B-Baum organisiert, weshalb ein Texteditor sie als Rauschen darstellt.

Finders Quick Look parst nichts davon. TextEdit interpretiert es als reinen Text und zeigt dir überwiegend unlesbare Zeichen mit ein paar erkennbaren Strings dazwischen (Tabellennamen, Spaltennamen und in den Tabellen gespeicherte Textdaten überleben tendenziell, weil SQLite Strings weitgehend unverändert speichert). Nichts davon sagt dir, ob die Datei tatsächlich gültig ist, mit welcher Seitengröße sie erstellt wurde oder warum eine andere App sich weigert, sie zu öffnen.

Deine Möglichkeiten, hineinzuschauen

Das Kommandozeilenwerkzeug sqlite3. macOS bringt sqlite3 im Terminal mit. Führe sqlite3 yourfile.db ".schema" aus und du bekommst die Tabellendefinitionen, oder .tables für eine schnelle Liste. Das funktioniert gut, wenn du bereits weißt, dass es eine gültige Datenbank ist, und sie abfragen willst. Es ist weniger nützlich, wenn du dir nicht sicher bist, ob die Datei überhaupt gültig ist, denn ein beschädigter Header erzeugt nur einen kryptischen Fehler ohne Detail darüber, was nicht stimmt.

DB Browser for SQLite. Das ist das richtige Werkzeug, wenn dein eigentliches Ziel ist, Tabellenzeilen zu durchsuchen, Daten zu bearbeiten oder SQL-Abfragen auszuführen. Es ist kostenlos, gut gepflegt und genau dafür gebaut. Wenn du die Daten in den Tabellen erkunden musst, hör hier auf zu lesen und hol dir DB Browser.

Ein Hex-Editor mit SQLite-Bewusstsein. Das ist die Option für eine andere Frage: nicht „was ist in den Tabellen", sondern „was ist diese Datei eigentlich". Das ist die Lücke, die Hexter füllt. Öffne die Datei und sie wird standardmäßig schreibgeschützt gelesen, sodass du die Datei nicht schon durch das bloße Anschauen gefährdest. Der Analysieren-Tab erkennt den SQLite-Header auf einen Blick und schlüsselt die Felder auf, Seitengröße, Kodierung, Schema-Cookie, neben dem rohen Hex, sodass du bestätigen kannst, dass die Datei wirklich SQLite ist, prüfen kannst, mit welcher Seitengröße sie erstellt wurde, oder einen Header entdecken kannst, der abgeschnitten oder überschrieben wurde, bevor du sie überhaupt an etwas übergibst, das eine saubere Datenbank erwartet.

Diagramm, das die ersten 100 Bytes einer SQLite-Datei in Header-Felder aufteilt: Magic-String, Seitengröße, Kodierung und Schema-Cookie, neben den rohen Hex-Bytes, die Hexter anzeigt. — Die ersten 100 Bytes jeder SQLite-Datei sind ein fester Header. Hexter liest ihn direkt aus den rohen Bytes.

Wann die Rohbyte-Ansicht wirklich zählt

Ein paar Situationen, in denen es Zeit spart, den Header direkt zu sehen, nicht nur die Abfrageergebnisse:

Eine Datei lässt sich in deiner App nicht öffnen, und du bist dir nicht sicher, ob sie überhaupt SQLite ist. Manche Apps schreiben Dateien mit einer .db-Endung, die gar kein SQLite sind. Das Prüfen auf den Magic-String SQLite format 3 in den ersten 16 Bytes beantwortet das in Sekunden.
Du debuggst eine Sync- oder Backup-Pipeline und vermutest, dass eine Datei unterwegs abgeschnitten oder beschädigt wurde. Ein Header, der zu kurz ist, oder ein Seitengrößenfeld, das nicht zur tatsächlichen Dateigröße passt, ist eine schnelle Diagnose.
Du willst die Textkodierung einer Datenbank bestätigen (UTF-8 vs. UTF-16), bevor du Code schreibst, der sie liest, ohne eine ganze Datenbankbibliothek hochzufahren, nur um eine Frage zu stellen.
Du reverse-engineerst den lokalen Speicher einer App und willst genau sehen, was auf der Festplatte liegt, bevor du entscheidest, ob es sich lohnt, eine richtige SQL-Abfrage dagegen zu schreiben.

So machst du es

Öffne die .sqlite- oder .db-Datei in Hexter. Sie öffnet schreibgeschützt, sodass kein Risiko besteht, eine Datenbank versehentlich zu verändern, die du intakt brauchst.
Öffne die Inspektor-Seitenleiste und wechsle zum Analysieren-Tab.
Hexter erkennt den SQLite-Header automatisch und zeigt dir die geparsten Felder neben den Byte-Offsets, aus denen sie stammen.
Wenn du ein bestimmtes Feld näher betrachten musst, etwa die Seitengröße oder das Schema-Cookie, wähle diese Bytes im Hex-Raster aus, und der Inspektor zeigt dir die numerische Interpretation direkt an.

Wenn du danach eigentlich die Tabellen abfragen musst, wechselst du dafür zu sqlite3 oder DB Browser. Das sind die richtigen Werkzeuge für diese Aufgabe. Hexter ist für die zehn Sekunden davor, wenn du einfach wissen musst, was du da vor dir hast.

Hexter ist ein nativer Hex-Editor für macOS, gebaut, um genau diese Art der Dateiinspektion standardmäßig sicher zu machen: schreibgeschützt, bis du das Bearbeiten ausdrücklich aktivierst, mit integriertem Struktur-Parsing für SQLite-, PNG-, ZIP-, Mach-O- und WAV-Dateien.