Problème saut de ligne incompréhensible

en cherchant un peu des infos relatives aux fichiers ".dbf" que tu évoquais rapidement plus tôt dans la discussion on tombe sur deux liens intéressants :

• http://mscnastrannovice.blogspot.fr/...df-or-dat.html
• https://simcompanion.mscsoftware.com...nt&id=DOC10004

donc l'extension si elle ne change pas le contenu du fichier n'est tout de même pas anodine puisqu'elle peut révéler de quel type de fichier il s'agit

on apprend notamment dans le deuxième lien :

• qu'il s'agit d'un "Small Field Format"
• que chaque ligne comporte obligatoirement 10 champs de 8 caractères chacun, le 10e champ ayant une signification (donc une ligne qui fait moins de 80 caractères est invalide)
• que les champs 1 et 10 (premier et dernier donc) doivent avoir un alignement à gauche obligatoire
• que l'alignement des champs 2 à 9 importe peu
• qu'un champ ne comportant pas de valeur doit être représenté vide, donc par 8 espaces (:aie:)

(on apprend également qu'il y avait moyen d'exporter dans un format "Free Field" dont les champs sont simplement séparés par des virgules, loin de moi l'idée de dire que le format fixe c'est du caca en barre mais ce dernier format permet sans doute moins d'erreurs...)

donc au temps pour moi, la solution pour le coup c'est bien de rajouter les espaces manquants à la ligne 5 du fichier :oops:, ça veut aussi dire qu'une ligne qui ne fait pas très exactement 81 caractères (80 + '\n') devrait être prise en compte par le programme et donner lieu à un traitement spécifique (remontée d'erreur, arrêt du programme, correction automatique de la ligne ou autre)

Citation:

---

Envoyé par nekcorp

En fait si j'ai utilisé les formules "bourins" dans mon code de départ c'est parce qu'il faut respecter 8 caractères maximum dans un champ.

Si vous prenez l'exemple de GRID, à lui tout seul il fait 4 caractères du coup le nombre d'espace que je dois ajouter c'est 4 afin de respecter les 8 caractères max et ainsi pouvoir écrire dans le champ suivant.

---

Si une ligne commençant par GRID est composée de 9 éléments de longueur fixée à 8, .split va dégager les champs non renseignés (là ou il n'y a que des espaces) et ne verra pas les champs accolés (ceux qui ne sont pas séparés par 1 espace).
Exemple:

Code:

---

1 2	>>> line 'GRID 86725 8290. 1863.13 2003.55 \n'

---

Avec .split, on obtient:

Code:

---

1 2 3

>>> line.split() ['GRID', '86725', '8290.', '1863.13', '2003.55'] >>>

---

et on perd le 3ème élément...
Si on doit découper la ligne par paquets de 8:

Code:

---

1 2	>>> [ line[x: x+8].strip() for x in range(0, len(line[:-1]), 8) ] ['GRID', '86725', '', '8290.', '1863.13', '2003.55', '', '', '', '']

---

Pour le cas ou la line est "incomplète":

Code:

---

1 2 3 4

>>> line = 'GRID 86729 8288. 1750. 2003.55' >>> items = [ line[x: x+8].strip() for x in range(0, len(line[:-1]), 8) ] >>> items ['GRID', '86729', '', '8288.', '1750.', '2003.55']

---

On peut ajouter les éléments à la fin:

Code:

---

1 2 3 4

>>> VARCOUNT = 10 >>> items += [ '' ] * (VARCOUNT- len(items)) >>> items ['GRID', '86729', '', '8288.', '1750.', '2003.55', '', '', '', '']

---

Et on peut remettre tout çà en forme avec:

Code:

---

1 2 3

>>> ''.join(FORMAT % s for s in items) 'GRID 86729 8288. 1750. 2003.55 ' >>>

---

Reste à comprendre l'intérêt de la manip. puisqu'ici on découpe et on réassemble à l'identique.
Enfin presque car on ajoute des 'espaces' aux lignes trop courtes, mais çà pourrait être fait plus simplement.

- W

Citation:

---

Envoyé par BufferBob

d'accord.

voici les 8 premières lignes du fichier MPC_NODE.dat que tu as fourni plus haut :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CARD ID CP X1 X2 X3 CD PS SEID --------_______--------________--------________--------________-------- 1 'GRID 86725 8290. 1863.13 2003.55 \n' 2 'GRID 86726 8290. 1842.13 2003.55 \n' 3 'GRID 86727 8290. 1821.13 2003.55 \n' 4 'GRID 86728 8290. 1800.13 2003.55 \n' 5 'GRID 86729 8288. 1750. 2003.55\n' 6 'CROD 10000 \n' 7 'GRID 86730 8288. 1726. 2003.55 \n' 8 'GRID 86731 8288. 1689. 2003.55 \n' --------_______--------________--------________--------________-------- CARD ID CP X1 X2 X3 CD PS SEID

---

la ligne 5 (celle qui précède la ligne commençant par "CROD") fait 48 caractères de long, en conséquence le saut de ligne se trouve sur le 48ème caractère, et se retrouve inclu dans le champs CD, alors que les autres lignes commençant par "GRID" ne prennent jamais en compte le saut de ligne à cause des nombreux espaces en fin de ligne
c'est peut-être plus clair ainsi ?

il est assez évident (?) que la bonne solution ne consiste pas à rajouter des espaces à la fin de la ligne 5, la preuve, c'est difficile de s'en rendre compte
pour le redire simplement; découper par colonnes n'est pas une bonne idée, le découpage par colonnes comme tu le fais donne à l'espace une importance qu'il ne devrait pas avoir.

---

J'ai l'impression que tu n'as pas très bien compris mon problème. Le fichier que j'ai fournis il est généré par un autre logiciel (Msc Patran) je ne gère pas le format, enfin si je peux gérer les formats en informant uniquement si je souhaite des formats court où long mais sans plus. Du coup je dois faire avec le fichier tel qu'il est.

Dans le cas de mon exemple il ni a pas beaucoup de lignes à traiter mais on peut vite passer à 500 000 lignes facilement. Du coup lorsque j'ai codé mon script j'ai essayé d'anticipé toutes les éventualités et celle du retour de ligne m'a échappé.
Je me suis simplement concentré sur les 8 caractères max par champ (pour les formats courts). Donc mon découpage par colonne est loin d'être la mauvaise idée à mon sens il faut juste s'assurer de bien ré-écrire pour le coup le nouveau fichier de sortie.

Citation:

---

Envoyé par BufferBob

en cherchant un peu des infos relatives aux fichiers ".dbf" que tu évoquais rapidement plus tôt dans la discussion on tombe sur deux liens intéressants :

• http://mscnastrannovice.blogspot.fr/...df-or-dat.html
• https://simcompanion.mscsoftware.com...nt&id=DOC10004

donc l'extension si elle ne change pas le contenu du fichier n'est tout de même pas anodine puisqu'elle peut révéler de quel type de fichier il s'agit

on apprend notamment dans le deuxième lien :

• qu'il s'agit d'un "Small Field Format"
• que chaque ligne comporte obligatoirement 10 champs de 8 caractères chacun, le 10e champ ayant une signification (donc une ligne qui fait moins de 80 caractères est invalide)
• que les champs 1 et 10 (premier et dernier donc) doivent avoir un alignement à gauche obligatoire
• que l'alignement des champs 2 à 9 importe peu
• qu'un champ ne comportant pas de valeur doit être représenté vide, donc par 8 espaces (:aie:)

(on apprend également qu'il y avait moyen d'exporter dans un format "Free Field" dont les champs sont simplement séparés par des virgules, loin de moi l'idée de dire que le format fixe c'est du caca en barre mais ce dernier format permet sans doute moins d'erreurs...)

donc au temps pour moi, la solution pour le coup c'est bien de rajouter les espaces manquants à la ligne 5 du fichier :oops:, ça veut aussi dire qu'une ligne qui ne fait pas très exactement 81 caractères (80 + '\n') devrait être prise en compte par le programme et donner lieu à un traitement spécifique (remontée d'erreur, arrêt du programme, correction automatique de la ligne ou autre)

---

Oui effectivement le traitement de ses fichiers fait partis de mon boulot du quotidien, les doc que tu cite je les utilise également.
Il existe pas mal de "vieilles routines" en internes écrites en FORTRAN qui fonctionnent très bien pour gérer ces formats de fichiers. Mais moi je suis de la nouvelle école et je souhaite combler les lacunes en introduisant des scripts en python.

concernant le format avec virgule je suis d'accord avec toi j'aurai surement moins d'erreurs et ça serait moins compliqué je pense à coder, sauf que le format choisit au boulot est celui sans les virgules :mouarf: Ne me demande pas pourquoi c'est comme ça depuis 60 ans. Du coup pas trop le choix.

Mais merci pour tes remarques certaines choses m'avaient échappées.

Citation:

---

Envoyé par wiztricks

Si une ligne commençant par GRID est composée de 9 éléments de longueur fixée à 8, .split va dégager les champs non renseignés (là ou il n'y a que des espaces) et ne verra pas les champs accolés (ceux qui ne sont pas séparés par 1 espace).
Exemple:

Code:

---

1 2	>>> line 'GRID 86725 8290. 1863.13 2003.55 \n'

---

Avec .split, on obtient:

Code:

---

1 2 3

>>> line.split() ['GRID', '86725', '8290.', '1863.13', '2003.55'] >>>

---

et on perd le 3ème élément...
Si on doit découper la ligne par paquets de 8:

Code:

---

1 2	>>> [ line[x: x+8].strip() for x in range(0, len(line[:-1]), 8) ] ['GRID', '86725', '', '8290.', '1863.13', '2003.55', '', '', '', '']

---

Pour le cas ou la line est "incomplète":

Code:

---

1 2 3 4

>>> line = 'GRID 86729 8288. 1750. 2003.55' >>> items = [ line[x: x+8].strip() for x in range(0, len(line[:-1]), 8) ] >>> items ['GRID', '86729', '', '8288.', '1750.', '2003.55']

---

On peut ajouter les éléments à la fin:

Code:

---

1 2 3 4

>>> VARCOUNT = 10 >>> items += [ '' ] * (VARCOUNT- len(items)) >>> items ['GRID', '86729', '', '8288.', '1750.', '2003.55', '', '', '', '']

---

Et on peut remettre tout çà en forme avec:

Code:

---

1 2 3

>>> ''.join(FORMAT % s for s in items) 'GRID 86729 8288. 1750. 2003.55 ' >>>

---

Reste à comprendre l'intérêt de la manip. puisqu'ici on découpe et on réassemble à l'identique.
Enfin presque car on ajoute des 'espaces' aux lignes trop courtes, mais çà pourrait être fait plus simplement.

- W

---

Merci wiztricks pour cet élément de réponse.

J'ai pas encore testé tes recommandations mais pour répondre à ton interrogation

Citation:

---

Reste à comprendre l'intérêt de la manip. puisqu'ici on découpe et on réassemble à l'identique.

---

En fait si tu te rappel au début j'expliquais que je devais renuméroter mes cartes GRID en modifiant le 2ème champs et mon soucis c'était que lorsque je ré-écrivais le fichier avec les cartes renumérotés, j'avais des sauts de lignes qui apparaissaient mais que je ne comprenais pas pourquoi.

De plus le fait de comprendre comment manipuler ce genre de fichier cela me permettra par la suite de mettre en place des outils car cet exemple est très simple, j'ai des projets de scripts plus ambitieux pour la suite.:mouarf:

Citation:

---

Envoyé par nekcorp

Mais merci pour tes remarques certaines choses m'avaient échappées.

---

de mémoire c'est du côté des pages 1050 et quelques

Citation:

---

Envoyé par nekcorp

En fait si tu te rappel au début j'expliquais que je devais renuméroter mes cartes GRID en modifiant le 2ème champs et mon soucis c'était que lorsque je ré-écrivais le fichier avec les cartes renumérotés, j'avais des sauts de lignes qui apparaissaient mais que je ne comprenais pas pourquoi.

---

on est d'accord pour dire en l'occurrence que la ligne 5 du fichier n'était pas valide (48 caractères au lieu de 81 normalement) et par extension la ligne 6 (celle commençant par CROD) également ?
si c'est l'application qui tronque les lignes ainsi c'est soucieux à mon avis, puisque ça ne respecterait pas le format décrit dans leurs propres spécifications :?

Citation:

---

Envoyé par nekcorp

Salut marco056,

Je ne comprend pas ta question. Les fichiers que j'utilise sont des fichiers de donnés pour des calculs par éléments finis utilisés sous le logiciel Patran.
Ces fichiers sont générés par Patran en format texte (l'extension importe peu : .dat, .bdf, etc ....).

Que veux tu savoir exactement ?

Cordialement

---

En fait, je n'ai pas le logiciel Patran et je télécharge de temps en temps en temps les fichiers grib pour mon usage perso mais je n'ai jamais accès aux fichiers de données (que ce soit en txt ou autre).
D'où ma question. Je vais creuser...