Comment consulter un fichier de base de données SQLite sur Mac

Vous avez trouvé un fichier .sqlite, .db ou .sqlite3 quelque part sur votre Mac, dans le dossier de support d’une application, dans une sauvegarde, dans un projet que vous déboguez, et vous voulez savoir ce qu’il contient réellement. Le double-clic ne fait rien d’utile. Quick Look vous montre un aperçu vide ou du texte brouillé. Il vous faut un vrai visualiseur de fichiers SQLite, et l’outil vers lequel se tourner n’est pas évident.

Pourquoi vous ne pouvez pas simplement l’ouvrir comme un fichier normal

Les bases de données SQLite sont des fichiers binaires, pas du texte. Les 100 premiers octets sont un en-tête fixe : une chaîne magique qui se lit SQLite format 3, suivie de champs comme la taille de page, l’encodage du texte et un cookie de schéma qui change chaque fois que la structure des tables est modifiée. Après cet en-tête viennent les données de page proprement dites, organisées en arbre B, ce qui explique pourquoi un éditeur de texte les affiche comme du bruit.

Le Quick Look du Finder n’analyse rien de tout cela. TextEdit l’interprète comme du texte brut et vous montre surtout des caractères illisibles, avec quelques chaînes reconnaissables mélangées (les noms de tables, les noms de colonnes et toute donnée textuelle stockée dans les tables ont tendance à survivre, car SQLite stocke les chaînes en grande partie telles quelles). Rien de cela ne vous dit si le fichier est réellement valide, avec quelle taille de page il a été créé, ni pourquoi une autre application refuse de l’ouvrir.

Vos options pour regarder à l’intérieur

L’outil en ligne de commande sqlite3. macOS est livré avec sqlite3 dans le Terminal. Lancez sqlite3 yourfile.db ".schema" et vous obtiendrez les définitions des tables, ou .tables pour une liste rapide. Cela fonctionne bien si vous savez déjà qu’il s’agit d’une base de données valide et que vous voulez l’interroger. C’est moins utile si vous n’êtes pas sûr que le fichier soit valide au départ, car un en-tête corrompu produit juste une erreur obscure, sans détail sur ce qui ne va pas.

DB Browser for SQLite. C’est le bon outil si votre véritable objectif est de parcourir les lignes des tables, d’éditer des données ou d’exécuter des requêtes SQL. Il est gratuit, bien entretenu et conçu spécifiquement pour cette tâche. Si vous devez explorer les données à l’intérieur des tables, arrêtez de lire ceci et allez chercher DB Browser.

Un éditeur hexadécimal conscient de SQLite. C’est l’option pour une question différente : non pas « qu’y a-t-il dans les tables » mais « qu’est-ce que ce fichier, au juste ». C’est le vide que Hexter comble. Ouvrez le fichier et il se lit en lecture seule par défaut, donc vous ne risquez rien juste en regardant. L’onglet Analyser reconnaît l’en-tête SQLite au premier coup d’œil et en détaille les champs, taille de page, encodage, cookie de schéma, à côté de l’hexadécimal brut, pour que vous puissiez confirmer que le fichier est bien du SQLite, vérifier avec quelle taille de page il a été construit, ou repérer un en-tête tronqué ou écrasé avant même de le confier à quelque chose qui attend une base de données propre.

Quand la vue en octets bruts compte vraiment

Voici quelques situations où voir l’en-tête directement, et pas seulement les résultats de requête, fait gagner du temps :

• Un fichier refuse de s’ouvrir dans votre application, et vous n’êtes pas sûr qu’il soit vraiment du SQLite. Certaines applications écrivent des fichiers avec une extension .db qui ne sont pas du SQLite du tout. Vérifier la présence de la chaîne magique SQLite format 3 dans les 16 premiers octets tranche cette question en quelques secondes.
• Vous déboguez un pipeline de synchronisation ou de sauvegarde et suspectez qu’un fichier a été tronqué ou corrompu en transit. Un en-tête coupé court, ou un champ de taille de page qui ne correspond pas à la taille réelle du fichier, est un diagnostic rapide.
• Vous voulez confirmer l’encodage du texte d’une base de données (UTF-8 ou UTF-16) avant d’écrire du code qui la lit, sans lancer toute une bibliothèque de base de données juste pour poser une seule question.
• Vous faites de la rétro-ingénierie sur le stockage local d’une application et voulez voir exactement ce qui se trouve sur le disque avant de décider s’il vaut la peine d’écrire une vraie requête SQL dessus.

Comment procéder

1. Ouvrez le fichier .sqlite ou .db dans Hexter. Il s’ouvre en lecture seule, donc aucun risque de modifier par accident une base de données que vous devez garder intacte.
2. Ouvrez la barre latérale Inspecteur et passez à l’onglet Analyser.
3. Hexter détecte l’en-tête SQLite automatiquement et vous montre les champs analysés à côté des offsets d’octets dont ils proviennent.
4. Si vous devez regarder de plus près un champ précis, comme la taille de page ou le cookie de schéma, sélectionnez ces octets dans la grille hexadécimale et l’Inspecteur vous en montre directement l’interprétation numérique.

Si ce dont vous avez réellement besoin ensuite, c’est d’interroger les tables, c’est là que vous passez à sqlite3 ou à DB Browser. Ce sont les bons outils pour cette tâche. Hexter est là pour les dix secondes qui précèdent, quand vous avez juste besoin de savoir ce que vous regardez.

Hexter est un éditeur hexadécimal natif pour macOS, conçu pour rendre exactement ce genre d’inspection de fichiers sûr par défaut : en lecture seule jusqu’à ce que vous activiez explicitement l’édition, avec une analyse de structure intégrée pour les fichiers SQLite, PNG, ZIP, Mach-O et WAV.