framboise314.fr

Bonjour,
Entre python 2 et python 3 , il y a eu de gros changements.

Le principal concernant les méthodes d'utilisation des chaînes de caractères et leur encodage.
Dans un écosystème pur Linux (ou Linux/Mac), pas de soucis, il suffit d'utiliser l'UTF-8 partout et tout va bien.

Mais lorsque vous échangez des données avec un Windows "Frenchie" qui est en ANSI, là, ça coince.

On peut, en précisant à Python comment sont encodés les fichiers, et avec beaucoup de précautions, exploiter l'un ou l'autre de ces encodages.
Mais si on doit transmettre à windows des fichiers (par exemple textes, destinés à devenir des fichiers Excel), il faut qu'ils soient encodés en ISO8859, sinon, attention aux caractères spéciaux de notre belle langue ! Idem si on lit une base de données issues du monde windows avec un Pi.
En plus, une session ssh est systématiquement dans l'encodage paramétré dans l'OS.

Quelles sont vos habitudes à ce sujet. Il y a différentes recommandations mais toutes ont des défauts non négligeables.

Salut Piper.

Je n'utilise pas python.

Je ne me complique pas trop l'existence, puisque j'utilise "latin1" (ISO-8859-1) pour mes sites et mes bases de données mysql.
Pour la console, à travers putty, j'utilise utf8.

Piper a écrit :Dans un écosystème pur Linux (ou Linux/Mac), pas de soucis, il suffit d'utiliser l'UTF-8 partout et tout va bien.

Il existe plusieurs version de utf8.
Sous MySql, tu peux utiliser "utf8mb4" car cette version est complète mais à le problème de codifier les caractères jusqu'à quatre octets.

Piper a écrit :Mais lorsque vous échangez des données avec un Windows "Frenchie" qui est en ANSI, là, ça coince.

De quel échange parles-tu ? En mode Serie ? Ou des transferts de fichiers ?
Pour le transfert de fichiers vers windows, je passe par samba, et je n'ai jamais eu de problèmes d'accents.

Piper a écrit :Mais si on doit transmettre à windows des fichiers (par exemple textes, destinés à devenir des fichiers Excel), il faut qu'ils soient encodés en ISO8859 ...

Quel ISO-8859 ? Il y a en à 15. Si tu fais "latin1" alors c'est "ISO-8859-1". Si tu veux le caractères € alors c'est "ISO-8859-15".

Piper a écrit :... sinon, attention aux caractères spéciaux de notre belle langue ! Idem si on lit une base de données issues du monde windows avec un Pi.

Une astuce est de n'utiliser que les caractères de la table ASCII (<=127). Du coup, tu n'as pas les accents.
Ou bien, faire une conversion de "utf8" vers "latin1".en utilisant les fonctions "encode()" et ou "decode()."

@+

Merci
Je connais sur le bout des doigts les différents types d'encodage de tous les SGBDR que ce soit DB2, Oracle, Firebird, Interbase, MySQL, SQL Server.
Je sais aussi qu'utiliser l'ASCCI nous débarrasse du problème (et des accents aussi, ce qui n'est pas ce que je veux)

Je parlais plutôt d'un exemple comme celui-ci :
1) installation par défaut d'un Raspberry Pi (il est donc en UTF-8)
2) développement à partir de windows avec Winscp/Notepad++ : là, on est en ANSI : ouille
3) des print de debuggage dans le code
5) execution sur le raspberry via putty ==> tous les accents sont remplacés par des caractères bizarres.

Autre exemple :
1)Développement directement sur le raspberry (avec geany) => UTF-8
2) Production de fichiers à partir d'une base de données en UTF-8 ==> UTF-8
3) Envoi vers Windows de ces fichiers (via ftp, sftp, samba, what else)
4) création de tableaux sous Excel à partir de ces fichiers ==> les accents sont pourris

La solution est la conversion mais la conversion provoque souvent au mieux des warning mais souvent des erreurs.
J'arrive toujours à m'en sortir mais je me demandais si vous aviez des habitudes moins "chiantes"
Pire sous python3, sans conversion==> plantage brutal

Salut Piper.

Piper a écrit :2) développement à partir de windows avec Winscp/Notepad++ : là, on est en ANSI : ouille

ANSI = Windows-1252. C'est presque du ISO-8859-1 qui est le "latin1".

Piper a écrit :5) exécution sur le raspberry via putty ==> tous les accents sont remplacés par des caractères bizarres.

