[Résolu] Export CSV > données parasites pour mise en forme

[creusois]

Bonsoir,

Je constate que j'ai des données qui parasitent la mise en forme de mes exports CSV ("individus") lorsque je les importe dans un tableur... je m'explique
Mon fichier GEDCOM est originaire d'Heredis et donc traîne des données non formatées de façon propre et rigoureuse selon les critères Gedcom.

Après un export de la table des individus au format CSV, je fais un import dans mon tableur LibreOffice et j'ai beau jouer avec les différentes "options de séparation" (tabulations bien sûr), je me retrouve systématiquement avec des lignes supplémentaires dans mon fichier final. Lignes qui sont des retour à la ligne de celles qui les précèdent. Elles contiennent notamment les notes contenues dans le champs "Notes décès"

Avez-vous un conseil à me donner afin de conserver l'ensemble des données d'un individu sur une seul et même ligne ?

Merci par avance.

[creusois]

Bonsoir,

Mon pb vient des "retours chariot" se trouvant dans les "notes".
Une idée pour conserver dans la même cellule du tableur lors de l'import du CSV les notes contenant ces "retours chariot" ? 

Merci par avance.

[creusois]

J'ai trouvé une solution de contournement puisque je n'ai pas besoin des "notes" dans mes exports en liste.
Je déselecionne les champs "notes" dans le paramétrage de la vue pour procéder à un export CSV sans ces dernière ... je ne suis plus embêté par des retour à la ligne intempestif.

Bonne soirée.

[Zurga]

A partir de quel endroit faites vous les exports CSV ?
Le format CSV n'accepte pas les passages à la lignes, il faut que nous les échappions si nous ne l'avons pas fait ou que nous ajoutions des doubles guillemets pour éviter que le changement de ligne soit pris en compte.

Zurga

[creusois]

Bonsoir,

A partir de quel endroit faites vous les exports CSV ?...

A partir de la table des individus.

Le format CSV n'accepte pas les passages à la lignes, il faut que nous les échappions si nous ne l'avons pas fait ou que nous ajoutions des doubles guillemets pour éviter que le changement de ligne soit pris en compte...

Effectivement, c'est bien pour cela que je ne sélectionne pas les "notes" que j'utilise beaucoup et dans lesquelles je place des retours pour des questions de mise en forme basiques des infos.

Il me suffit donc de faire des exports sans ces champs, et c'est parfait.
merci bien.

[Zurga]

C'est corrigé.
Ce sera dans la version de demain.

Zurga

[creusois]

C'est corrigé. Ce sera dans la version de demain. Zurga

Bonjour et Merci bien pour votre réactivité.

Effectivement .. par contre tous les champs sont exportés avec des doubles quotes et certains retours chariot ont été "conservés" et donc il y atoujours des retours à la ligne intempestif.
Je joint une capture pour visualisation.
Cordialement.

[Zurga]

Je ne sais pas quel logiciel vous utilisez.
Libre-office gère très bien ces cas.
Notamment en lui indiquant que les double-quotes encadrent des chaines de caractères, elles disparaissent des cases et les passages à la ligne sont bien gérés.

Zurga

[creusois]

Je ne sais pas quel logiciel vous utilisez.
Libre-office gère très bien ces cas.
Notamment en lui indiquant que les double-quotes encadrent des chaines de caractères, elles disparaissent des cases et les passages à la ligne sont bien gérés.

Au temps pour moi !!!

Je suis 100% open source, du tél. mobile à l'ordi (cf. ma signature  ) donc bien sûr aussi Libre Office ...
J'avais procédé à d'autres essais sur d'autres types de CSV et voulant aller trop vite, j'ai laissé tel quel.

Donc résultat OK et parfait comme toujours avec l'équipe Ancestris 

[creusois]

re-Bonsoir,

Avec une étupe un peu plus poussée de mon CSV importé dans mon tableur, je vois que le champs "Note" de l'événement "General" est incorrectement traité.
Les retours chariots sont malheureseument effectifs dans le fichier final ODT (cf; capture).

les autres champs "notes" des autres évènements semblent correctement traités.

Qu'en pensez-vous ?

[Zurga]

Cela devient compliqué si en plus des sauts de lignes vous mettez des guillemets dans le texte de vos notes.
Je rajoute un échappement pour ce cas de figure.
Cela devrait être corrigé dans l'update du 18 novembre.

Zurga

[creusois]

Bonjour,

Il est effectivement difficile de tenir compte du "comportement" de chacun dans l'utilisation d'un logiciel lorsqu'on le développe.
Surtout que lorsqu'il n'y a pas de contrainte dans une note et que le texte est "brut", l'utilisation des "quotes", "doubles quotes" et autres "caractères spéciaux" est monnaie courante.
Sauf à passer par une multiplication de messages d'alertes ou d'avertissements à la saisie, qui au final ont tendance à polluer son utilisation, le fait est que les exceptions doivent être le plus rare.

Bon et bien encore merci et bonne continuation.

[Zurga]

C'est de ma faute, j'aurais du vérifier les échappements de tous les caractères spécifiques au format quand j'ai introduit l'échappement du passage à la ligne.

Normalement, tout est pris en compte, y compris que le jeu de caractère est bien UTF-8 pour le document produit (ce qui n'était pas le cas avant).

Zurga