Bonjour,
J'ai en ma possession une base de données, et un outil client.
Dans la base de données, j'ai des données sous forme binaire (BLOB).
Depuis l'interface client, je peux voir que ces données renferment des données strucurées, et notamment du texte.
J'ai tenté de récupérer le contenu de ces BLOB sous forme de fichiers, mais à la vision dans un éditeur Hexa ou de texte, je ne vois pas le moindre caractère intelligible.
J'en déduit que :
- soit les données sont compressées
- soit elles sont cryptées
Étant donné le volume de données affichée dans l'application en rapport avec la taille des données en base, j'en déduis qu'elles sont effectivement compressées.
En toute logique, elle ne sont pas cryptées (leur nature ne nécessite aucunement un encryptage).
J'ai tenté de sauvegarder le contenu d'un BLOB dans un fichier, puis de le décompresser avec 7zip : rien n'y fait, il ne comprends pas du tout ce que c'est que ces données.
J'en déduis que :
- soit j'ai affaire à un "développeur" qui a inventé son propre algo de compression plutôt que de reprendre un standard (gzip, bzip2, etc.)
- soit le "développeur" s'est dit "tiens, je vais gagner 5 octet par blob en ne stockant pas le header du flux compressé"
J'ai donc entrepris de rajouter une entête et un pied de document pour le rendre conforme mon fichier aux spécifications de GZip et BZip2.
Mais après moultes tentatives, je me rends compte que pour ces deux algo :
- J'ai besoin de la taille du flux d'origine
- Du CRC32 du flux d'origine
Hors je n'ai ni l'un ni l'autre : dans la base c'est qu'une autre colonne qui contient la taille du BLOB "en l'état"... Genre le "développeur" sait pas récupérer la taille d'un BLOB en base alors il la stock, mais à côté de ça il m'emmerde à compresser son truc comme un porc.
Bref, je continue toujours à essayer de trouver comment ça a pu être compressé.
Je recherche un algo "standard" dont l'entête serait "fixe" (c'est à dire non dépendante du flux d'origine, mais pouvant intégralement être déduire du flux généré).
Une idée ?
Partager