[E-00] format CSV

Bonjour!

je vais continuer avec mes questions d'amateur...désolé.

Ma situation est la suivante: j'ai un programme qui sauve des données dans un fichier CSV. Jusqu'à maintenant, j'utilisait un ";" comme séparateur pour pouvoir l'ouvrir avec excel.

Jusque la, tout roule.

Maintenant j'ai fait une petite macro - domaine dans lequel je débute- qui ouvre le csv, copie son contenu et le mets dans un xsl. Pour pouvoir faire ca, étant donné ma version vetuste d'office et, d'après ce que j'ai pu lire sur le net, une problématique de "régionalité", il faut que le séparateur soit une virgule à présent. Je modifie mon csv et ca marche, mais, résultat, je peux plus ouvrir "benoitement" mon csv en double cliquant dessus.

Est-ce que quelqu'un connaitrait une solution à tout ca? (en tenant compte du fait que la macro doit pas etre dépendante de problèmes de régions, etc. (doit pouvoir etre executée aussi bien aux US qu'en Europe...))

Merci d'avance :D

bonjour

pour ouvrir ton fichier csv utilise :

Code:

---

1 2	Workbooks.Open Filename:= _ Chemin & "\" & Fichier_à_Analyser, local:=True

---

consulte l'aide VBA sur Open, méthode :

Code:

---

