Un fichier de sauvegarde est souvent opaque juste au moment où on en a le plus besoin : cette visionneuse reconnaît donc les familles que les jeux réels utilisent et montre ce que chaque spécification expose. Le NBT de la famille Minecraft est analysé balise par balise selon la spécification wiki.vg (les 12 types de balises, enveloppes gzip/zlib/brut — level.dat en gzip, servers.dat brut). Les saves Unreal Engine sont identifiés par la magie "GVAS" et décodés selon la disposition uesave/gvas : version du save, versions de paquet UE4 et UE5, le tuple FEngineVersion avec sa branche, et la table des versions personnalisées ; les sauvegardes Palworld de Steam sont déballées à travers leur conteneur réel (deux entiers d’en-tête, magie "PlZ1", flux zlib) jusqu’à la charge GVAS. Les saves SQLite sont ouverts en lecture seule via node:sqlite et listés table par table avec comptages et lignes d’aperçu. Les saves texte sont détectés structurellement : JSON (style deck-builder), XML (un SaveGame de Stardew Valley est reconnu par ses champs racine documentés), INI (y compris la configuration [/Script/…] d’Unreal) et tables Lua (famille Hades). Les conteneurs Zip sont listés avec leurs entrées internes. Tout le reste retombe sur une lecture d’entropie de Shannon, un dump hex des 256 premiers octets et un balayage des chaînes imprimables, avec une heuristique pour les .sav du moteur Source dont les jetons de blocs (ADVSYS, EntityPatch, Response System…) sont documentés sur la Valve Developer Community. Les champs liés à la progression (name, level, gold, health, seed, playtime…) sont extraits dans un panneau de faits clés, et chaque analyse est bornée — budget de nœuds, plafond de profondeur, aperçus de tableaux — car les sauvegardes sont une entrée non fiable. Où vivent les saves ? Les jeux avec Steam Cloud les gardent sous Steam/userdata///remote (selon la documentation Steamworks) ; les autres, où le jeu le décide. Cet outil ne modifie jamais votre fichier — il lit une copie en mémoire et se contente de rendre.