Lire et interpréter fichier binaire

Bonjour,
je débute en Python et souhaite pourvoir lire un fichier Python (un en format Int16, un en format Int32 et un en Double).

Ce fichier contient un nombre complexe (2 variable : partie réelle - partie imaginaire) : var1_réelle var1_imaginaire var2_réelle var2_imaginaire ... varn_réelle varn_imaginaire
J'ai commencé à écrire :

Code:

---

1 2	with open("fichier.bin", "rb") as binay_file: for line in binay_file:

---

Ensuite, j'ai dû mal à enregistrer les données dans les 2 tableaux "partie_réelle" et "partie_imaginaire" (en décimal)
Merci

le fichier a été créé comment ? (fonction python, outils, autre logiciel?) si c'est par une fonction python, tu dois avoir la fonction opposée qui permet de relire le fichier, sinon il faut a minima que tu ais l'info de codage (nombre d'octets pour chaque élément, et type de codage (mantisse/exposant, complément à deux, ..)

Tu parles de données en format entier (16 et 32 bits) et format double.
Tu indiques que le fichier contient UN nombre complexe, or tu listes n variables (partie entière/partie imaginaire en réelle, donc à virgule (possiblement donc des doubles))
Bref, tu ne donnes pas vraiment d'infos très cohérentes

Hello,

Faut se renseigner... et ne pas faire n'importe quoi. Si vous avez la théorie, au moins vous savez où aller, sans ça vous pissez du code juste pour dire que !

L'instruction for line in binay_file: est la principale source d'erreur ici. Cette syntaxe est conçue pour itérer sur les lignes d'un fichier texte, où les "lignes" sont délimitées par des caractères spéciaux de fin de ligne (comme \n ou \r\n). Les fichiers binaires, par nature, n'ont pas de concept de "lignes" au sens textuel du terme. Ils sont un flux continu d'octets.

Utiliser une lecture par ligne sur un fichier binaire structuré comme le vôtre (séquence de nombres) entraînera :

• Une découpe arbitraire des données : un nombre Int16 (2 octets), Int32 (4 octets) ou Double (8 octets) pourrait être scindé en deux si un octet b'\n' apparaît au milieu de sa représentation binaire.
• Une mauvaise interprétation des valeurs : les fragments d'octets lus ne correspondront plus aux nombres attendus.
• Des erreurs potentielles lors de la conversion si les fragments ne correspondent pas à la taille attendue par les fonctions de conversion.
• Une impossibilité de séparer correctement les parties réelles et imaginaires de manière fiable.

En résumé, cette approche est fondamentalement inadaptée à la nature des fichiers binaires contenant des données numériques structurées.

Pour lire correctement et de manière sûre un fichier binaire, plusieurs informations sont indispensables. Sans elles, toute tentative de code serait hasardeuse.

Donner les renseignements sur l'Endianness (bah oui faudra chercher et se renseigner), parce-que ça définit l'ordre dans lequel les octets constituant un nombre de plusieurs octets (comme un Int16, Int32 ou un Double) sont stockés en mémoire ou dans un fichier. Si votre fichier est écrit en little-endian et que votre code tente de le lire en big-endian (ou vice-versa), les valeurs numériques extraites seront complètement fausses. Pour un Int16, Int32 ou un Double, l'impact est significatif. Cette information n'est pas devinable ; elle doit être connue à partir de la spécification du format de fichier ou du système qui a généré le fichier. Voir demande de @umfred sur l'origine de ce fichier.

Bien que la description initiale mentionne "Int16, Int32 et Double" et la séquence "var1_réelle var1_imaginaire var2_réelle var2_imaginaire...", il faut être précis :

Ces précisions sont nécessaires pour construire la bonne "chaîne de format" qui indiquera à Python comment interpréter les blocs d'octets.

• Type de données par fichier : Un fichier est-il uniquement Int16, ou uniquement Int32, ou uniquement Double? Ou bien ces types sont-ils mélangés au sein d'un même fichier (ce qui complexifierait grandement la lecture)? L'énoncé "un en format Int16, un en format Int32 et un en Double" suggère des fichiers distincts, chacun avec un type homogène. C'est l'hypothèse retenue.
• Cohérence des types pour réel et imaginaire : La partie réelle et la partie imaginaire d'un même nombre complexe sont-elles du même type (par exemple, toutes deux Int16, ou toutes deux Double)? C'est généralement le cas.
• Taille des types :
  
  • Int16 (entier signé court) : typiquement 2 octets.
  • Int32 (entier signé) : typiquement 4 octets.
  • Double (nombre à virgule flottante double précision) : typiquement 8 octets, suivant la norme IEEE 754.

Python fournit le module struct pour gérer la conversion entre les valeurs Python et les structures C représentées comme des objets bytes (données binaires). C'est l'outil standard et approprié pour votre problème.

Le module struct repose principalement sur deux fonctions :

• struct.pack(format, v1, v2,...) : Convertit les valeurs Python v1, v2,... en un objet bytes (une chaîne d'octets) selon la chaîne de format format.
• struct.unpack(format, buffer) : Interprète l'objet bytes buffer selon la chaîne de format format et retourne les valeurs Python extraites sous forme d'un tuple. Même s'il n'y a qu'une seule valeur, elle est retournée dans un tuple.

Du coup vous avez beaucoup de documentations à lire et si ça a déjà été digéré et se trouve dans vos connaissances, alors soyez bien plus précis dans votre demande.

Citation:

---

Envoyé par BonhomNitram

je débute en Python et souhaite pourvoir lire un fichier python (un en format Int16, un en format Int32 et un en Double).

---

Ce n'est pas trop compliqué si on utilise les bibliothèques python qui font cela très bien comme numpy:

Code:

---

1 2 3 4 5 6 7 8

>>> import numpy as np >>> ar = np.array(range(5),dtype=np.int16) >>> b = ar.tobytes() >>> b # le contenu du fichier... b'\x00\x00\x01\x00\x02\x00\x03\x00\x04\x00' >>> np.frombuffer(b, dtype=np.int16) array([0, 1, 2, 3, 4], dtype=int16) >>>

---

Après il y a peut être d'autres détails côté bytes order.... mais numpy est bien documenté et plein d'exemples dont s'inspirer.

- W

note: ce n'est pas parce que c'est facile que les considérations mentionnées par fred1599 peuvent être ignorées: vous obtiendrez juste du n'importe quoi plus vite.

Bonjour, j'ai fini par essayer avec ce qui suit et cela semble marcher :

Code:

---

1 2 3 4 5 6 7 8 9

with open(forLoading_filePath, "rb") as binay_file: data = binay_file.read() # Convertir les données if str.lower(formatInfo) == "int16": conv_data = np.frombuffer(data, dtype=np.int16) elif str.lower(formatInfo) == "int32": conv_data = np.frombuffer(data, dtype=np.int32) else: logger.error('fill_DB: ')

---

Merci pour tous vos commentaires.

Citation:

---

Envoyé par BonhomNitram

Bonjour, j'ai fini par essayé avec ce qui suit et cela semble marché

---

ce n'est pas parce que ça marche sans erreur que le résultat n'est pas n'importe quoi.
Si je pars avec int16 et ce byte order:

Code:

---

1 2 3 4 5 6

>>> ar = np.array(range(6),dtype='>i2') >>> ar array([0, 1, 2, 3, 4, 5], dtype='>i2') >>> b = ar.tobytes() >>> b b'\x00\x00\x00\x01\x00\x02\x00\x03\x00\x04\x00\x05'

---

Je vais pouvoir relire ça comme int16/int32 sans soucis:

Code:

---

1 2 3 4 5

>>> np.frombuffer(b, dtype=np.int16) array([ 0, 256, 512, 768, 1024, 1280], dtype=int16) >>> np.frombuffer(b, dtype=np.int32) array([16777216, 50332160, 83887104], dtype=int32) >>>

---

mais comme je n'ai pas les données de départ, c'est n'importe quoi.

- W

Bonjour

Citation:

---

Envoyé par BonhomNitram

Code:

---

1 2 3 4 5 6

if str.lower(formatInfo) == "int16": conv_data = np.frombuffer(data, dtype=np.int16) elif str.lower(formatInfo) == "int32": conv_data = np.frombuffer(data, dtype=np.int32) else: logger.error('fill_DB: ')

---

---

Appeler la méthode "lower()" de façon générique et lui passer la str cible en paramètre ça marche... mais il existe une écriture plus adaptée => formatInfo.lower() (appeler directement la méthode de la chaine cible).
Ta façon de faire pourra s'envisager si tu dois traiter plusieurs chaines => tu fais une boucle et tu appelles str.lower(x) pour chaque "x" de la chaine. Mais pour une chaine précise, c'est inutilement plus compliqué.

Ensuite, pour évaluer plusieurs cas, tu as match qui te permettra de ne pas réécrire (réappeler plusieurs fois donc) la fonction

Code:

---

1 2 3 4 5

match formatInfo.lower(): case "int16": conv_data = np.frombuffer(data, dtype=np.int16) case "int32": conv_data = np.frombuffer(data, dtype=np.int32) case _: logger.error('fill_DB: ') # match

---

Pour le reste... je ne peux que te redire ce que d'autres ont écrit. Ce n'est pas parce que tu réussis à extraire des infos d'un fichier binaire que tu as correctement extrait les infos. Exemple: tu peux parfaitement ouvrir un mp3 dans word... mais ce que tu verras à l'écran ne sera ni lisible, ni écoutable. Avoir une version de test te permettrait de vérifier ton algo.

Citation:

---

Envoyé par Sve@r

Appeler la méthode "lower()" de façon générique et lui passer la str cible en paramètre ça marche... mais il existe une écriture plus adaptée => formatInfo.lower() (appeler directement la méthode de la chaine cible).

---

En passant un peu de temps dans la documentation de numpy et en maîtrisant les bases de python, on pourrait écrire cela:

Code:

---

1 2 3 4

try: convdata = np.fromfile(forLoading_filePath, dtype=np.dtype(formatInfo.lower()) except TypeError: logger.error('fill_DB')

---

mais ça veut dire prendre un peu de recul plutôt que chipoter sur un détail ...

- W

Citation:

---

Envoyé par wiztricks

En passant un peu de temps dans la documentation de numpy et en maîtrisant les bases de python, on pourrait écrire cela:

Code:

---

1 2 3 4

try: convdata = np.fromfile(forLoading_filePath, dtype=np.dtype(formatInfo.lower()) except TypeError: logger.error('fill_DB')

---

---

Oui aussi. Tu vois, quand tu veux, que tu peux toi aussi partager tes connaissances et montrer des possibilités au PO...

Citation:

---

Envoyé par wiztricks

mais ça veut dire prendre un peu de recul plutôt que chipoter sur un détail ...

---

Ah oui, "chipoter". Tu es tellement négatif que fatalement tu mets tout au péjoratif. Ce n'était pas du "chipotage" mais une info, juste une info. Il veut garder son code d'origine je n'en ferai pas une maladie. Mais là au-moins il connait une autre possibilité.

Citation:

---

Envoyé par Sve@r

Tu vois, quand tu veux, que tu peux toi aussi partager tes connaissances

---

Partager ses connaissances? on peut juste montrer ce qu'on sait/peut faire avec Python (et ses bibliothèques).
Dans ce cas particulier, ce sont des résultats (le code) obtenus après avoir passé plus ou moins de temps à (re)lire la documentation de numpy, y rechercher frombytes pour illustrer ce que je voulais raconter(*) et vérifié qu'il avait de la souplesse côté datatype,...
(*) j'avais exclu d'utiliser fromfile parce que je voulais illustrer la mécanique simplement.... et qu'il y a une documentation.

Récupérer le résultat de ce boulot n'apporte rien quant à sa capacité à le réaliser soi-même.
On prend le résultat.

Et je n'ai posté cela qu'en réaction a votre post et pour illustrer ce que vous avez des difficultés à comprendre.
note: Je ne méprise pas le PO, je pense juste qu'il a d'autres urgences... et qu'il peaufinera peut être plus tard.

- W

Citation:

---

Envoyé par wiztricks

Récupérer le résultat de ce boulot n'apporte rien quant à sa capacité à le réaliser soi-même.

---

Tout comme récupérer des exemples de tutoriels, ou bien des corrigés d'exercices. Celui qui écrit l'exemple ou le corrigé ne saura jamais si cet exemple/corrigé sera profitable à celui qui le récupère. Il n'en a que l'espoir (et s'en accomode).

Citation:

---

Envoyé par Sve@r

Tout comme récupérer des exemples de tutoriels, ou bien des corrigés d'exercices. Celui qui écrit l'exemple ou le corrigé ne saura jamais si cet exemple/corrigé sera profitable à celui qui le récupère. Il n'en a que l'espoir (et s'en accomode).

---

Dans ce cas, on a au moins fait l'effort d'ouvrir un tuto. et chercher un peu... Si on ne s'en sort pas ça transpire un peu dans la question posée. On peut alors se contenter de donner des pistes plutôt qu'une solution prête à emporter...
C'est toute la différence.

- W

Hello,

On peut tourner les choses dans tous les sens, avant de "coder", faut comprendre la théorie pour mettre en pratique. C'est comme si on essayait de résoudre un problème mathématique en comptant juste sur la prise en main d'une calculatrice... c'est juste aberrant.

Le code présenté par le PO le montre, itérer ligne par ligne un fichier binaire, c'est montrer ne pas savoir faire une différence entre fichier texte et fichier binaire...
Le fichier binaire ne contient aucune notion inhérente de "caractère" ou de "ligne". Chaque octet est une valeur numérique comprise entre 0 et 255.

Comme indiqué précédemment, la méthode correcte pour lire un fichier binaire structuré est de le traiter comme un flux continu d'octets à consommer par blocs de taille fixe.
Dans le contexte de la problématique, un "enregistrement" ou une "unité logique" est un nombre complexe unique, qui est lui-même composé de deux parties : une partie réelle et une partie imaginaire. Le "bloc" de données à lire à chaque itération doit donc correspondre exactement à la taille d'un de ces nombres complexes.


La taille de ce bloc est déterministe et dépend directement du type de données des composantes :

• Pour des complexes en Int16 : la taille du bloc est taille(Int16)+taille(Int16)=2 octets+2 octets=4 octets.
• Pour des complexes en Int32 : la taille du bloc est taille(Int32)+taille(Int32)=4 octets+4 octets=8 octets.
• Pour des complexes en Double : la taille du bloc est taille(Double)+taille(Double)=8 octets+8 octets=16 octets.

La logique de lecture consistera donc en une boucle qui, à chaque tour, lit un bloc de cette taille exacte depuis le fichier, le décode, et continue jusqu'à ce que la fin du fichier soit atteinte.

Le problème initial, qui semblait se diviser en trois tâches distinctes ("lire des Int16", "lire des Int32", "lire des Doubles"), est en réalité une seule et même tâche dont seuls les paramètres changent. La solution robuste et professionnelle n'est pas d'écrire trois scripts quasi identiques, mais de concevoir une seule fonction qui abstrait le type de données. Ce que tente de faire le PO si on regarde son code et ses conditions de types.


Imaginons que j'écrive trois fichiers binaires en choisissant un endianness courant.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

import struct     complexes_int = [(10, 20), (-30, 40), (0, -50)] complexes_float = [(1.23, 4.56), (-7.89, 10.11), (3.14159, -2.71828)]   ENDIANNESS = '<'   format_i16 = ENDIANNESS + 'hh' with open("complexes_i16.bin", "wb") as f_i16: print(f"Génération de 'complexes_i16.bin' avec le format '{format_i16}'...") for real, imag in complexes_int: packed_data = struct.pack(format_i16, real, imag) f_i16.write(packed_data) print("Fichier Int16 généré.")   format_i32 = ENDIANNESS + 'ii' with open("complexes_i32.bin", "wb") as f_i32: print(f"Génération de 'complexes_i32.bin' avec le format '{format_i32}'...") for real, imag in complexes_int: packed_data = struct.pack(format_i32, real, imag) f_i32.write(packed_data) print("Fichier Int32 généré.")   format_f64 = ENDIANNESS + 'dd' with open("complexes_f64.bin", "wb") as f_f64: print(f"Génération de 'complexes_f64.bin' avec le format '{format_f64}'...") for real, imag in complexes_float: packed_data = struct.pack(format_f64, real, imag) f_f64.write(packed_data) print("Fichier Double (f64) généré.")

---

Se lira,

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74

import struct from typing import Any     def lire_complexes_struct( filename: str, format_char: str, endianness: str = "<" ) -> tuple [list[int], list[int]] | tuple [list[float], list[float]]: block_format = endianness + format_char * 2 try: block_size = struct.calcsize(block_format) except struct.error: print(f"Erreur : Le caractère de format '{format_char}' est invalide.") return [], []   real_parts: list[Any] = [] imaginary_parts: list[Any] = []   try: with open(filename, "rb") as binary_file: while True: chunk = binary_file.read(block_size)   if not chunk: break   if len(chunk) < block_size: print( f"Avertissement : Fichier '{filename}' potentiellement corrompu. " f"Dernier bloc incomplet ignoré." ) break   try: real, imag = struct.unpack(block_format, chunk) real_parts.append(real) imaginary_parts.append(imag) except struct.error: print( f"Avertissement : Erreur lors du dépaquetage d'un bloc dans '{filename}'. Bloc ignoré." )   except FileNotFoundError: print(f"Erreur : Le fichier '{filename}' n'a pas été trouvé.") return [], [] except IOError as e: print(f"Erreur d'E/S lors de la lecture du fichier '{filename}': {e}") return [], []   return real_parts, imaginary_parts     if __name__ == "__main__": print("--- Lecture du fichier Int16 ---") reels_i16, imags_i16 = lire_complexes_struct("complexes_i16.bin", "h") if reels_i16: print(f"Parties réelles: {reels_i16}") print(f"Parties imaginaires: {imags_i16}") print(f"Paires (réel, imag): {list(zip(reels_i16, imags_i16))}\n")   print("--- Lecture du fichier Int32 ---") reels_i32, imags_i32 = lire_complexes_struct("complexes_i32.bin", "i") if reels_i32: print(f"Parties réelles: {reels_i32}") print(f"Parties imaginaires: {imags_i32}") print(f"Paires (réel, imag): {list(zip(reels_i32, imags_i32))}\n")   print("--- Lecture du fichier Double ---") reels_f64, imags_f64 = lire_complexes_struct("complexes_f64.bin", "d") if reels_f64: print(f"Parties réelles: {reels_f64}") print(f"Parties imaginaires: {imags_f64}") print(f"Paires (réel, imag): {list(zip(reels_f64, imags_f64))}\n")

---

Résultat

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

--- Lecture du fichier Int16 --- Parties réelles: [10, -30, 0] Parties imaginaires: [20, 40, -50] Paires (réel, imag): [(10, 20), (-30, 40), (0, -50)]     --- Lecture du fichier Int32 --- Parties réelles: [10, -30, 0] Parties imaginaires: [20, 40, -50] Paires (réel, imag): [(10, 20), (-30, 40), (0, -50)]     --- Lecture du fichier Double --- Parties réelles: [1.23, -7.89, 3.14159] Parties imaginaires: [4.56, 10.11, -2.71828] Paires (réel, imag): [(1.23, 4.56), (-7.89, 10.11), (3.14159, -2.71828)]

---

Après le choix de struct, numpy, ... peu importe une fois qu'on sait ce qu'on fait. Numpy est une dépendance externe, c'est un fait, et son besoin est souvent en liaison avec les grandes structures de données.
Je suppose que dans ce cas de figure, struct est un besoin très largement suffisant.

Citation:

---

Envoyé par fred1599

On peut tourner les choses dans tous les sens, avant de "coder", faut comprendre la théorie pour mettre en pratique.

---

Savoir découper une séquence d'objets en paquets de 2, 3, ...n est un bon exercice qu'on devrait savoir coder facilement.

Des qu'on fait des calculs ou qu'on travaille sur des images, ce sera un boulot récurrent pour lequel avant d'écrire ses fonctions génériques on regardera ce qui existe côté bibliothèques car il n'y a pas de raison pour que notre besoin soit très original.

Une bibliothèque capture l'intelligence et savoir faire qui va avec...
On peut l'utiliser avec une vague idée de comment elle fonctionne, sans trop savoir la recoder par soi même...
Dommage peut être, mais c'est comme çà (et ce n'est pas propre à la programmation).

Après on a le besoin que le PO exprime....
Il ferait bien de peaufiner sa formation en python avant de se lancer dans de petits projets... mais même s'il savait écrire ce genre de code, je lui recommanderai quand même d'utiliser une bibliothèque telle que numpy pour obtenir quelque chose de fonctionnel le plus rapidement possible (quitte à optimiser plus tard si besoin).

- W