Discussion :

[NejNej]

Bonjour à tous!
J'ai un petit problème de download avec les caractères spéciaux (accents,& etc...)

je déclare un objet de type webclient et j'utilise la méthode DownLoadFile()
Mais lorsque le fichier contient un caractère spécial il me renvoi l'erreur 404 du fichier introuvable.

Quelqu'un aurait il une explication ???

Merci!

[Philippe Vialatte]

salut,

est-ce que tu as essayé d'encoder tes caractères spéciaux ?

Genre, un coup de HTMLEncode, ou un coup de renommage des & en & ?

[tomlev]

Ce qui pose problème, c'est les caractères spéciaux dans le nom du fichier, je suppose ? (pas dans son contenu)
Dans ce cas il faut utiliser la méthode UrlEncode (et non HtmlEncode) :

Code :

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

1
2
3
4
5
using System.Web; // il faut aussi référencer System.Web.dll
...
string encodedUrl = HttpUtility.UrlEncode(url);
WebClient wc = new WebClient();
wc.DownloadFile(encodedUrl, localFilename);

[Philippe Vialatte]

il faut utiliser la méthode UrlEncode (et non HtmlEncode)

[NejNej]

Merci pour les réponses!

Tomlev j'ai testé ta solution néanmoins j'ai une erreur qui intervient :

"Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de*260*caractères et le nom du répertoire moins de 248*caractères."

Pourtant mon 'encodeUrl' et mon localFileName contiennent moins de 200 caractères!

[tomlev]

"Le chemin d'accès spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de*260*caractères et le nom du répertoire moins de 248*caractères."

Pourtant mon 'encodeUrl' et mon localFileName contiennent moins de 200 caractères!

Tu peux montrer le contenu de ces 2 variables, ou c'est top-secret-défense-confidentiel ?

[stever50]

Ce qui pose problème, c'est les caractères spéciaux dans le nom du fichier, je suppose ? (pas dans son contenu)
Dans ce cas il faut utiliser la méthode UrlEncode (et non HtmlEncode) :

Code :

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

1
2
3
4
5
using System.Web; // il faut aussi référencer System.Web.dll
...
string encodedUrl = HttpUtility.UrlEncode(url);
WebClient wc = new WebClient();
wc.DownloadFile(encodedUrl, localFilename);

Salut,
Désolé de m'initier comme ça mais ta remarque m'interpelle; J'arrive à transférer mes fichiers avec downloadFile mais quand je les récupère et que je veux traiter leurs contenus, tout est écrit sur une seule ligne! Alors que si je les transfère par FileZilla c'est ok.
... et tous les fichiers contiennent après l'extension .txt un cara ";" ...
D'ou ma question : est-ce qu'un cara spécial dans le nom du fichier à transférer peut tout faire foirer?

Si oui, connais-tu la solution ?

Bonne soirée !

[tomlev]

Salut,
Désolé de m'initier comme ça mais ta remarque m'interpelle; J'arrive à transférer mes fichiers avec downloadFile mais quand je les récupère et que je veux traiter leurs contenus, tout est écrit sur une seule ligne! Alors que si je les transfère par FileZilla c'est ok.
... et tous les fichiers contiennent après l'extension .txt un cara ";" ...
D'ou ma question : est-ce qu'un cara spécial dans le nom du fichier à transférer peut tout faire foirer?

Attention de pas tout mélanger... toi tu transfères des données à partir d'un serveur FTP, pas HTTP (enfin je suppose, puisque tu utilises FileZilla). Je sais pas si les règles sur les noms de fichier sont les mêmes qu'en HTTP.

Pour le problème de "tout sur la même ligne" : essaie d'ouvrir le fichier avec WordPad ou quelque chose comme ça, tu verras qu'il y a bien plusieurs lignes ; c'est juste le bloc-note qui ne sait pas les afficher. C'est parce que la séquence de retour à la ligne est différente sous UNIX (\n) et Windows (\r\n). Normalement, quand tu transfères en FTP un fichier texte, tu passes en mode de transfert ASCII, qui gère la conversion des fins de ligne. Mais WebClient.DownloadFile ne permet pas de spécifier le mode de transfert, et par défaut je pense que c'est le mode binaire qui est utilisé. Le fichier est donc transféré tel quel, sans conversion des fins de ligne, d'où le résultat que tu obtiens... Essaie d'utiliser FtpWebRequest à la place de WebClient

[stever50]

Attention de pas tout mélanger... toi tu transfères des données à partir d'un serveur FTP, pas HTTP (enfin je suppose, puisque tu utilises FileZilla). Je sais pas si les règles sur les noms de fichier sont les mêmes qu'en HTTP.

Pour le problème de "tout sur la même ligne" : essaie d'ouvrir le fichier avec WordPad ou quelque chose comme ça, tu verras qu'il y a bien plusieurs lignes ; c'est juste le bloc-note qui ne sait pas les afficher. C'est parce que la séquence de retour à la ligne est différente sous UNIX (\n) et Windows (\r\n). Normalement, quand tu transfères en FTP un fichier texte, tu passes en mode de transfert ASCII, qui gère la conversion des fins de ligne. Mais WebClient.DownloadFile ne permet pas de spécifier le mode de transfert, et par défaut je pense que c'est le mode binaire qui est utilisé. Le fichier est donc transféré tel quel, sans conversion des fins de ligne, d'où le résultat que tu obtiens... Essaie d'utiliser FtpWebRequest à la place de WebClient

Merci de ta réponse!
Que j'ouvre mon fichier avec WordPad ou Notepad ne change rien [bizarre que FileZilla face correctement son boulot mais pas WebClient].

J'utilise FtpWebRequest pour lister les fichiers [ListDirectory] dans le répertoire sur le server distant et je les traite un à un dans une boucle [en parcourant le stream].
Mais je vais tester le téléchargement avec FtpWebRequest et je te redis.