Discussion :

[nagadscar]

Salut à tous ! (ou re pour certains ^^)

Voilà, j'ai un petit soucis : j'ai un fichier .csv.

Je veux lire ligne par ligne mais quand j'utilise "fLitLigne" ca me lit tout le contenu du fichier (je suppose donc qu'en csv la fin de ligne n'est pas le RC).

Quelqu'un peu-il me donner un coup de main? (on peut lire jusqu'à tel caractère sans avoir de taille fixe ? quel est ce $*$^ù*^! de caractère ? ^^)

merci d'avance !

[Jannus]

Je n'ai pas connaissance d'un problème pour lire un .csv avec la fonction fLitLigne()
Par contre, tu peux assez facilement trouver le(s) caractère(s) de fin de ligne.
Il suffit lire un bloc d'une taille suppérieure à la première ligne de ton fichier, de parcourir le bloc ainsi obtenu en affichant le caractère et son code ASCII.
Cela te donnera la solution

[nagadscar]

ah oui pas bête


bah écoute je sais pas, mais quand j'ouvre avec notepad => une seule ligne, et avec windev => idem

dans ma boucle, ça s'arrête quand ça trouve l'EOF (mais c'est fin de fichier ca je crois) et ça ça marche.

ça m'embête un peu car je ne vois pas pourquoi ça fait ça >_< (flitligne s'arrête uniquement à RC ? c'est con =/)

[Jannus]

Je confirme, aucun problème pour lire un .CSV avec fLitLigne, je viens de tester avec le code de l'assistant fouvre.

Poste ton code, tu as peut-être une erreur ?

[nagadscar]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
UneLigne =  fLitLigne(nFichier_ref)  
 
		UneLigne = fLitLigne(nFichier_ref)  
		TANTQUE UneLigne <> EOT
			S1.chp1 = ExtraitChaîne(UneLigne, 1, ",")
			S1.chp2 = ExtraitChaîne(UneLigne, 2, ",")
			S1.chp3 = ExtraitChaîne(UneLigne, 3, ",")
			S1.chp4 = ExtraitChaîne(UneLigne, 4, ",")
			S1.chp5 = ExtraitChaîne(UneLigne, 5, ",")
			S1.chp6 = ExtraitChaîne(UneLigne, 6, ",")
			S1.chp7 = ExtraitChaîne(UneLigne, 7, ",")
			S1.chp8 = ExtraitChaîne(UneLigne, 8, ",")
			TableAjouteLigne(TABLE_Contenu,S1.chp1,S1.chp2,S1.chp3,S1.chp4,S1.chp5,S1.chp6,S1.chp7,S1.chp8) 
			UneLigne = fLitLigne(nFichier_ref)       
		FIN
		fFerme(nFichier_ref)

Je lis une ligne au départ car elle m'intéresse pas ^^

[nagadscar]

ah, et tu peux me donner un code windev pour lire le caractère ascii ? ^^

je suis débutant sous windev donc bon ...

[ErwanA]

Je suppose que ce fichier vient d'un système UNIX ou la fin de ligne n'est CARACT(13)+CARACT(10) mais juste CARACT(10).

A cause de ça, le Notepad ne voit pas la fin de ligne ni Windev qui cherche sont RC.

Tu peux donc lire tout ton fichier et faire des extraitchaine sur le caract(10) pour récupère chaque ligne.


EDIT : "Tu n'est pas assez rapide petit scarabé."

[Raptor92]

Bonjour,

Je fais peut être une erreur, mais il me semble que le séparateur d'un fichier csv soit un ";" et non pas une virgule.

Bonne après midi.

PS: Et content de vous lire à nouveau Guardian.

[Bowen]

Le problème est très simple en fait : Le caractère de retour à la ligne utilisé par FLitLigne(), c'est RC c'est à dire CR+LF : (ou Caract(13)+Caract(10) ou retour chariot+Ligne suivante)
Mais dans ton fichier, seul l'un des deux est présent.
Il faut donc traiter ton fichier différemment.
Soit tu l'enregistres avec les Caract(13)+Caract(10), soit tu travailles ta chaine comme un tableau de chaines, séparés par un Caract(13) ou un Caract(10).

[Jannus]

Sans préjuger de ce que dit ErwanA, je ne connais pas Unix, je pense que tu as mal posé ton problème qui n'est pas de lire ligne par ligne mais d'attribuer les données à une table.

Donc un premier test serait de tracer ta ligne après lecture avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Trace(UneLigne)

Pour confirmer mon impression, il semblerait, d'après ce que tu nous dis, que la lecture de la première ligne se passe bien. Si c'est le cas, aucune raison que le reste se passe mal

Je te conseille également de revoir tes fonctions de gestion de chaîne de caractères parce que ta découpe n'est vraiment pas des plus pertinente

[nagadscar]

merci erwana !!

ah, et non, le séparateur est bien une "," pour moi =)

[Bowen]

Je fais peut être une erreur, mais il me semble que le séparateur d'un fichier csv soit un ";" et non pas une virgule.

Pour info, CSV à l'origine, c'est Coma Separated Values, en français Valeurs Séparées par une Virgule. C'était donc bien une virgule qui séparait les colonnes à l'origine, mais on conserve le nom CSV pour tous les fichiers de ce type, et l'un des séparateurs les plus répandus est le ;
Par contre, dans le post précédent, ErwanA parlait du séparateur de lignes.
Les séparateurs de lignes étaient eux différents selon les systèmes d'exploitation, CR+LF sous Windows, CR sous unix / mac (de mémoire, corrigez moi si j'ai dit une bêtise grosse comme moi !).

[Tober]

