AutoIt Français

Bonjour à tous,
je viens sollicité votre. Mon problème est que dans la fonction : Si "$s_RemoteFile", qui correspond donc au chemin menant fichier que je veux télécharger sur mon serveur FTP vers mon Pc, comprend des accents la fonction ignore le fichier.

Donc pour résoudre se problème je ne vois que deux solutions :

- La 1ère et la solution idée serait de trouver une astuce pour que _FTP_FileGet prennent en charge mon fichier avec les accents.

- 2ème solution renommer tout les fichier pour enlever les accents. Pour cela on pourrai utiliser une fonction comme "StringReplace" mais le problème c'est qu'il a beaucoup de fichiers et beaucoup d'accent (sur tout que je travail avec le dictionnaire Français et Allemand), et les ordinateur qui vont faire tourné mon programme ne sont pas très... vaillants .
Alors j'ai cherche dans l'aide et sur le forum mais je n'ai pas trouver de trace du fonction qui pourrai retirer tout les accents du fichier texte. ("d'un fichier texte" car oui mon programme récupère la liste des fichier à télécharger dans un document ".txt").

Alors voila si vous pourriez m'aider a résoudre mon problème avec l’une de ces solutions ou autre si vous avez des idées . Merci d'avance

Bonsoir,


Pour ma part je téléchargerai les fichiers manuellement, en local, puis ferai tourner une moulinette à accents, et les re-up ensuite.

Cdlt.

Il est possible qu'il faille remplacer les accents par leurs correspondance en caractère html :
Par exemple, é équivaut à %C3%A9 en caractère HTML.

Et sinon, si le fichier contient des accents, il faut voir les params dwFlags sur le MSDN ==> J'imagine que ça doit être "FTP_TRANSFER_TYPE_ASCII"

Ceci fonctionne chez moi :

Tout dépend si la liaison FTP se fait en ASCII (comprendre ANSI) ou en UTF-8 et si le filesystem en face est en ANSI (même codepage !) ou en UTF-8.

Le plus robuste est évidemment UTF-8 des deux côtés.

En ce qui concerne la demande de Pixelix, le code que je lui propose devrait résoudre son problème ...

Pardon mais je n'en suis pas certain :

Les tests que j'ai effectué sur le ftp du forum ont fonctionné pour 5 fichiers avec accents ...

Je n'en doute pas, mais ce n'est pas une solution qui marchera à tous les coups.
Le nom de fichier bizarre détruit le montre.

Il y a plusieurs points qui s'enchevêtrent là.

1) Ta fonction de conversion ANSI --> UTF-8 est correcte par elle-même, mais le problème est que tu ne lui passes pas une chaîne ANSI car toutes les variables natives et littéraux AutoIt sont de l'Unicode (UTF-16). Donc dès qu'on sort de l'ANSI (et encore, avec quelques exceptions) on détruit la chaîne avec le premier appel (MultiByteToWideChar) car on ne lui passe pas du multibyte.

2) Je ne suis pas du tout certain que l'on puisse changer la convention ANSI ou UTF-8 dans les fonctions _FTP*. Peut-être _FTPex, faudrait regarder.

3) Pas mal de serveurs ne sont pas bien fichus et établissent la liaison en ANSI alors que leur filesystem est en Unicode (Windows, quasiment tous les filesystems *nix et autres). C'est pour ça que Filezilla (par exemple, mais c'est vrai pour tous les prog. FTP corrects) dispose d'une jolie case à cocher pour forcer dans Unicode (UTF-8) alors que ça devrait se négocier automatiquement entre serveur et client.

Humm, certes ce que vous dites est juste, mais en l’occurrence Pixelix récupère une liste de nom de fichiers à partir d'un fichier texte, pour copier les fichiers sur son PC qui est sous Windows. Donc forcément, nous somme bien dans ce cas en ANSI !

