Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic Problème FTP avec Inet

Problème FTP avec Inet

6 réponses
Avatar
Christian
Bonjour,

J'ai dans mon programme une connexion FTP pour récupérer un fichier texte
qui sert à mettre à jour une base de données. Donc, les données des
différentes tables sont enregistrées sur une ligne séparées par des points
virgules. La récupération du fichier se passe correctement.

Le problème se trouve sur le contenu du fichier qui est complètement changé
par rapport à l'original. Du coup il ne me sert à rien.

J'utilise le contrôle Inet. Est-ce un problème qui lui est propre ? En
passant par FileZilla, il me le restitue correctement. Cela provient donc
d'un truc au niveau d'Inet, une commande que je ne connais pas ? Une façon
de faire ?

Je fais
Inet.execute "GET monfichier.txt c:\monfichier.txt"

Christian.
Signaler un problème avec ce contenu

6 réponses

Supprimer
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
Avatar
Pierre-R
Voici le code que j'utilise pour me vérifier si il y une mis a jours
si tu as des question gènes toi pas

Dim taille, pourcent As Integer
Dim fic_source, fic_destination As String

On Error GoTo ErrorHandler

CmdUpdate.Visible = False

fic_source = "version.txt"
'Fichier a telecharger.
fic_destination = "C:version.text" 'Fichier
de destination.

With Inet1
.Protocol = icFTP
'Declaration protocole.
.URL = "ftp://monFTP.org" '"ftp://user:" 'le ftp.
.UserName = "MonUsers"
.Password = "99999"
End With

LblInfo.Caption = "Connexion en cour..."

Inet1.Execute , "SIZE " & fic_source 'Demande
la taille du fichier a telecharger.

Do Until Inet1.StillExecuting = False 'Boucle
pendant le traitement de inet.
DoEvents
Loop

taille = Inet1.GetChunk(1024)
'Recuperation de la taille dans taille.

pb.Value = 0
'Definition de la valeur minimum.
pb.Max = taille
'Definition de la valeur maximum.

Inet1.Execute , "get " & fic_source & " " & fic_destination
'Telechargement du fichier

Do Until Inet1.StillExecuting = False 'Boucle
pendant le traitement de inet

On Error Resume Next
DoEvents
pb.Value = FileLen(fic_destination) 'Mise a
jour de la valeur de la progressbar PB
pourcent = (pb.Value / taille) * 100 'Calcul
du pourcentage reçu

Label1.Caption = pourcent & "%"
'Affichage du % du telechargement

Loop

If pourcent = "100" Then
LblInfo.Caption = "Recherche des mis-à-jours..."

Inet1.Execute , "close "
Call FindUpdate
End If

Exit Sub


ErrorHandler:

Resume Next
"Christian" a écrit dans le message de news:
450821d1$0$1774$
Bonjour,

J'ai dans mon programme une connexion FTP pour récupérer un fichier texte
qui sert à mettre à jour une base de données. Donc, les données des
différentes tables sont enregistrées sur une ligne séparées par des points
virgules. La récupération du fichier se passe correctement.

Le problème se trouve sur le contenu du fichier qui est complètement
changé
par rapport à l'original. Du coup il ne me sert à rien.

J'utilise le contrôle Inet. Est-ce un problème qui lui est propre ? En
passant par FileZilla, il me le restitue correctement. Cela provient donc
d'un truc au niveau d'Inet, une commande que je ne connais pas ? Une façon
de faire ?

Je fais
Inet.execute "GET monfichier.txt c:monfichier.txt"

Christian.





Avatar
Christian
Merci pour la réponse.

Même si je n'y croyais pas trop j'ai tout de même tenté le coup.
Effectivement cela ne marche pas mieux.
Je refais mon explication. J'arrive à importer le fichier se trouvant sur le
serveur FTP. Par contre le contenu n'est plus au même format.

Dans l'original, le fichier est formaté avec des retours de ligne comme ça :
Ligne1
Ligne2
etc.
Le fichier restitué (après la récupération par Inet) donne ça :
Ligne1 Ligne2 Ligne3 etc.
d'où l'obligation de le retraité en le parsant.

Pourtant avec le client FTP (FileZilla) je ne rencontre pas ce problème.

Christian.

"Pierre-R" <moldry(supprimer)@hotmail.com> a écrit dans le message de news:

Voici le code que j'utilise pour me vérifier si il y une mis a jours
si tu as des question gènes toi pas

Dim taille, pourcent As Integer
Dim fic_source, fic_destination As String

On Error GoTo ErrorHandler

CmdUpdate.Visible = False

