Version imprimable
Bonjour,
je voudrais pouvoir deviner l'encodage d'un fichier TEXTE, ceci afin de permettre aux utilisateurs non avertis de mon projet d'avoir la possibilité d'utiliser des textes ne respectant pas l'UTF-8, pour bien entendu ensuite écraser leur fichier en un ayant pour encodage l'UTF-8, encodage avec lequel travaille mon projet.
Il semblerait qu'il y ait une solution ici dans l'excellent "Dive Into Python 3".
L'avez-vous testé ? En connaissez-vous d'autres ?
Salut
As -tu lu les précautions d'emploi de chardet?
Le problème de conception de fond est assez "basique", mais mérite de s'y attarder un peu.
Règle 1: Un traitement sur "du texte" travaille avec de l'Unicode, i.e des caractères codés avec des entiers 16 bits (ou plus).
Règle 2: Décoder le plus tôt possible et encoder le plus tard possible...
Conséquence: on ne devine qu'en cas de désespoir, on garde l'encoding utilisé dans le cas "normal".
Ce qui signifie:
- pouvoir stocker/lire des documents dans n'importe quel encoding pour peu qu'on sache ce qu'il est (et que les codeurs/décodeurs existent).
- UTF-8 est un standard de représentation de l'Unicode sous la forme de bytes. C'est très bien pour 'stocker', 'échanger', mais impropre aux traitements qui transforment la suite de bytes en suite de mots Unicode.
- W
C'est bien l'idée. L'utilisateur aura le choix de l'encodage à l'ouverture, et une recommandation lui sera faite de passer à du codage UTF-8 lors de l'enregistrement.Citation:
Envoyé par wiztricks
Maintenant, pour un utilisateur qui n'y connait rien, qui ne sait pas ce qu'est un encodage, je proposerais via chardet des encodages possibles avec bien entendu un visuel à côté du fichier original avant toute modification. Au final, c'est l'utilisateur qui dira que l'encodage est bon et non mon programme.
Je vois pas le problème. Avec Python 3 je ne manipule plus que des fichiers codés en UTF-8 sans aucun souci... Peux-tu préciser ton propos ? Il faut savoir que je vais travailler sur des fichiers TEXTE qui seront des documents rédigés par un humain pour des humains.Citation:
Envoyé par wiztricks
Ben...
Je ne sais pas quel est l'IHM mais pour pour l'encoding de l'utilisateur est dans la locale ou la default locale... Et comme l'utilisateur sait rarement ce que c'est, je ne vois pas l'intérêt de lui poser une question à laquelle on aura une réponse incertaine alors qu'on peut avoir la réponse par ailleurs.Citation:
Envoyé par rambc
Dans Python 3 il y a des bytes (encodés utf-8 par défaut) et des strings Unicode (des séquences de codepoints).Citation:
Je vois pas le problème. Avec Python 3 je ne manipule plus que des fichiers codés en UTF-8 sans aucun souci... Peux-tu préciser ton propos ? Il faut savoir que je vais travailler sur des fichiers TEXTE qui seront des documents rédigés par un humain pour des humains.
J'espère les traitements se font sur des strings Unicode et les résultats/entrées convertis en bytes à la lecture/écriture des fichiers.
- W
Hum, je ne te suis plus... J'ai été personnellement heurté au problème d'encodage lors de mon passage de Windaube à Mac O$. Une fois le problème repéré, j'avais utilisé NotePad+ sous Windaube pour passer de l'encodage Windaube cp... à de l'UTF-8. C'est ce genre de chose que je voudrais faire.Citation:
Envoyé par wiztricks
Quant l'utilisateur qui ne sait rien sur les encodages, ce qui était mon cas sous NotePad++, et bien c'est à eux que je proposerais une aide via une fenêtre avec le fichier ouvert avec différents encodages que l'on pourra choisir dans une liste. On a un rendu direct et on peut dire qu'un encodage est bon dans la mesure où le rendu ne renvoie aucun caractère mystique.
Salut,
Répétons, répétons,... c'est la base de la pédagogie :mrgreen:Citation:
Envoyé par rambc
Un fichier contient (à priori) une suite de "bytes" représentant du texte.
Exemple: Un script Python contenant autre chose que de l'ASCII doit être renseigné avec l'encoding pour être 'utilisable'.
L'encoding "connu" convertir les bytes en Code Points Unicode ne pose aucun souci.
S'il y a soucis, c'est dans la fonction inverse i.e. impossible d'écrire l'ensemble des Code Points Unicode en "bytes" Latin-1.
Pire, la valeur d'un byte pourra correspondre à des glyphs différents si on passe de latin-1 en latin-10.
Ceci dit si l'environnement "utilisateur" est configuré "latin-1", on sait l'encodage dans lequel seront récupérées les "'bytes" et celui dans lequel les écrire.
Le problème est que l'ensemble des traitements qui sont susceptibles de représenter la suite de "bytes" doivent savoir faire correspondre un entier ou une suite d'entiers à des "glyphs" bien particuliers.Citation:
Quant l'utilisateur qui ne sait rien sur les encodages, ce qui était mon cas sous NotePad++, et bien c'est à eux que je proposerais une aide via une fenêtre avec le fichier ouvert avec différents encodages que l'on pourra choisir dans une liste. On a un rendu direct et on peut dire qu'un encodage est bon dans la mesure où le rendu ne renvoie aucun caractère mystique.
Ce qui suppose qu'on leur envoie des représentations dans un encoding particulier ou qu'on leur précise l'encoding dans lequel l'information est codée pour qu'il s'en accommodent.
Exemple: Afficher le contenu du document avec l'utilitaire x ou y suppose que x et y sachent interpréter format et encodage... Et on a aussi envie que le document imprimé ressemble à ce qu'on voit sur l'écran, voir qu'on soit capable de faire des "cut" d'un bout de document qu'on paste dans un autre programme.
Le codage de nos bytes (utf-8) ou autre dépendant aussi du media type, si cela n'a pas été un minimum "pensé" et "construit" pour que ce soit transparent, cela restera:
- un casse tête sans fin pour l'utilisateur,
- des tas d'ennuis côté assistance/maintenance/ajout de fonctionnalités
- W
J'ai repris le sport et je crois que je suis atteint du syndrome bleu, à savoir une tendance du cerveau à s'atrophier suite à une pratique sportive.Citation:
Envoyé par wiztricks
Pas de souci là-dessus.Citation:
Envoyé par wiztricks
Et donc ceci est normalement accessible directement. Si oui comment ?Citation:
Envoyé par wiztricks
Oui mais je vais uniquement produire de l'UTF-8 afin que l'on puisse utiliser les fichiers sur différentes OS et aussi avec différents éditeurs sans difficulté (je pense à des éditeurs un minimum sérieux comme NotePad++ sous Windaube, TextWrangler sous Mac O$, et Gedit sous Linux). Mon prog. va utiliser ces fichiers pour en produire par exemple une version LaTeX, un peu comme ce que fait Sphinx avec Rest.Citation:
Envoyé par wiztricks
L'utilisateur sera informé de la manipulation à chaque fois.Citation:
Envoyé par wiztricks
Merci pour ta patience.
Dans la plupart des encodages latin-1,...latin15, le même code peut être utilisé pour représenter des glyphs/caractères différénts. Si on perd l'info "encodage", on est paumé.Citation:
Citation:Et donc ceci est normalement accessible directement. Si oui comment ?Citation:
Envoyé par wiztricks
Exemple: Un script Python contenant autre chose que de l'ASCII doit être renseigné avec l'encoding pour être 'utilisable'.
L'encoding "connu" convertir les bytes en Code Points Unicode ne pose aucun souci.
C'est accessible "directement" dans la mesure ou chaque type de document (un fichier script Python peut être considéré comme...) dit 'par défaut, l'encoding est...' et 'si vous utilisez autre chose que le défaut, voilà comment signaler l'encoding utilisé'.
Certes mais si la nature des fichiers produits par cette "chose" doivent être exploitable par d'autres outils, ce ne sont plus de simples fichiers mais des documents qui devront avoir un minimum de structure pour être exploitable "ailleurs".Citation:
Oui mais je vais uniquement produire de l'UTF-8 afin que l'on puisse utiliser les fichiers sur différentes OS et aussi avec différents éditeurs sans difficulté (je pense à des éditeurs un minimum sérieux comme NotePad++ sous Windaube, TextWrangler sous Mac O$, et Gedit sous Linux). Mon prog. va utiliser ces fichiers pour en produire par exemple une version LaTeX, un peu comme ce que fait Sphinx avec Rest.
Heureusement des "standards" existent: jettes deux yeux sur Open Document et UNO qui possède une API Python.
Dans ce cas, typiquement, un document est représenté sous la forme d'une structure XML dont l'encoding est précisé par l'en-tête <?xml version="1.0" encoding="UTF-8"?>.
Note: Et toutes les suites de bytes "UTF-8" ne sont pas nécessairement valide tel que dans un fichier XML encodé "UTF-8".
Je maintiens que ce n'est pas nécessairement une bonne idée car si nous avons nous même des soucis pour donner du sens à tout çà comment espérer que l'utilisateur s'en sortira ? Rendre ce micmac transparent, quitte à tracer certaines opérations au cas où, me semble la seule option.Citation:
L'utilisateur sera informé de la manipulation à chaque fois.
- W
Finalement, je ferais quelque chose à la Python 2..., à savoir une ligne commentée donnant l'encodage au début en cas d'utilisation des fichiers TXT en dehors de mon application.
Un simple "Le logiciel amateur TrucMuche ne sait lire que des fichiers encodés en UTF-8". Très autoritaire mais bon si j'ai un utilisateur de mon prog., je serais très content. Je l'ai développé dans un cadre précis mais non limitatif. Je le mettrais en ligne dès fois que d'autres personnes lui trouvent une utilité.Citation:
Envoyé par wiztricks
Tu me parles de formats ouverts mais en fait j'utilise un langage de type Rest, donc c'est "comme" si on tapait un programme. La mise en forme se fait via des balises comme en Rest avec des simplifications et des compléments. Une fois le document tapé, il devient via une compilation un document lisible par n'importe qui.
Mouais, je n'ai pas trop regardé comment se représentait autre chose que de l'ASCII sous ce format et une vague recherche "google" semblerait dire qu'on n'écrit pas en utf-8 mais en valeur du code point entre unicode: et .. style:Citation:
Envoyé par rambc
Mais je n'ai pas encore travaillé suffisamment sous ce format pour que ce soit "inquiétant": il y a certainement des solutions que j'ignore utilisée par des logiciels existants comme Sphynx ou autre qui 'traitent' ce format.Code:
2
3
4
5
6
7
8
9
10
- W