Local Argument de type Variant facultatif. La valeur True enregistre les fichiers en fonction de la langue de Microsoft Excel (y compris les paramètres du Panneau de configuration). La valeur False (valeur par défaut) enregistre les fichiers en fonction de la langue de Visual Basic pour Applications (VBA) (qui est généralement l'anglais des États-Unis, sauf si le projet VBA où Workbooks.Open est exécuté est un ancien projet VBA XL5/95 de niveau international).

---

à plus

Hello,

merci pour ta réponse. D'après c'que j'ai vu, Local:=True n'existe qu'à partir de la version 02 et comme précisé dans l'intitulé de mon post, j'ai la version 2000...

mes infos sont peut etre mauvaises, je vais revérifier.

[Edit] C'est testé et effectivement Local n'est pas accepté

J'ai une fois de plus pas été suffisemment explicite ou alors il n'y a pas de solution à mon problème?

bonjour,

je ne connais pas bien excel 2000 et je ne suit pas expert dans les macros mais personnellement j'ai résolu ce problème en passant par un import de donnée externe

ci joint un bout de code que j'utilisait pour faire un import de fichier .csv dont le séparateur était un |

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Set feuille = ActiveWorkbook.Sheets(1)   feuille.Activate   With ActiveSheet.QueryTables.Add(Connection:= _ "TEXT; 'chemin du fichier à importer " _ , Destination:=Range("A1")) .TextFileOtherDelimiter = "," .Refresh BackgroundQuery:=False End With End Sub

---

j'espère que cela pourra t'aider

QueryTables est parfois capricieux ceci dit, j'ai parfois eu de mauvaises surprises avec. Eventuellement tu peux l'ouvrir "brut" en colonne A et le convertir après coup, une fois le séparateur identifié.

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

Dim monFichier As String, varLigne As String   monFichier = "D:\files\sample.csv"   ActiveSheet.Cells.Select Selection.NumberFormat = "@"   'Etape 1 : on met le csv dans la feuille excel i = 1 Open monFichier For Input As #1 Do While Not EOF(1) Line Input #1, varLigne ActiveSheet.Cells(i, 1) = varLigne i = i + 1 Loop Close #1   'Etape 2, on identifie le séparateur (virgule ou point-virgule ?) et on scinde en fonction If InStr(ActiveSheet.Cells(1, 1), ";") <> 0 Then ActiveSheet.Columns("A:A").Select Selection.TextToColumns Destination:=Range("A1"), DataType:=xlDelimited, _ TextQualifier:=xlNone, ConsecutiveDelimiter:=False, Tab:=False, _ Semicolon:=True, Comma:=False, Space:=False, Other:=False ElseIf InStr(ActiveSheet.Cells(1, 1), ",") <> 0 Then ActiveSheet.Columns("A:A").Select Selection.TextToColumns Destination:=Range("A1"), DataType:=xlDelimited, _ TextQualifier:=xlNone, ConsecutiveDelimiter:=False, Tab:=False, _ Semicolon:=False, Comma:=True, Space:=False, Other:=False Else MsgBox "Erreur : le séparateur n'a pas pu être identifié." End End If

---

Merci deuxmains pour ta réponse! (qui plus est quand on voit que c'est ton premier message du forum!)

j'ai essayé ton bout de code et tout comme toi je suis loin d'etre un as des macros, et j'ai une erreur avec la ligne:

Code:

---

.Refresh BackgroundQuery:=False

---

Saurais-tu m'expliquer ce que c'est sensé faire?

Citation:

---

Nouveau message apparu pendant que j'écrivais le mien

---

Neupon merci également! Je me demandais efffectivement si y'avait moyen de faire du traitement "brut". Juste une petite quesion concernant ton code, le "OR" n'existe pas en VBA ou alors il y a une différence de traitement entre les deux cas "virgule" et "point-virgule" qui m'a echappé?

Je vais tenter tout ca tres bientot! (la c'est un long week-end dont je compte bien profiter :D)

En vous souhaitant une bonne soirée et un excellent week end!
:merci: encore

Salut, regarde si cela peut t'aider,à adapter à ton contexte http://cjoint.com/?eErBKRM8IF

Citation:

---

Envoyé par TheCaribouX

Juste une petite quesion concernant ton code, le "OR" n'existe pas en VBA ou alors il y a une différence de traitement entre les deux cas "virgule" et "point-virgule" qui m'a echappé?

---

Oui il y a une différence, dans un cas tu as :
Semicolon:=True, Comma:=False

et dans l'autre :
Semicolon:=False, Comma:=True

;)

merci pour le compliment TheCaribouX

le Refresh BackgroundQuery est là pour bloquer la procédure tant que l'ensemble des données n'a pas été importé dans ta feuille excel ( les nombreux "meilleurs_que_moi_en_excel" me corrigeront si je dit une bêtise)

Comme le dit si bien neupont: "QueryTables est parfois capricieux " :?

la solution empirique pour résoudre ce type d'erreur est de faire un enregistrement de macro et de faire un import de données externe depuis le menu outils. ainsi tu auras le code VB de ton import et tu pourras faire un copier/coller dans ta procédure et a optimiser le code en fonction de tes besoins :P

le recours a la touche F1 est vivement conseillé et cette méthode m'a permis d'apprendre beaucoup sur les macros

Citation:

---

Envoyé par neupont

Oui il y a une différence, dans un cas tu as :
Semicolon:=True, Comma:=False

et dans l'autre :
Semicolon:=False, Comma:=True

;)

---

Forcément ca prend tout son sens :D

Citation:

---

Envoyé par deuxmains

la solution empirique pour résoudre ce type d'erreur est de faire un enregistrement de macro et de faire un import de données externe depuis le menu outils. ainsi tu auras le code VB de ton import et tu pourras faire un copier/coller dans ta procédure et a optimiser le code en fonction de tes besoins :P

---

Je le fais assez souvent, mais dans le cas présent je crois, si je me rappelle bien, qu'il faisait un bête "open" sans trop d'options.

Merci pour vos réponses, et désolé pour la lenteur de la mienne, je vais tâcher d'essayer vos solutions une fois que j'aurai réellement pris conscience qu'on est effectivement lundi matin et je suis effectivement au travail devant mon écran :P

Ca y'est j'ai eu le temps de tester la "méthode neupont". Ca fonctionne à merveille, le séparateur est bien détécté.

Reste un problème qui n'est pas lié directement au séparateur mais bon, jprofite un peu du post ouvert. Je génère mes fichiers dans un programme en c# en mettant un "\n" à la fin de chaque ligne. Notepad++ le comprend, excel aussi, mais le bloc note affiche un carré ( [] ) et pas de retour à la ligne. Lorsque je scanne le fichier avec le EOF(1) du code à neupont, je n'ai que la premiere ligne qui est traitée.

Le problème est-il connu? (j'utilise certainemetn le mauvais caractère de fin de ligne...)

Citation:

---

Envoyé par TheCaribouX

Reste un problème qui n'est pas lié directement au séparateur mais bon, jprofite un peu du post ouvert. Je génère mes fichiers dans un programme en c# en mettant un "\n" à la fin de chaque ligne. Notepad++ le comprend, excel aussi, mais le bloc note affiche un carré ( [] ) et pas de retour à la ligne. Lorsque je scanne le fichier avec le EOF(1) du code à neupont, je n'ai que la premiere ligne qui est traitée.

Le problème est-il connu? (j'utilise certainemetn le mauvais caractère de fin de ligne...)

---

Ah oui, \n équivaut à un "LF" (code ASCII 10) alors que dans le "monde" DOS/Windows, c'est un CR (code ASCII 13) plus un LF qui sont attendus.
Or si on regarde l'aide sur la commande Line Input on lit : "L'instruction Line Input # lit un à un les caractères d'un fichier jusqu'au premier retour chariot (Chr(13)) ou retour chariot – saut de ligne (Chr(13) + Chr(10)) rencontré."

Donc effectivement le \n n'est pas reconnu par Line Input comme la fin d'une ligne... je veux bien croire que ça pose problème :mouarf:

Alors soit tu peux modifier ton prog en C# en mettant \r\n (de mémoire je crois que c'est ça), soit la macro excel doit réécrire préalablement le fichier csv en remplaçant le LF par CR LF.
Si le fichier CSV n'est pas susceptible d'être traité par un environnement unix (qui lui va préférer le LF seul) et si tu as accès aux sources C# comme ça semble être le cas, il est largement préférable de modifier le programme plutôt que la macro.

oui je pense effectivement modifier le c# (ça me correspond plus :D). Donc en soit le "\r\n" représente un seul caractère? tiens j'aurais pas pensé (j'avais rencontré "ce" caractère dans mon programme si j'me rappelle bien, mais j'avais fait en sorte de l'eliminer :mouarf:)

merci pour tes réponses!

En vba, ça donne ça :

Code:

---

1 2 3 4

Chr(13) => vbcr 'Retour charriot Chr(12) => vblf 'ligne suivante Chr(13) & Chr(12) => Vbcrlf 'retour en début de ligne suivante EOF => End of file

---

Si ça peut ajouter quelque chose à ce que t'a mis Neupont.

Citation:

---

Envoyé par TheCaribouX

oui je pense effectivement modifier le c# (ça me correspond plus :D). Donc en soit le "\r\n" représente un seul caractère? tiens j'aurais pas pensé (j'avais rencontré "ce" caractère dans mon programme si j'me rappelle bien, mais j'avais fait en sorte de l'eliminer :mouarf:)

merci pour tes réponses!

---

Techniquement on ne peut pas dire que ça représente un seul caractère... disons que ça représente 2 octets, un pour le CR (retour charriot) et un pour le LF (retour ligne).
Mais comme ces octets ne sont pas visibles sous forme de caractères, précisément, on voit juste que le texte est passé à la ligne.
Unix fait un retour à la ligne avec un LF simple, les mac avec un CR simple, windows avec CR + LF... Bilou a voulu mettre tout le monde d'accord sans doute ! :mrgreen:

J'aurais dis "se mettre d'accord avec lui-même", c'est ça d'être autosuffisant :lol:

merci ouskelnor pou rle complement d'info! pour le moment je vais tacher de modifier le code qui génpre le csv, mais ca peut toujours etre utile!

Ca fontionne! merci à tous.

j'ai encore un problème, mais ca mérite un nouveau post :D