fic_source = "version.txt"
'Fichier a telecharger.
fic_destination = "C:version.text"


'Fichier
de destination.

With Inet1
.Protocol = icFTP
'Declaration protocole.
.URL = "ftp://monFTP.org" '"ftp://user:" 'le ftp.
.UserName = "MonUsers"
.Password = "99999"
End With

LblInfo.Caption = "Connexion en cour..."

Inet1.Execute , "SIZE " & fic_source


'Demande
la taille du fichier a telecharger.

Do Until Inet1.StillExecuting = False


'Boucle
pendant le traitement de inet.
DoEvents
Loop

taille = Inet1.GetChunk(1024)
'Recuperation de la taille dans taille.

pb.Value = 0
'Definition de la valeur minimum.
pb.Max = taille
'Definition de la valeur maximum.

Inet1.Execute , "get " & fic_source & " " & fic_destination
'Telechargement du fichier

Do Until Inet1.StillExecuting = False


'Boucle
pendant le traitement de inet

On Error Resume Next
DoEvents
pb.Value = FileLen(fic_destination) 'Mise


a
jour de la valeur de la progressbar PB
pourcent = (pb.Value / taille) * 100


'Calcul
du pourcentage reçu

Label1.Caption = pourcent & "%"
'Affichage du % du telechargement

Loop

If pourcent = "100" Then
LblInfo.Caption = "Recherche des mis-à-jours..."

Inet1.Execute , "close "
Call FindUpdate
End If

Exit Sub


ErrorHandler:

Resume Next
"Christian" a écrit dans le message de news:
450821d1$0$1774$
> Bonjour,
>
> J'ai dans mon programme une connexion FTP pour récupérer un fichier


texte
> qui sert à mettre à jour une base de données. Donc, les données des
> différentes tables sont enregistrées sur une ligne séparées par des


points
> virgules. La récupération du fichier se passe correctement.
>
> Le problème se trouve sur le contenu du fichier qui est complètement
> changé
> par rapport à l'original. Du coup il ne me sert à rien.
>
> J'utilise le contrôle Inet. Est-ce un problème qui lui est propre ? En
> passant par FileZilla, il me le restitue correctement. Cela provient


donc
> d'un truc au niveau d'Inet, une commande que je ne connais pas ? Une


façon
> de faire ?
>
> Je fais
> Inet.execute "GET monfichier.txt c:monfichier.txt"
>
> Christian.
>
>
>




Avatar
Vincent Guichard
Christian a écrit :
Merci pour la réponse.

Même si je n'y croyais pas trop j'ai tout de même tenté le coup.
Effectivement cela ne marche pas mieux.
Je refais mon explication. J'arrive à importer le fichier se trouvant sur le
serveur FTP. Par contre le contenu n'est plus au même format.

Dans l'original, le fichier est formaté avec des retours de ligne comme ça :
Ligne1
Ligne2
etc.
Le fichier restitué (après la récupération par Inet) donne ça :
Ligne1 Ligne2 Ligne3 etc.
d'où l'obligation de le retraité en le parsant.

Pourtant avec le client FTP (FileZilla) je ne rencontre pas ce problème.

Christian.




Probablement un problème de transfert ASCII des fichiers texte. Sur les
serveurs UNIX, les fichiers textes sont stockés avec <CR> comme
séparateur de fin de ligne, alors que c'est <CR><LF> pour les divers
Windows.

Filezilla est capable de faire la transformation au vol, et probablement
INET aussi (ou alors tu peux faire la modification toi même, en
remplacant tous les <CR> par des <CR><LF>).

Vincent Guichard
Avatar
Christian
"Vincent Guichard" a écrit dans le message de
news: 450a6fac$0$27375$
Christian a écrit :
> Merci pour la réponse.
>
> Même si je n'y croyais pas trop j'ai tout de même tenté le coup.
> Effectivement cela ne marche pas mieux.
> Je refais mon explication. J'arrive à importer le fichier se trouvant


sur le
> serveur FTP. Par contre le contenu n'est plus au même format.
>
> Dans l'original, le fichier est formaté avec des retours de ligne comme


ça :
> Ligne1
> Ligne2
> etc.
> Le fichier restitué (après la récupération par Inet) donne ça :
> Ligne1 Ligne2 Ligne3 etc.
> d'où l'obligation de le retraité en le parsant.
>
> Pourtant avec le client FTP (FileZilla) je ne rencontre pas ce problème.
>
> Christian.
>

Probablement un problème de transfert ASCII des fichiers texte. Sur les
serveurs UNIX, les fichiers textes sont stockés avec <CR> comme
séparateur de fin de ligne, alors que c'est <CR><LF> pour les divers
Windows.

