Discussion :

[saad.hessane]

Bonjour tout le monde.
J'espère que je ne pose pas une question triviale. Mais je vous assure que j'ai chercher (certainement mal). Je poste aussi dans le forum C++, car j'ai du mal à trouvé ou poser cette question.
Quand on ouvre un fichier .txt, l'éditeur sait automatiquement qu'il est au format ASCII ou UTF. Comment ça se fait? Je parle au niveau physique. Y a t il un entête dans le fichier? Si oui pourquoi n'est il pas comptabilisé dans la taille du fichier. Serait-ce gérer par le système de fichier?
Merci d'avance.

[metagoto]

UTF-8 est backward compatible avec ASCII. Les unités de codage sont de simples words de 8 bits (octets). Le range ASCII 0x00-0x7F est encodé tel quel avec UTF-8. Les caractères en dehors de ASCII seront codés avec une séquence de 2 à 4 octets. Les bits prépondérants du premiers octets vont indiquer combien d'octets sont nécessaires pour coder le caractère:
0 -> 1 octet
110 -> 2 octets dans la séquence
1110 -> 3 octets
11110 -> 4 octets
On remarque que c'est indépendant d'une convention d'endianness
Un éditeur text (ou n'importe quel prog) qui est UTF-8 aware va savoir comment gérer la chaîne d'octets qu'on lui donne.

C'est moins le cas pour UTF-16 ou 32. Là, les words sont de 16 ou 32 bits.
Alors qu'en UTF-8 un caractère est codé sur 1 à 4 octets, on en aura 2 ou 4 pour UTF-16 et toujours 4 pour UTF-32. On se retrouve avec des 0x00 insérés pour avoir le bon padding de 2 ou 4 octets. De plus, ça dépend de l'endianness (big endian ou little endian). C'est pourquoi UTF-16 ou 32 sont rarement utilisés en dehors des mécanismes particuliers d'une application (UTF-16 est utilisé en interne par pas mal de systèmes: Windows, Qt, python, libxml..)
Le fameux BOM (Byte-order mark) vient pallier à ce problème d'endianness pour les fichiers texts: c'est le caractère unicode U+FEFF inséré en tout début de chaîne (fichier) et qui, selon son codage, indiquera si on est en big ou little endian. par exemple en UTF-32:
00 00 FE FF -> big endian
FF FE 00 00 -> little endian
Donc quelque part, le BOM sert d'entête dans le fichier. Surtout sous Windows d'ailleurs (regarde avec notepad) parceque les systèmes POSIX préfèrent manipuler du UTF-8: c'est compatible avec ASCII, y a pas besoins de BOM, ça marche bien (pas de 0x00 intempestifs) et ça prend moins de place en moyenne pour un range ASCII-latin.

ref
http://www.unicode.org/faq/utf_bom.html
http://www.cl.cam.ac.uk/~mgk25/unicode.html
http://en.wikipedia.org/wiki/UTF-8 (et tous les liens internes)

PS: l'utilisateur loufoque sur ce forum saura bien mieux répondre que moi à toute cette machinerie unicode

[saad.hessane]

Merci beaucoup metagoto pour la réponse.
Maintenant si j'enregistre un fichier UTF, et que je l'ouvre à nouveau, l'éditeur va essayer de voir si le code ressemble à de l'UTF ou de l'ASCII. C'est ça?
Mais si c'est cela, si le document est écrit entièrement avec des caractères codés sur 8 bits, ça sera codé comme de l'ASCII, comment l'éditeur fera t il la différence?
Encore merci

[metagoto]

Si tous les bytes (octets) sont dans le range 0x00 et 0x7f, alors il n'y a pas de différences: c'est ascii et utf-8 à la fois.
La où ça devient intéressant c'est qu'il y a des séquences de bytes qui ne peuvent jamais être du utf-8 valide. En effet, si je reprends l'exemple d'une séquence utf-8 de 3 bytes. Le premier:
1110 -> indique le début d'une séquence de 3 bytes
Les 2 bytes suivants commencent toujours par 10. C'est aussi valable pour les autres séquences (2 ou 4 bytes).
On ne peut donc pas avoir, par exemple:
1110xxxx 0xxxxxxx 1111111x
Donc là un éditeur text il fait quoi ? Y a des chances qu'il se rabatte sur de l'iso-8859-N (latin1 etc) où tout le range 0x00-0xff est utilisé, mais où tous les caractères sont codés sur un seul byte.

Les navigateurs web par exemple, en l'absence de header content-type vont essayer de deviner l'encoding utilisé en regardant les séquences qui commencent par un 8th bit à 1.

[Médinoc]

Évidemment, parfois, l'éditeur se trompe en cherchant des correspondances.

En effet, un texte en pur ASCII et un fichier UTF-16 sans BOM peuvent tout-à-fait avoir la même représentation, alors il faut deviner, avec des heuristiques.

Et quand l'heuristique se trompe, ça mène à des problèmes comme le fameux Bush hid the facts.

[saad.hessane]

Merci beaucoup à vous, vous répondez totalement à ma question.