C'est l'interprétation du caractère codé windows-1252 en utf-8.

Winscp repose sur pscp.exe.

Je fais ça, en utilisant un batch windows avec la commande pscp.exe (PuTTY Secure Copy client).
J'ai testé avec un fichier encodé ANSI coté windows.
Coté raspberry, quand je l'ai ouvert avec "vi", j'avais bien les accents. La conversion se fait automatiquement.
Ma Raspberry est bien encodé en utf-8.

@+

Tu t'es fait avoir parce que tu l'as consulté avec un éditeur de texte intelligent qui recherche l'encodage.

Ex : ouvres putty fait un

Code : Tout sélectionner

echo "héhé" > toto.txt

Maintenant fais (si file te manques installes-le)

Code : Tout sélectionner

file toto.txt

Il te diras en quoi est encodé le fichier (normalement : UTF-8)

Maintenant transfert ce fichier sur Windows (avec winscp par exemple)
Et consultes-le avec type (pas avec un éditeur intelligent !!!!) :

Code : Tout sélectionner

type toto.txt

==> les accents sont des caractères illisibles

Dans l'autre sens :
Ouvre un fichier avec le bloc-notes windows, par exemple titi.txt, mets dedans "héhé"
Envoies le sur le Raspberry
tapes

Code : Tout sélectionner

file titi.txt

==> il te dit qu'il est en ISO-8859

Fais un

Code : Tout sélectionner

cat toto.txt

==> les accents sont des caractères illisibles

Il y a toute une littérature la dessus sur Python3
Je te conseille de la lire avant de chercher à faire des échanges de fichiers entre Windows et Linux (ou inversement)
https://docs.python.org/3/howto/unicode.html

Salut,

Le problème d'encodage entre les windowseries et le reste du monde n'est pas nouveau.

A l'époque, passer le ftp en mode text (ou ascii) mais je ne sais pas si ca marche encore pour les différents encodages ISO merdié vers UTF-8.
Si ca ne suffit pas (par exemple si les fichiers sont dans des archives), il existe sous unix l'utilitaire dos2unix qui de mémoire permet aussi de changer d'encodages. Sinon, iconv qui est fait pour ca.

Mais pour résoudre ton problème, une des solutions les plus simples est d'utiliser un éditeurs plus civilisés comme "Notpad++" qui permet de définir l'encodage du fichier et donc de le mettre en UTF8 ce qui résoudra ton problème.

Pour ms-excel, au moment de l'import du CSV tu peux lui indiquer l'encodage.

Par contre pour :

J'arrive toujours à m'en sortir mais je me demandais si vous aviez des habitudes moins "chiantes"

C'est simple : je n'utilise pas windows pour mes développements (ou pour quoi que soit d'autre d'ailleurs

)
Je fais tous directement sous Linux et quand malheureusement j'ai ce besoin au taf ou l'on m'impose cet "os", soit je me logue sur les machines Unix et j’édite les fichiers en locale, soit au pire je passe par Notepad++ comme je l'indique.

A+

Moi non plus je n'utilise pas Windows pour mes développements.

Mais certains projets ont pour objectif d'exploiter les résultats sous windows !

Ou de recevoir des données en provenance de Windows !

Salut Piper.

J'ai fait le test de windows vers raspbian à travers l'outil pscp.exe (putty), que j'utilise pour mes transferts automatisés, et ça fonctionne !
Sinon, je peux le faire manuellement en passant par SAMBA, et ça fonctionne aussi.
De raspbian vers windows, j'utilise samba, et je n'ai jamais rencontré de problèmes.

Piper a écrit :Tu t'es fait avoir parce que tu l'as consulté avec un éditeur de texte intelligent qui recherche l'encodage.

Il est vrai que j'utilise "notepad++", coté windows et "vi" coté raspberry.
Avant de dire quoi que ce soit dans mon dernier message, j'ai fait le test, afin de m'assurer que je ne raconte pas de conneries.
J'ai vérifié l'encodage et avant transfert, j'avais bien ANSI, que j'ai même forcé en cliquant sur convertir ansi et en sauvegardant ensuite.

Je n'utilise pas l'outil "winscp".

Voici le nouveau test :

Code : Tout sélectionner

~> echo "été près forêt" > toto.txt
~> file toto.txt
toto.txt: UTF-8 Unicode text
~> cp toto.txt /share
~>