Filezilla est capable de faire la transformation au vol, et probablement
INET aussi (ou alors tu peux faire la modification toi même, en
remplacant tous les <CR> par des <CR><LF>).

Vincent Guichard



Bonjour,

Meric de répondre. C'est ce que je me suis dit et du coup je récupère le
fichier (genre fihcier tempo) puis récupère son contenu pour ensuite le
re-écrire avec des sauts de lignes (comme je les veux) et efface le fichier
tempo.
Mais comment fait filezilla pour justement détecter ce genre d'ennui et
réaliser ce traitement "en vol". Existe t-il une commande d'identification
du serveur ?
De plus en quoi consisterait - il ? Il chope le contenu (façon EDIT) pour
ensuite le re-écrire dans le fichier de destination ? Mais pour ça il lui
faut reconnaître s'il s'agit d'un serveur UNIX ou IIS ?

Le caractère <CHR(10)> correspond au <CR> dans ce cas il suffit de voir à
quoi correspond <CRLF>, CHR(13) ?


Christian.
Avatar
Jean-marc
"Christian" a écrit dans le message de news:
450ba403$0$28599$

"Vincent Guichard" a écrit dans le message de
news: 450a6fac$0$27375$
Christian a écrit :
> Merci pour la réponse.
>
> Même si je n'y croyais pas trop j'ai tout de même tenté le coup.
> Effectivement cela ne marche pas mieux.
> Je refais mon explication. J'arrive à importer le fichier se trouvant


sur le
> serveur FTP. Par contre le contenu n'est plus au même format.
>
> Dans l'original, le fichier est formaté avec des retours de ligne comme


ça :
> Ligne1
> Ligne2
> etc.
> Le fichier restitué (après la récupération par Inet) donne ça :
> Ligne1 Ligne2 Ligne3 etc.
> d'où l'obligation de le retraité en le parsant.
>
> Pourtant avec le client FTP (FileZilla) je ne rencontre pas ce
> problème.
>
> Christian.
>

Probablement un problème de transfert ASCII des fichiers texte. Sur les
serveurs UNIX, les fichiers textes sont stockés avec <CR> comme
séparateur de fin de ligne, alors que c'est <CR><LF> pour les divers
Windows.

Filezilla est capable de faire la transformation au vol, et probablement
INET aussi (ou alors tu peux faire la modification toi même, en
remplacant tous les <CR> par des <CR><LF>).

Vincent Guichard



Bonjour,

Meric de répondre. C'est ce que je me suis dit et du coup je récupère le
fichier (genre fihcier tempo) puis récupère son contenu pour ensuite le
re-écrire avec des sauts de lignes (comme je les veux) et efface le
fichier
tempo.
Mais comment fait filezilla pour justement détecter ce genre d'ennui et
réaliser ce traitement "en vol". Existe t-il une commande d'identification
du serveur ?
De plus en quoi consisterait - il ? Il chope le contenu (façon EDIT) pour
ensuite le re-écrire dans le fichier de destination ? Mais pour ça il lui
faut reconnaître s'il s'agit d'un serveur UNIX ou IIS ?



Bonjour,

voici qq explications:

dans le protocole FTP, il existe 2 commandes, respectivement:
ASCII et BINARY. Ces commandes permettent de spécifier au serveur
la nature du fichier à transférer. Si on demande un transfert binaire,
le serveur doit envoyé les donnés "brutes", bytes par bytes.
Si on spécifie ASCII, le protocole garanti une conversion correcte
de la séquence "NEWLINE".

La conversion se passe comme ça:
le serveur convetit de son encodage vers un encodage neutre
le client convertit l'encodage neutre vers son encodage.

Ainsi:
Sous Windows, c'esst CRLF
Sous Unix, le passage à la ligne est un simple LF.
Sous Mac et sous VMS (OS des VAX), c'est un simple CR
Sous z/OS (le système des mainframe IBM), c'est le caractère 0x25 du jeu de
caractère EBCDIC.

Mais ce n'est pas grave car le protocole FTP garanti que si on spécifie
ASCII, le transfert
sera effectué correctement, avec les adaptations/conversions idoines des
séquences NewLine.

Voir à ce sujet la section 3.1.1.1 de la RFC FTP:
http://abcdrfc.free.fr/rfc-vf/rfc959.html

A noter que si on ne dit rien au serveur, par défaut le mode est ASCII (pour
FTP).
Pour les clients, c'est en revanche souvent binaire par défaut.

