Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romain PETIT
Louis a utilisé son clavier pour écrire :
Bonjour
j'ai besoin de récupérer quelques colonnes d'un fichier .csv
le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV n'est pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
je ne peux donc pas utiliser FlitLigne... et je dois donc utiliser Hlit en scrutant les caract(13) Il serait donc intéressant de pouvoir passer en paramètre optionnel à la fonction FlitLigne() le code de fin de ligne Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial. Si ton fichier n'est pas énorme, tu le charges en mémoire (fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton séparateur de ligne...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Louis a utilisé son clavier pour écrire :
Bonjour
j'ai besoin de récupérer quelques colonnes d'un fichier .csv
le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV n'est
pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
je ne peux donc pas utiliser FlitLigne...
et je dois donc utiliser Hlit en scrutant les caract(13)
Il serait donc intéressant de pouvoir passer en paramètre optionnel à la
fonction FlitLigne() le code de fin de ligne
Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial.
Si ton fichier n'est pas énorme, tu le charges en mémoire
(fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton
séparateur de ligne...
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
j'ai besoin de récupérer quelques colonnes d'un fichier .csv
le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV n'est pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
je ne peux donc pas utiliser FlitLigne... et je dois donc utiliser Hlit en scrutant les caract(13) Il serait donc intéressant de pouvoir passer en paramètre optionnel à la fonction FlitLigne() le code de fin de ligne Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial. Si ton fichier n'est pas énorme, tu le charges en mémoire (fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton séparateur de ligne...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Louis
Bonjour Romain et merci
mon fichier fait 4Mo...
je ne saisi pas trop la finalité des caractère de fin de ligne des CSV...
j'ai parfois 13 parfois 10 ?
à suivre
merci
"Romain PETIT" a écrit dans le message de news:
Louis a utilisé son clavier pour écrire : > Bonjour > > > j'ai besoin de récupérer quelques colonnes d'un fichier .csv > > > le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV
n'est
> pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
> je ne peux donc pas utiliser FlitLigne... > et je dois donc utiliser Hlit en scrutant les caract(13) > Il serait donc intéressant de pouvoir passer en paramètre optionnel à la > fonction FlitLigne() le code de fin de ligne > Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial. Si ton fichier n'est pas énorme, tu le charges en mémoire (fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton séparateur de ligne...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Bonjour Romain
et merci
mon fichier fait 4Mo...
je ne saisi pas trop la finalité des caractère de fin de ligne des CSV...
j'ai parfois 13 parfois 10 ?
à suivre
merci
"Romain PETIT" <VoirM@Signature.fin> a écrit dans le message de
news:mn.83137d478d8ed914.2248@Signature.fin...
Louis a utilisé son clavier pour écrire :
> Bonjour
>
>
> j'ai besoin de récupérer quelques colonnes d'un fichier .csv
>
>
> le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV
n'est
> pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
> je ne peux donc pas utiliser FlitLigne...
> et je dois donc utiliser Hlit en scrutant les caract(13)
> Il serait donc intéressant de pouvoir passer en paramètre optionnel à la
> fonction FlitLigne() le code de fin de ligne
> Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial.
Si ton fichier n'est pas énorme, tu le charges en mémoire
(fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton
séparateur de ligne...
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
je ne saisi pas trop la finalité des caractère de fin de ligne des CSV...
j'ai parfois 13 parfois 10 ?
à suivre
merci
"Romain PETIT" a écrit dans le message de news:
Louis a utilisé son clavier pour écrire : > Bonjour > > > j'ai besoin de récupérer quelques colonnes d'un fichier .csv > > > le problème est que, sauf erreur, la fin de ligne d'un (de mon) CSV
n'est
> pas le RC mais juste char(13)
Certainement un fichier généré par un Mac...
> je ne peux donc pas utiliser FlitLigne... > et je dois donc utiliser Hlit en scrutant les caract(13) > Il serait donc intéressant de pouvoir passer en paramètre optionnel à la > fonction FlitLigne() le code de fin de ligne > Qu'en pensez-vous ?
Pourquoi pas, mais c'est quand même trivial. Si ton fichier n'est pas énorme, tu le charges en mémoire (fChargeTexte) et tu boucles sur des ExtraitChaine() avec ton séparateur de ligne...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
Louis avait soumis l'idée :
Bonjour Romain et merci mon fichier fait 4Mo...
Un peu lourd à priori pour un fChargeTexte mais si c'est une opération ponctuelle ça ne devrait pas poser de problème...
je ne saisi pas trop la finalité des caractère de fin de ligne des CSV... j'ai parfois 13 parfois 10 ?
Cela dépend de l'OS (ou du choix lors de l'enregistrement). Sous Windows, CR+LF (10+13) Sous Mac, CR (10) Sous Unix et consort, LF (13)
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Louis avait soumis l'idée :
Bonjour Romain
et merci
mon fichier fait 4Mo...
Un peu lourd à priori pour un fChargeTexte mais si c'est une opération
ponctuelle ça ne devrait pas poser de problème...
je ne saisi pas trop la finalité des caractère de fin de ligne des CSV...
j'ai parfois 13 parfois 10 ?
Cela dépend de l'OS (ou du choix lors de l'enregistrement).
Sous Windows, CR+LF (10+13)
Sous Mac, CR (10)
Sous Unix et consort, LF (13)
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, Romain PETIT ecrivait (wrote) :
Cela dépend de l'OS (ou du choix lors de l'enregistrement). Sous Windows, CR+LF (10+13) Sous Mac, CR (10) Sous Unix et consort, LF (13)
C'est presque ça :)
Reprenons :
<CR> -> ASCII 13 <LF> -> ASCII 10
Donc :
Sous Windows, CR+LF (13+10) Sous Mac, CR (13) Sous Unix et consort, LF (10)
A noter que par un bizarre effet de bord que je ne m'explique pas, si on envoie un fichier texte en pièce jointe avec OE, les <CR><LF> sont (parfois, pas toujours, c'est du Microsoft, donc de la logique floue) remplacés par des <LF> dans le transport, ce qui met le bronx si on doit les traiter automatiquement à la réception.
Solution : zipper les fichiers qui sont alors encodés puis transportés en binaire (généralement BASE64, parfois UUENCODE), puis dézipper à l'arrivée.
-- Eric
dans (in) fr.comp.developpement.agl.windev, Romain PETIT
<VoirM@Signature.fin> ecrivait (wrote) :
Cela dépend de l'OS (ou du choix lors de l'enregistrement).
Sous Windows, CR+LF (10+13)
Sous Mac, CR (10)
Sous Unix et consort, LF (13)
C'est presque ça :)
Reprenons :
<CR> -> ASCII 13
<LF> -> ASCII 10
Donc :
Sous Windows, CR+LF (13+10)
Sous Mac, CR (13)
Sous Unix et consort, LF (10)
A noter que par un bizarre effet de bord que je ne m'explique pas, si on
envoie un fichier texte en pièce jointe avec OE, les <CR><LF> sont
(parfois, pas toujours, c'est du Microsoft, donc de la logique floue)
remplacés par des <LF> dans le transport, ce qui met le bronx si on doit
les traiter automatiquement à la réception.
Solution : zipper les fichiers qui sont alors encodés puis transportés
en binaire (généralement BASE64, parfois UUENCODE), puis dézipper à
l'arrivée.
dans (in) fr.comp.developpement.agl.windev, Romain PETIT ecrivait (wrote) :
Cela dépend de l'OS (ou du choix lors de l'enregistrement). Sous Windows, CR+LF (10+13) Sous Mac, CR (10) Sous Unix et consort, LF (13)
C'est presque ça :)
Reprenons :
<CR> -> ASCII 13 <LF> -> ASCII 10
Donc :
Sous Windows, CR+LF (13+10) Sous Mac, CR (13) Sous Unix et consort, LF (10)
A noter que par un bizarre effet de bord que je ne m'explique pas, si on envoie un fichier texte en pièce jointe avec OE, les <CR><LF> sont (parfois, pas toujours, c'est du Microsoft, donc de la logique floue) remplacés par des <LF> dans le transport, ce qui met le bronx si on doit les traiter automatiquement à la réception.
Solution : zipper les fichiers qui sont alors encodés puis transportés en binaire (généralement BASE64, parfois UUENCODE), puis dézipper à l'arrivée.
-- Eric
Romain PETIT
Eric Demeester a présenté l'énoncé suivant :
C'est presque ça :)
Juste pour vérifier que tout le monde suivait... :-)
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Eric Demeester a présenté l'énoncé suivant :
C'est presque ça :)
Juste pour vérifier que tout le monde suivait... :-)
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Juste pour vérifier que tout le monde suivait... :-)
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Eric Demeester
dans (in) fr.comp.developpement.agl.windev, Romain PETIT ecrivait (wrote) :
Bonsoir Romain,
Juste pour vérifier que tout le monde suivait... :-)
Etant tombé dans les fichiers ASCII tout petit, avant que Microsoft n'existe [*] donc, je suis impitoyable en la matière :)
[*] Sisi, l'informatique existait avant M$, de même que l'Internet existait avant Wanadoo, même si on vous raconte le contraire dans les agences France-Telecom.
-- Eric
dans (in) fr.comp.developpement.agl.windev, Romain PETIT
<VoirM@Signature.fin> ecrivait (wrote) :
Bonsoir Romain,
Juste pour vérifier que tout le monde suivait... :-)
Etant tombé dans les fichiers ASCII tout petit, avant que Microsoft
n'existe [*] donc, je suis impitoyable en la matière :)
[*] Sisi, l'informatique existait avant M$, de même que l'Internet
existait avant Wanadoo, même si on vous raconte le contraire dans
les agences France-Telecom.
dans (in) fr.comp.developpement.agl.windev, Romain PETIT ecrivait (wrote) :
Bonsoir Romain,
Juste pour vérifier que tout le monde suivait... :-)
Etant tombé dans les fichiers ASCII tout petit, avant que Microsoft n'existe [*] donc, je suis impitoyable en la matière :)
[*] Sisi, l'informatique existait avant M$, de même que l'Internet existait avant Wanadoo, même si on vous raconte le contraire dans les agences France-Telecom.
