[R] Conversion de caractères entre MAC et WIN

[peuchere83]

Bonjour à tous,

Je récupère des fichiers par ftp provenant du monde MAC.
Mon problème est le suivant :
Les caractères accentués sont mal interprétés des réceptions sur mon poste Windows.
Voici un exemple de fichier nommé sous MAC:
â-ä-é-è-ù-$-£-`-&-@-Ä-Â
Et maintenant le fichier après ouverture sous WIN :
â-ä-é-è-ù-$-£-`-&-@-Ä-Â

Rq : le caractère '╠' est détecté comme un carré sous WIN. C'est le copié collé sur le forum qui l'a transformé ainsi.

D'après vous comment pourrais je renommer correctement mon fichier ?
Faire un tableau de conversion ?

Par avance merci.

[jbnh]

Quelle est l'extension de ce fichier ? Normalement si tu édites le fichier sur mac et windows avec le même logiciel il ne devrait pas y avoir de soucis.

[peuchere83]

Merci de me répondre jbnh.

En fait ce n'est pas forcément un fichier, cela peut être aussi un répertoire.
En fait il faut savoir que ce répertoire (prenons le cas d'un répertoire) contenant ces caractères, s'il m'est transmis non zippé, je n'ai aucun problème : Windows dans ce cas là, détecte correctement les caractères.
Par contre dans le cas ou le fichier est compressé (.zip), lors de la décompression sous Windows : catastrophe !!!

De plus je viens de faire des tests de décompression avec 3 programmes différents et j'obtiens 3 interprétations différentes !!! (la plus proche de la réalité a été obtenu avec Stuffit)

Petite précision : ce problème je le rencontre sur le nom de l'élément (fichier ou répertoire).

Pj : un nom de répertoire qui contient tous les caractères accentués que j'ai pu trouver sous mac.

Si quelqu'un a une suggestion je suis preneur.

Par avance merci.

[jchd]

Il devrait te suffire de faire tes transferts FTP en UTF-8 et d'enregistrer en temps que tel (UTF-8 + BOM).

[peuchere83]

Bonjour et merci pour la réponse.

Désolé j'étais plongé sur d'autre projet d'où mon retard pour la réponse.
En fait le problème se passe surtout lors de la décompression du fichier zip que j'ai récupéré par ftp.
C'est là qu'apparaissent les caractères "bizarres".

Donc 2 solutions : soit j'arrive à traiter les fichier en UTF8 (ou autre) mais pour l'instant je ne sais pas faire,
Soit je fais un tableau de conversion de caractère (ca je sais faire).


Cordialement

[jchd]

Peux-tu poster un fichier exemple ne contenant pas d'infos confidentielles, ou avec des infos rendues neutres ?

Ca me semble plus simple de déterminer quel encodage est reçu que de faire une conversion au pif qui risque d'éclater si on n'a pas bien compris les données du problème.

[peuchere83]

Ben par exemple le fichier zip qu'il y a dans mon 1er post est un répertoire que j'ai créé sous mac et que j'ai compressé toujours depuis mac.

Et lors de la décompression sous Windows, le problème d'affichage apparaît (en tout cas chez moi).

Si cela n'est pas suffisant comme exemple , je peux te mettre à disposition via dl.free.fr un véritable fichier zip récupéré depuis ftp (mais le problème sera le même que le fichier que j'ai créé de toutes pièces).

Par avance merci.

[jchd]

J'ai bien regardé ton archive, mais le fait que ce soit un répertoire et non pas un fichier fait qu'il est difficile de savoir comment il est encodé.

Si tu peut poster un bête fichier texte, ça sera mille fois plus simple.