Une question con mais qui n'a pas encore était posée :
Es-tu sur que ton fichier CSV fasse plus d'une ou deux ligne ?

[ErwanA]

je ne connais pas Unix

Ben... Comment on peux avoir un tel avatar (Un Tux, mascotte Linux (selon Wikipedia), avalant Windows) et ne pas connaitre les système Unix ???


Pour info, la plupart des FTP sont hebergé sur des système Unix.
Ce qui fait que si vous avez un fichier Texte avec des retour chariot sous Windows, que vous uploadez ce fichier sur un FTP en mode ASCII, le client ou serveur FTP va remplacer ces RC Windows en RC Unix.
Ensuite, vous télécharger ce même fichier mais en mode Binary (c'est-à-dire sans conversion de RC) et là, votre fichier se retrouvera avec le Caract(10) comme séparateur de ligne.
Ce qui fait que la taille en octet de ce 2e fichier sera moindre que le fichier originel (1 octet de moins par ligne).

[Jannus]

Ben... Comment on peux avoir un tel avatar (Un Tux, mascotte Linux (selon Wikipedia), avalant Windows) et ne pas connaitre les système Unix ???

Parce que c'est juste un avatar
Tu dis un Tux qui avale un logo Windows, mais ça peut aussi être un logo Windows qui reste sur l'estomac d'un Tux

Si tu veux lui trouver une signification, ça ne peut être que le signe d'une certaine ouverture d'esprit. Je n'ai aucun à priori concernant les OS et j'essaye de ne parler que de chose que je connais (ou pense connaître ).

Sinon, il faut peut-être aussi s'entendre sur ce que signifie "connaître"

[Raptor92]

Bonsoir Bowen,

Pour info, CSV à l'origine, c'est Coma Separated Values, en français Valeurs Séparées par une Virgule. C'était donc bien une virgule qui séparait les colonnes à l'origine, mais on conserve le nom CSV pour tous les fichiers de ce type, et l'un des séparateurs les plus répandus est le ;
Par contre, dans le post précédent, ErwanA parlait du séparateur de lignes.
Les séparateurs de lignes étaient eux différents selon les systèmes d'exploitation, CR+LF sous Windows, CR sous unix / mac (de mémoire, corrigez moi si j'ai dit une bêtise grosse comme moi !).

Il ne serait être question de contrer de tels arguments, néanmoins, je me permettrais une nouvelle question:

Comment ce fait il que les fichiers csv qu'il m'arrive de manipuler utilisent comme séparateurs des ";" ?

Ceci dit, nagadscar pourrait il nous confirmer le séparateur présent dans son fichier ?

[klbsjpolp]

Comment ce fait il que les fichiers csv qu'il m'arrive de manipuler utilisent comme séparateurs des ";" ?

Ça c'est de la faute à Excel. Puisque le séparateur décimal est une virgule en français, il utilise le point-virgule comme séparateur. En anglais, c'est la virgule puisque le séparateur est un point. Plutôt que de créer un standard entre les langues, ils ont créé des séparateurs différents.

C'est un problème très courant ici puisque les deux langues sont souvent utilisées dans la même entreprise et les installation d'Office ne se comprennent pas mutuellement. Le seul séparateur efficace la plupart du temps, c'est le TAB.

Par contre, je ne vois pas l'intérêt de connaitre son séparateur de champ puisque le problème vient du séparateur de ligne.

[gancau]

Bonjour
J'arrive un peu tard, j'utilise beaucoup de fichier csv qui viennent effectivement d'excel et qui ont comme séparateur un ;, mais en gros, le plus important est de connaître le séparateur et peu importe le caractère.
Pour connaître le séparateur de ligne il faudrait que le fichier soit ouvert avec un éditeur de texte du style ultraedit, vi, ... et voir le séparateur en mode hexa.
Il se peut tout simplement que le fichier n'aiut pas de séparateur mais qu'i soit taille de ligne fixe auquel cas flitligne ne sert à rien mais il faut faire un flit(ligne, tailleLigne)
Il faudrait d'abord étudier le fichier avant de commencer le dév

Gancau

[mogwai162]

Euh... Je vais peut être répondre a coté mais si ça peut permettre d'avoir un fichier correct en entrée... on ne sait jamais :

Les seules fois ou j'ai eu un tel fichier c'est parce que j'ai fait un ftp d'un fichier texte depuis unix vers un windows en mode binaire. c'est pas ton cas par hasard ? si oui refais ton ftp en mode ascii et tu n'auras plus de problème de séparateur de ligne.

Sinon, Tu peux toujours charger ton fichier en une fois dans une variable texte, remplacer les caract(10) par des RC. et ensuite faire un pour tout sur cette variable.

[nagadscar]

Pour info, la plupart des FTP sont hebergé sur des système Unix.
Ce qui fait que si vous avez un fichier Texte avec des retour chariot sous Windows, que vous uploadez ce fichier sur un FTP en mode ASCII, le client ou serveur FTP va remplacer ces RC Windows en RC Unix.
Ensuite, vous télécharger ce même fichier mais en mode Binary (c'est-à-dire sans conversion de RC) et là, votre fichier se retrouvera avec le Caract(10) comme séparateur de ligne.
Ce qui fait que la taille en octet de ce 2e fichier sera moindre que le fichier originel (1 octet de moins par ligne).

plusieurs personnes avaient tourné autour de ça donc voilà ma réponse :

Le serveur ftp est sous windows, les fichier sont générés sous vax et je les récupère au format .zip donc ils ne connaissent pas de modifications.

Ma solution à été de chercher le caractère (10 || 13) et ca passe =)


merci pour votre aide !
cdlt,
naga