D'après ce qui est dit, le but est donc de récupérer une liste de fichiers dont le nom est codé en ANSI à partir d'un FTP qui vraisemblablement (certes nous n'en sommes pas sur) utilise l'UTF-8.

Alors, certes la solution n'est pas universelle, mais elle correspond au besoin de Pixelix.

Tlem a écrit :en l’occurrence Pixelix récupère une liste de nom de fichiers à partir d'un fichier texte, pour copier les fichiers sur son PC qui est sous Windows. Donc forcément, nous somme bien dans ce cas en ANSI !

Ah bon, pourquoi ce "donc" ?

D'après ce qui est dit, le but est donc de récupérer une liste de fichiers dont le nom est codé en ANSI ...

une chance sur deux.

jchd a écrit :Ah bon, pourquoi ce "donc" ?

Même si il y a peut être une part de pifométrie, par déduction, nous avons :

• - AutoIt
  - PC (Windows ou Linux, mais bon, là je ne vois pas un utilisateur de Linux demander ce genre de chose !!!)
  - Pixelix parle d'un fichier texte à partir duquel il récupère la liste des fichiers à télécharger.

Ces trois éléments me font penser qu'il est sur un PC avec Windows et qu'il traite un simple fichier texte créé sous cet OS.

Maintenant, si vous voyez une solution plus universelle, ce serait génial.

PS: Pour celui qui aurait du temps pour bricoler, j'ai trouvé ce sujet qui me parait fort intéressant pour la détection du codage d'un fichier.
Il y à plein d'autres liens sur internet, mais celui-la m'a parut sympa.

OK Thierry mais un "simple fichier texte" peut être en ANSI (probablement la page de code "Europe de l'Ouest" qu'on utilise en grande majorité ici) ou en Unicode. Perso, j'ai des tonnes de fichiers que je dois maintenir en Unicode car contenant du texte en hébreu, en viêtnamien, en Indi, etc.

Si notre posteur maintient un dico en allemand, il n'est pas complètement impossible qu'il doive gérer la dernière nouveauté Unicode : le eszet majuscule (que je trouve être une abération linguistique mais je ne suis pas spécialiste) ou d'autres points de code du bas allemand du 13ème siècle, pourquoi pas.

Ce point est peu important toutefois : s'il lit son "fichier de fichiers" sous le bon mode, il chargera ça correctement en mémoire, car les chaînes AutoIt supporteront ces représentations.

Maintenant la question se pose au niveau FTP : si son serveur ne déclare pas correctement qu'il supporte UTF-8 (et pas mal de serveurs sont mal configurés de ce point de vue), la récupération des répertoires et fichiers distants va découillonner. Je viens de vérifier FTPex.au3 et (ouf !) on y emploie bien des fonctions Unicode (fonctionW). Seul hiatus : si le serveur est en ANSI (je doute un peu) et ne transforme pas en UTF-8.

Le contenu est autre chose : transfert en binaire, mode passif et ça doit fonctionner partout (ou presque !).

Si on a un Mac en face, le problème n'est pas forcément trivial (cf.: ce vieux fil).

En dernier lieu, la fonction à employer pour convertir une chaîne AutoIt native en UTF-8 est __UTF16toUTF8 ci-dessous (ou un équivalent) : Ne pas croire ce qu'on croit y voir : les ВΈТΑ là-dedans sont 4 caractères bien distincts des 5 caractères ASCII B'ETA, leur encodage le montre !

Bon lien sur un survol des problèmes de jeux de caractères, bien que la diversité des intervenants brouille un peu le tableau. J'ai aussi pondu quelques "murs de texte" dans des discussions similaires (comment détecter l'encodage d'un fichier texte) sur le forum US. Stricto sensu, il n'y a aucune solution qui soit à l'abri d'erreurs d'interprétation dans le cas général, ni hier, ni aujourd'hui, ni demain.

alors pour l'instant je suis pas chez donc je ne peu pas tester se weekend. mais pour plus d'informations le serveur est un pc sur le quel j'ai installer filezilla serveur d'après se que j'ai lu il me suffirait de changer la config du serveur pour que cella fonctionne correctement ?

ps : les clients sont Windows Xp ou devenu et le client sera est sous Xp

Oui, FileZilla fait tout et le reste.
Je ne peux pas tester : pas de FileZilla ici, download trop gros pour ma liaison instable et pas droit au FTP...
Aucun doute, je suis bien en France.

Donc finalement j'ai pu résoudre mon problème grâce a la fonction de Tlem, je n'ai pas réussit a changer la configuration du serveur (et pourtant j'ai tester tout les boutons). Mais pour l'instant ca fonctionne très bien.

Merci à vous tous pour votre précieuse aide.

Ps : comment on fait pour changer le tire du sujet pour mettre [R] ?

En éditant le titre de votre premier sujet (bouton Editer).

C'est bon c'est fait merci !