Quel logiciel de compression emploies-tu, côté Mac ? En fait, je devrais dire as-tu une possibilité d'employer un outil existant à la fois sous Mac et PC, car je ne connais rien au Mac. Enfin rien, juste que les entrées de répertoire sont en Unicode (comme Win32) et que les programmes Mac ont tendance à privilégier une normalisation Unicode distincte du logiciel PC : les accentués sont dissociés en accent + lettre, alors que le soft PC utilise généralement la normalisation C (lettre accentuée en un seul code). A prendre avec deux grains de sel car je n'ai, ô honte à moi, jamais touché un Mac après la version "mini télé".

[moutelous]

Bonsoir,

Un petit constat, sans aucune analyse :

J'ai transféré votre fichier zip par ftp de mon mac vers un pc virtuel sous vm ware fusion. Sur le Pc virtuel je fais le même constat que vous en utilisant le décompresseur intégré dans XP.

Par contre en décompressant le fichier zip à l'aide d'Izarc sous windows tout rentre dans l'ordre.

A+

[peuchere83]

Bonjour et merci pour vos réponses.

Jchd : Ci-joint un répertoire compressé contenant 3 images jpg.
La compression se fait avec le logiciel intégré à Mac OS X (et certainement aussi avec stuffit)

Moutelous : je viens de tester la décompression avec izarc et en effet cela corrige le problème.
Cela signifie donc que stuffit, 7-zip , winzip utilisent un encodage des caractères différents de izarc

Mais je laisse le post non résolu car je suis curieux de connaître la réponse de jchd.

Merci à tous.

[peuchere83]

Je viens rajouter une information supplémentaire :

Avec izarc cela fonctionne MAIS seulement au travers de l'interface graphique et pas en ligne de commande (add-on : izarce) (je suis dégouté)

Donc c'est bien un problème d'encodage.
Comment le contourner ?

Est il possible d'exploiter la dll de izarc avec autoit pour cela ? et comment ?

D'autres suggestions ?

Par avance merci

[jchd]

Une simple recherche Google montre que le support de noms de fichiers Unicode n'est pas aussi évident qu'il y paraît.

Maintenant, existe-t-il une option dans stuffit pour le support Unicode ?
WimZip supporte les noms Unicode depuis la version 11.2. WinRar dispose d'un switch en ligne de commande.

Le problème de la ligne de commande sous OS X est peut-être similaire à celui rencontré avec la console par défaut sous Win32. Le jeu de caractères est ANSI avec page de code définie par le réglage de localisation de l'utilisateur. Sous Win32, on peut changer la page de code et passer en Unicode UTF-8 (page de code 65001).

[peuchere83]

Désolé de cet harcèlement au niveau de mes question mais c'est un point que j'ai du mal à saisir donc je profite de vos connaissances pour améliorer la mienne.

WinRar dispose d'un switch en ligne de commande.

Je viens d'installer winrar et regarder les différentes options. La seule qui semble correspondre est : " I[i|c|h|t]=<chaîne>" mais elle e fonctionne pas lors de la décompression (ou alors, je n'ai pas réussi à l'utiliser ).

Sous Win32, on peut changer la page de code et passer en Unicode UTF-8 (page de code 65001).

Comment ? J'ai regardé sous internet et je ne vois pas comment faire. De mémoire sous dos il y a une commande (de mémoire chcp) qui doit faire cela mais comment l'utilisé sous autoit ?

Si je comprends bien c'est sur le logiciel de décompression que je doit faire ce changement de page de code.

Par avance merci.

[jchd]

Je n'y tenais pas trop, mais j'ai regardé le fichier .ZIP lui-même pour déterminer ce qui se passe exactement.

Voici la fin du .zip du premier post, c'est la fin du répertoire.

Code : Tout sélectionner