Je passe par Samba pour obtenir le fichier coté windows.

Code : Tout sélectionner

C:\>type toto.txt
+®t+® pr+¿s for+¬t

C:\>

C'est normal car je suis dans la console qui travaille en windows-1252.

Code : Tout sélectionner

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

C:\>type toto.txt
été près forêt

C:\>

Et comme tu peux le voir, le contenu de toto.txt est lisible.
Je fais le test avec "bloc.notes", et je lis correctement le fichier.
Le fichier en provenance de la raspberry est bien en utf8 sous windows et cela ne me pose aucun problème, à la condition d'avoir le bon jeu de caractères.

Je fais le test dans l'autre sens windows vers raspbian.

Code : Tout sélectionner

C:\>type tata.txt
forÛt prÞs ÚtÚ
C:\>chcp 1252
Page de codes active : 1252

C:\>type tata.txt
forêt près été
C:\>

Je transfères le fichier tata.txt par samba vers raspbian.

Code : Tout sélectionner

~> cd /share
/share> la
total 28
drwxrwxr-x+  3 root root  4096 juil.  8 20:14 .
drwxr-xr-x  25 root root  4096 mai   30 01:55 ..
drwx------   2 root root 16384 déc.   8  2020 lost+found
-rwxr--r--   1 root root    15 juil.  8 17:06 tata.txt
/share> cat tata.txt
for¦t pr¦s ¦t¦ /share>
/share>
/share>

Je fais le test avec "vi", et je lis bien les caractères accentués.

Pour traiter un fichier, je passe en effet par un éditeur de text.

Si maintenant, coté windows, je convertis le fichier tata.txt en utf8

Code : Tout sélectionner

C:\>type tata.txt
for+¬t pr+¿s +®t+®
C:\>chcp 65001
Page de codes active : 65001

C:\>type tata.txt
forêt près été
C:\>

Comme tu peux le voir coté windows, le fichier est bien en utf8. Je transfères par samba.

Code : Tout sélectionner

/share> la
total 28
drwxrwxr-x+  3 root root  4096 juil.  8 20:20 .
drwxr-xr-x  25 root root  4096 mai   30 01:55 ..
drwx------   2 root root 16384 déc.   8  2020 lost+found
-rwxr--r--   1 root root    19 juil.  8 17:14 tata.txt
/share> cat tata.txt
forêt près été /share>
/share>

C'est ce que je dis, je n'ai pas de problème pour la conversion des caractères accentués.

@+

Logique chcp change la page de code
En fait c'est pareil. Tu changes la page de code avec chcp

Donc ta réponse a la question serait :
"Je change la page de code sur windows avant de traiter le fichier par un logiciel sur windows"

Comment tu automatises ça quand tu veux qu'un "ancien" à qui tu transfères le fichier qui sait tout juste utiliser 5% d'Excel traite le fichier sans te téléphoner ?

Car la question était "Quelle est la meilleur méthode pour qu'à la sortie du Raspberry n'importe quel utilisateur de Windows puisse exploiter le fichier"

Et dans l'autre sens : lorsque tu dois lire une base de données Windows via le réseau, dont la page de code est latin-1 et que tu veux cette fois-ci faire de beau print sur le Raspberry (en UTF-8)

Salut Piper.

Il faut distinguer deux choses, le transfert du fichier et la codification dudit fichier.
Comme je l'ai dit précédemment, si je désire rendre le transfert du fichier automatique, j'utilise "pscp.exe" (Putty) ou bien manuel alors j'utilise "samba".
Pour ce qui est de la codification du fichier, comme dans mon exemple ci-avant, je passe par "notepadd++" pour le codifier (ansi ou utf8), et convertir les sauts de lignes (windows, unix ou mac).
Si tu veux le rendre automatique, il y a un utilitaire windows en ligne de commande "convertcp.exe":
--> https://sourceforge.net/projects/convertcp/

Convertir de ANSI (0) vers UTF-8 (65001) sans BOM :

Code : Tout sélectionner

convertcp.exe 0 65001 /i infile.txt /o outfile.txt

Coté raspberry, en ligne de commande, convertir de utf8 vers ISO-8859-1 qui est très proche de ansi (windows-1252) :

Code : Tout sélectionner

iconv -f iso-8859-1 -t utf-8 <infile >outfile

@+

framboise314.fr

Quelle méthode d'encodage utilisez-vous ?

Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?

Re: Quelle méthode d'encodage utilisez-vous ?