Discussion :

[RAMEX]

Bonjour

en faisant des tests sur la gestion de contenu j ai créé un fichier
texte (.txt)avec notepad rempli d'accents et de caracteres spéciaux
pour valider mes traitements ultérieurs,
ci dessous :

Je m’en rappellerais si j’avais créé un programme capable de parler.
é&'- rtue à )^ù:; l'école l'arrivée -AtESERE
Et puis tiens, je suis en train de taper la causette avec un ordinateur !
Je deviens vraiment cinglé ! C’est fini, j’arrête l’informatique !

En ouvrant ce fichier avec python c'est ennuyeux car
je me retrouve avec ce qui suit :

Je m’en rappellerais si j’avais créé un programme capable de parler.
é&'- rtue Ã* )^ù:; l'école l'arrivée -AtESERE
Et puis tiens, je suis en train de taper la causette avec un ordinateur !
Je deviens vraiment cinglé ! C’est fini, j’arrête l’informatique !

A tout hasard je joins le source python ( très classique)

Code :

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

1
2
3
4
5
6
7
8
9
# Définition de la fonction qui ouvre le filedialog et récupère le chemin du fichier sélectionné
def ouvrir_fichier():
    chemin_fichier = filedialog.askopenfilename(initialdir = "/", title = "Sélectionner un fichier texte", filetypes = (("Fichiers texte", "*.txt"), ("Tous les fichiers", "*.*")))
    if chemin_fichier:
        # Si un fichier a été sélectionné, on lit son contenu et on l'affiche dans le widget texte
        with open(chemin_fichier, "r") as fichier:
            contenu = fichier.read()
            zone_texte.delete("1.0", tk.END) # Efface le contenu précédent de la zone de texte
            zone_texte.insert("1.0", contenu)

Après une foultitude de recherches
1 - est-ce normal?
2 - comment obtenir en sortie la même chose qu'en entrée?
meeeeerci & bonne nuit

[Sve@r]

Bonjour

Apres une foultitude de recherches
1 - est-ce normal?
2 - comment obtenir en sortie la meme chose qu'en entree?

L'encoding. Ton fichier a été créé avec blocnote donc très probablement encodé en ascii, et Python travaille en utf-8 (qui est devenu la norme). C'est un peu comme si tu tentais de lire de l'allemand en lui appliquant une grammaire française.
Ouvre-le avec notepad++ (un éditeur bien plus sympa et gratuit). Tu as une option pour le convertir en utf-8 (menu "Encodage" en haut). Ou alors demande explicitement à Python de travailler en latin-1 (le nom officiel de l'ascii). Ca se demande lors de l'ouverture.

[fred1599]

Bonjour,

j ai créé un fichier

Vérifiez que le fichier est enregistré avec l'encodage UTF-8.

Dans le cas où vous ne le faîtes pas pour d'autres raisons, ouvrez votre fichier avec l'argument encoding à UTF-8.

Code :

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

with open("...", 'r', encoding='utf8')

EDIT: grilled

[jurassic pork]

Hello,

L'encoding. Ton fichier a été créé avec blocnote donc très probablement encodé en ascii, et Python travaille en utf-8 (qui est devenu la norme). C'est un peu comme si tu tentais de lire de l'allemand en lui appliquant une grammaire française.

Ben non les 127 premiers caractères de l'UTF-8 c'est l'ASCII :

Généralement en Unicode, un caractères prend 2 octets. Autrement dit, le moindre texte prend deux fois plus de place qu'en ASCII. C'est du gaspillage.
De plus, si on prend un texte en français, la grande majorité des caractères utilisent seulement le code ASCII. Seuls quelques rares caractères nécessitent l'Unicode.
On a donc trouvé une astuce: l'UTF-8.
Un texte en UTF-8 est simple: il est partout en ASCII, et dès qu'on a besoin d'un caractère appartenant à l'Unicode, on utilise un caractère spécial signalant "attention, le caractère suivant est en Unicode".
Par exemple, pour le texte "Bienvenue chez Sébastien !", seul le "é" ne fait pas partie du code ASCII. On écrit donc en UTF-8:
Bienvenue chez Sébastien !

Ce qu'il y a de bizarre dans le texte de RAMEX c'est l'apostrophe qui normalement existe en ASCII. L'apostrophe utilisée n'est pas celle de l'ASCII.

Ami calmant, J.P

[Sve@r]

Ben non les 127 premiers caractères de l'UTF-8 c'est l'ASCII
Ce qu'il y a de bizarre dans le texte de RAMEX c'est l'apostrophe qui normalement existe en ASCII. L'apostrophe utilisée n'est pas celle de l'ASCII

Tes remarques sont légitimes... mais je ne vois pas d'autre cause.

[jurassic pork]

Tes remarques sont légitimes... mais je ne vois pas d'autre cause.

D'après ce qu'on voit en sortie, il semblerait que le fichier d'entrée soit encodé en UTF-8 mais pas interprété comme tel. Le code de fred1599 devrait normalement rétablir une bonne interprétation. Par défaut en python sous windows la lecture d'un fichier se fait en ANSI (utf-8 sous linux).

[Sve@r]

Par défaut en python sous windows la lecture d'un fichier se fait en ANSI (utf-8 sous linux).

Ah ? Ca je savais pas. Je pensais que c'était utf-8 par défaut dans les deux mondes

[RAMEX]

Ok merci

Mon but - dans un domaine de cryptographie- est d'obtenir les caractères tels qu'on les a entrés
dans le but de traiter la chaine ave plus d'efficacité

[RAMEX]

hello
avec with open("...", 'r', encoding='utf8') c’a a l'air de marcher

merci

[Sve@r]

Mon but - dans un domaine de cryptographie- est d'obtenir les caractères tels qu'on les a entrés

Oui c'est un peu le but de tout le monde dans tous les domaines que de récupérer ce qui a été entré
Par ailleurs la cryptographie est un domaine qui ne traite pas des chaines mais du simple binaire. Parce que c'est plus sécurisé de transformer un flux binaire de 64, 128, 256 bits en un autre flux de taille identique que transformer un caractère en un autre.
Autrement dit, tu veux chiffrer ton fichier tu dois l'ouvrir en "rb" et non pas en "r" et là plus de souci d'encoding car plus d'encoding.

dans le but de traiter la chaine ave plus d'efficacité

Non, juste avec exactitude. Python n'est pas moins efficace avec une chaine erronée qu'une chaine correcte, pour lui ça reste des chaines de même nature.