34440H  EA 02 00 5F 5F 4D 41 43 4F 53 58 2F 64 6F 73 73   'j..__MACOSX/doss'
34450H  69 65 72 20 64 65 20 74 65 73 74 2F 2E 5F 41 6C   'ier de test/._Al'
34460H  69 63 65 20 43 68 61 69 73 65 20 61 CC 80 20 74   'ice Chaise aL. t'
34470H  72 6F 75 20 76 65 72 74 65 5F 30 30 31 35 2E 6A   'rou verte_0015.j'
34480H  70 67 55 58 08 00 C2 FC 47 4C 9B FC 47 4C 50 4B   'pgUX..B|GL.|GLPK'
34490H  05 06 00 00 00 00 0B 00 0B 00 46 04 00 00 48 40   '..........F...H@'
344A0H  03 00 00 00                                       '....'

La chose intéressante est en 3446C..3446D = 61 CC 80
C'est bien de l'UTF-8 et c'est la lettre 'a' minuscule suivie du caractère diacritique 'accent grave' (codepoint U0300). C'est la forme "Mac" de 'à' car, comme je le disais plus haut, le Mac a une forte tendance à privilégier la forme Unicode décomposée tandis que le monde PC utilise très majoritairement la forme C, composée. Voir http://en.wikipedia.org/wiki/Unicode_equivalence vers la fin, § Errors due to normalization differences qui parle de Mac OS X (désolé, la version française omet le paragraphe).

Il y a donc en fait deux problèmes :
1) le format ZIP est en délicatesse avec Unicode (une recherche Google montre l'ampleur du problème).
2) même si on parvient à faire fonctionner le décodage UTF-8, les répertoires crées n'auront pas le même nom ! Ils apparaîtront identiques car à l'affichage a` donne à mais si un programme cherche un nom contenant un à, Windows ne le trouvera pas s'il est créé sous la forme a` (a + accent grave).

La plus simple solution serait d'employer un format portable entre Mac et PC qui respecte l'encodage UTF-8 mais normalise en forme C les noms de fichiers et de répertoires sous Windows. Il est impossible que cela n'existe pas déjà, éventuellement payant. RAR, 7zip, que sais-je ?

L'option pour lister des fichiers en Unicode avec Rar.exe est pourtant bien documentée :
C:\temp\> "C:\Program Files\WinRAR\rar.exe" l -scul <nom de l'archive>

Ah, j'allais oublier :
C:\temp\> chcp
Page de codes active : 850

C:\temp\> chcp 65001
Page de codes active : 65001

C:\temp>
fonctionne très bien pour moi (XP SP3 x86).

[peuchere83]

Merci beaucoup pour le temps passé jchb.

J'ai fait de nombreux tests avec winrar et impossible de corriger ce problème en ligne de commande.

Il ne me reste donc que 2 solutions :
- à court terme : piloter izarc (interface graphique) pour décompresser les fichiers qui me sont envoyés
- à long terme : développer une application (pour mes clients) qui mettra là disposition sur ftp les fichiers zip mais avec un encodage qui ne me posera plus de problème ensuite pour mes postes Windows.
(c'est d'ailleurs ce que tu me recommandes dans ta précédente réponse)

J'ai terminé la 1ère solution (elle est en test) et j'ai commencé la 2ème sous monodevelop (C#).

Encore merci pour le temps passé car le passage entre les codes Mac et Windows est à se taper la tête contre les murs.

[jchd]

Bah, j'aime bien trouver le pourquoi du comment quand une situation de cet ordre survient. Je trouve ça tellement débile de devoir bloquer ainsi sur des opérations aussi élémentaires.

Bon courage car, comme je le dis bien trop souvent à mon gré, nous sommes toujours en pleine préhistoire et cet exemple le prouve une fois de plus...

UTF-8-MAC, quelle imbécilité !

Pour un point de départ sur les API Win32 requises pour normaliser de l'Unicode, voir http://msdn.microsoft.com/fr-fr/library ... 85%29.aspx (encore désolé, la page n'est pas traduite en hexagonal).

[peuchere83]

Pour un point de départ sur les API Win32 requises pour normaliser de l'Unicode, voir http://msdn.microsoft.com/fr-fr/library ... 85%29.aspx (encore désolé, la page n'est pas traduite en hexagonal).

Et encore merci