Dans le cas de fileZilla, il est possible que:
- Par défaut il effectue les transferts en Ascii
- Que en fonction de l'extension du fichier, il choisisse le mode qui lui
semble le mieux convenir
- Qu'en fonction des entêtes des fichiers, il sache reconnaitre si il s'agit
dun binaire ou de texte

On peut imaginer 20.000 stratégies possibles.


--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Christian
"Jean-marc" a écrit dans le message
de news: 450bb165$0$1217$
"Christian" a écrit dans le message de news:
450ba403$0$28599$
>
> "Vincent Guichard" a écrit dans le message


de
> news: 450a6fac$0$27375$
>> Christian a écrit :
>> > Merci pour la réponse.
>> >
>> > Même si je n'y croyais pas trop j'ai tout de même tenté le coup.
>> > Effectivement cela ne marche pas mieux.
>> > Je refais mon explication. J'arrive à importer le fichier se trouvant
> sur le
>> > serveur FTP. Par contre le contenu n'est plus au même format.
>> >
>> > Dans l'original, le fichier est formaté avec des retours de ligne


comme
> ça :
>> > Ligne1
>> > Ligne2
>> > etc.
>> > Le fichier restitué (après la récupération par Inet) donne ça :
>> > Ligne1 Ligne2 Ligne3 etc.
>> > d'où l'obligation de le retraité en le parsant.
>> >
>> > Pourtant avec le client FTP (FileZilla) je ne rencontre pas ce
>> > problème.
>> >
>> > Christian.
>> >
>>
>> Probablement un problème de transfert ASCII des fichiers texte. Sur les
>> serveurs UNIX, les fichiers textes sont stockés avec <CR> comme
>> séparateur de fin de ligne, alors que c'est <CR><LF> pour les divers
>> Windows.
>>
>> Filezilla est capable de faire la transformation au vol, et


probablement
>> INET aussi (ou alors tu peux faire la modification toi même, en
>> remplacant tous les <CR> par des <CR><LF>).
>>
>> Vincent Guichard
>
> Bonjour,
>
> Meric de répondre. C'est ce que je me suis dit et du coup je récupère le
> fichier (genre fihcier tempo) puis récupère son contenu pour ensuite le
> re-écrire avec des sauts de lignes (comme je les veux) et efface le
> fichier
> tempo.
> Mais comment fait filezilla pour justement détecter ce genre d'ennui et
> réaliser ce traitement "en vol". Existe t-il une commande


d'identification
> du serveur ?
> De plus en quoi consisterait - il ? Il chope le contenu (façon EDIT)


pour
> ensuite le re-écrire dans le fichier de destination ? Mais pour ça il


lui
> faut reconnaître s'il s'agit d'un serveur UNIX ou IIS ?

Bonjour,

voici qq explications:

dans le protocole FTP, il existe 2 commandes, respectivement:
ASCII et BINARY. Ces commandes permettent de spécifier au serveur
la nature du fichier à transférer. Si on demande un transfert binaire,
le serveur doit envoyé les donnés "brutes", bytes par bytes.
Si on spécifie ASCII, le protocole garanti une conversion correcte
de la séquence "NEWLINE".

La conversion se passe comme ça:
le serveur convetit de son encodage vers un encodage neutre
le client convertit l'encodage neutre vers son encodage.

Ainsi:
Sous Windows, c'esst CRLF
Sous Unix, le passage à la ligne est un simple LF.
Sous Mac et sous VMS (OS des VAX), c'est un simple CR
Sous z/OS (le système des mainframe IBM), c'est le caractère 0x25 du jeu


de
caractère EBCDIC.

Mais ce n'est pas grave car le protocole FTP garanti que si on spécifie
ASCII, le transfert
sera effectué correctement, avec les adaptations/conversions idoines des
séquences NewLine.

Voir à ce sujet la section 3.1.1.1 de la RFC FTP:
http://abcdrfc.free.fr/rfc-vf/rfc959.html

A noter que si on ne dit rien au serveur, par défaut le mode est ASCII


(pour
FTP).
Pour les clients, c'est en revanche souvent binaire par défaut.

Dans le cas de fileZilla, il est possible que:
- Par défaut il effectue les transferts en Ascii
- Que en fonction de l'extension du fichier, il choisisse le mode qui lui
semble le mieux convenir
- Qu'en fonction des entêtes des fichiers, il sache reconnaitre si il


s'agit
dun binaire ou de texte

On peut imaginer 20.000 stratégies possibles.


--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;




Bonjour,

Merci pour cette réponse très complète. En effet en regardant de plus près
les paramètres par défaut de FileZilla, le mode auto est défini par défaut.
En somme il utilise une des stratégies que vous décrivez plus haut. Encore
merci.

Christian.