Input data - fichier texte - séparateur de fin de ligne

[robi]

Bonjour

Je suis étonné de ne pas trouver un type "File format" simple pour lire des fichiers dont le délimiteur Fin de ligne (EOF End OF File) est CR (ascii 13) +LF (ascii 10).
Ce fichier peut contenir des fields commentaires qui contiennent des LF (ascii 10).

J'ai regardé la solution avec File Format = "Flat ASCII (*.flat)" pour préciser File/Field Layout et EOL = CRLF

mais message d'erreur "Missing FlatFileXML Specification" que je ne comprends pas car, a priori, je ne fais pas appel à un fichier de spécification des paramètres.

MERCI !

[carlosteixeira]

Bonjour mon ami @robi , comment vas-tu?

Quel format de fichier essayez-vous de lire ?

Avez-vous essayé de lire avec le format csv et le délimiteur \0 ?

Pouvez-vous partager des exemples de fichiers ? et quelques photos de ce que tu veux faire ?

Ainsi nous pouvons mieux vous aider

Merci

Carlos A Teixeira

[Toons]

Bonjour @robi ,

Effectivement, le format de fichier ".flat" est applicable à un fichier à structure fixe où tu dois définir le début et la fin de chaque colonne.

En choisissant un type ".csv", il n'y a pas d'option pour définir les caractères de fin de ligne (en tout cas je ne l'ai pas trouvé non plus).

Par contre, dans ton fichier source, si tu délimites avec des guillemets les valeurs qui incluent des sauts de ligne (LF), en cochant ensuite l'option "Ignorer les délimiteurs dans" dans ton format de fichier, tu devrais être capable de lire correctement le contenu du fichier.

Par ex, avec un contenu comme celui-ci :

11111;1111111;TOTO
123456;"123
456";TUTU
"222
22";22222;TOTO

On obtient :

[robi · Accepted solution]

Merci @carlosteixeira et @Toons 

Je connais bien le \0 et la problématique du "

Mais essayez de traiter un fichier composé ainsi :

où la fin d'enregistrement est CRLF mais avec des LF qui viennent se glisser dans les données...
Il ne s'agit ni d'un pb de délimiteur (solutionnables par \0) ni de " qui empêcherait la détection des délimiteurs....

mais d'un pb de délimiteur de fin de ligne qu'il serait bien de pouvoir AUSSI paramétrer dans un INPUT DATA.

J'ai solutionné en passant par des multi formula ligne pour recoller (dans l'exemple ci-dessus) les lignes 27+28+29 en 1 seule ligne de données, 1 seul enregistrement logique...

Merci pour vos messages.

[Toons]

---

@robi  a écrit :

Mais essayez de traiter un fichier composé ainsi :

où la fin d'enregistrement est CRLF mais avec des LF qui viennent se glisser dans les données...
Il ne s'agit ni d'un pb de délimiteur (solutionnables par \0) ni de " qui empêcherait la détection des délimiteurs....

---

Avec la solution que je te propose ci-dessus, je pense que ton problème serait résolu. Elle est valable si tu as la possibilité de pouvoir obtenir ton fichier source avec les valeurs de tes colonnes entourées de guillemets (").

---

mais d'un pb de délimiteur de fin de ligne qu'il serait bien de pouvoir AUSSI paramétrer dans un INPUT DATA.

Je suis d'accord, ça serait bien plus simple si cette option était disponible.

[robi]

Merci... mais malheureusement NON, je n'ai pas la main sur le fichier en entrée générée par une application.
Je ne peux donc pas quoter/protéger des données.

[robi · Accepted solution]

Je suis finalement passé par l'input data de type .flat.

Dans lequel on peut préciser son fin de ligne que j'ai fixé à CRLF afin que le LF n'interfère pas comme délimiteur d'enregistrements.

[robi]

Je reviens sur le sujet... car j'ai un fichier avec des enregistrements sont la longueur est supérieure à 6500 caractères

Je rappelle ma PROBLEMATIQUE :

LECTURE d'un fichier texte, longueur d'enregistrement : 13000 caractères avec délimiteurs LF, certains enregistrement contiennent CR.

LF = LINE FEED = chr(10)
CR = CARRIAGE RETURN = chr(13)

Solution 1 : Input data format csv
Problème car les CR sont interprétés à tort, comme des séparateurs d'enregistrements

Solution 2 : Input data format Flat :

Je peux déterminer le délimiteur de ligne à LF MAIS je suis limité à 6500 car (limite champ texte) et l'enregistrement fait plus de 6500 caractères. Donc problème de données perdues car enregistrement "coupé.

Je suis étonné qu'Alteryx ne sache pas faire 'en natif' cette lecture relativement simple...

MERCI ++ pour une solution