Détecter l'encodage d'un fichier texte [Résolu]

[Emcy]

bonjour,

Comment fait-on pour détecter l'encodage d'un fichier texte (AINSI, UTF-8, UCS-2 little/big endian) ?
Je programme en vb.net et j'ai posé la question sur le forum vb.net mais personne ne sait comment faire : c'est pourquoi je repose ma question ici...

[pseudocode]

Normalement, il y a au début du fichier un BOM (byte order mark), c'est à dire une séquence d'octets:

UTF8 : 3 premiers octets = EF BB BF
UTF-16/UCS-2 (big-endian) : 2 premiers octets = FE FF
UTF-16/UCS-2 (little-endian) : 2 premiers octets = FF FE
ASCII/AINSI : pas de BOM, directement le contenu.

[Emcy]

ok merci pour l'info, je vais pouvoir me débrouiller

[Jean-Marc.Bourguet]

Envoyé par Emcy

Comment fait-on pour détecter l'encodage d'un fichier texte (AINSI, UTF-8, UCS-2 little/big endian) ?

Il n'y a pas de methode universelle qui marche a tout les coups. Pour commencer,
le code ASCII est un sous-ensemble strict de pas mal de codes (en commencant par celui que tu appelles ANSI -- enfin, je suppose que AINSI est une faute de frappe, c'est un code que je ne connais pas -- et UTF-8).

Envoyé par pseudocode

Normalement, il y a au début du fichier un BOM (byte order mark), c'est à dire une séquence d'octets:

C'est pas normalement. C'est la convention utilisee par Windows, mais elle l'est rarement ailleurs parce qu'elle n'est pas sans probleme.

UTF8 : 3 premiers octets = EF BB BF
UTF-16/UCS-2 (big-endian) : 2 premiers octets = FE FF
UTF-16/UCS-2 (little-endian) : 2 premiers octets = FF FE
ASCII/AINSI : pas de BOM, directement le contenu.

Ca doit marcher assez bien sous Windows pour autant que tous les fichiers proviennent de Windows et d'une version localisee pour un pays bien couvert par CP1252 (nom plus correct pour le code que les gens appellent generalement ANSI). Si des fichiers proviennent d'Unix, il faut tenir compte que le BOM n'est generalement pas present et qu'en France on trouve deja un joyeux melange de ISO 8859-1 et ISO 8859-15 en plus d'UTF-8; par contre UTF-16 et UTF-32 doivent etre quasiment absent des fichiers. Pour les autres pays (aussi exotiques que la Grece ou la Russie -- pas necessairement Chine Japon Koree), ca se complique encore plus.

[pseudocode]

Envoyé par Jean-Marc.Bourguet

C'est pas normalement. C'est la convention utilisee par Windows, mais elle l'est rarement ailleurs parce qu'elle n'est pas sans probleme.

Non, ce n'est pas une convention de Microsoft mais une convention du Consortium Unicode (chapitre 16.8) pour identifier l'encodage des flux de données (fichier, stream, ...).

Pour une fois que Microsoft respecte une convention ou un standard.

[Jean-Marc.Bourguet]

Envoyé par pseudocode

Non, ce n'est pas une convention de Microsoft mais une convention du Consortium Unicode (chapitre 16.8) pour identifier l'encodage des flux de données (fichier, stream, ...).

Les choses sont à mon sens un peu plus complexe que ça. Unicode a prévu le BOM d'abord comme espace sans chasse insécable. Ensuite, dans le cadre de protocoles qui en avait besoin, on lui a donné la fonction d'indicateur d'ordre d'octet, par après on l'a utilisé comme indicateur de code et finalement classé obsolète sa fonction d'espace sans chasse insécable pour la donner à U+2060, le gluon de mot.

Mais la FAQ et le texte du standard me semble toujours aussi clair: le BOM
est à employer si
- le protocole l'impose (c'est, à ce que je comprends, le cas des fichiers textes de Windows -- mais voir plus bas)
- le protocole l'autorise; mais dans ce cas, l'absence n'indique pas qu'il ne s'agit pas de donnée en Uncode.
Et il faut faire attention à ne pas l'utiliser systématiquement:
- des protocoles (je crois qu'XML en fait partie) demandent à commencer en ASCII et contiennent par la suite une indication du code utilisé, code qui est un surensemble de l'ASCII (comme l'est UTF-8). Commencer alors par un BOM est problématique.

Pour une fois que Microsoft respecte une convention ou un standard.

Microsoft a décidé d'utiliser un BOM dans ses fichiers textes. C'est un choix compréhensible comme l'est le choix opposé de ne pas en utiliser un. Ca ne me gène pas.

Ce qui me gène, c'est quand les conséquences ne sont pas assumées jusqu'au bout: j'ai créé deux petits fichiers, qui commençaient bien par un BOM. Et je les ai copié avec

Code :

COPY /A F1.TXT+F2.TXT SUM.TXT

Résultat, le BOM de F2.TXT est présent au mileu de SUM.TXT, ce qui n'a pas lieu d'être quand on concatène des fichiers textes si le BOM n'est qu'un indicateur de code.

En fait, j'en suis à me demander si il y a bien une notion claire de ce qu'est un fichier texte sous Windows (il y a ce point, il y a aussi le problème de savoir si CR LF est une marque de fin de ligne ou un séparateur de ligne; un certain nombre de messages ici et ailleurs laissent penser qu'il s'agit d'un séparateur, mais pourquoi alors un CR LF n'est pas inséré avec la commande ci-dessus?)

[pseudocode]

Envoyé par Jean-Marc.Bourguet

Les choses sont à mon sens un peu plus complexe que ça. Unicode a prévu le BOM d'abord comme espace sans chasse insécable. Ensuite, dans le cadre de protocoles qui en avait besoin, on lui a donné la fonction d'indicateur d'ordre d'octet, par après on l'a utilisé comme indicateur de code et finalement classé obsolète sa fonction d'espace sans chasse insécable pour la donner à U+2060, le gluon de mot.

Je pensais que les développeurs ont utilisés la séquence FE FF comme identifiant little/big endian avant que le consortium ne règlemente son utilisation. Et que c'était pour cela que, plus tard, cette séquence fut répertoriée comme "caractère vide". Mais bon, je n'ai pas confirmation de cette rumeur.

Ce qui me gène, c'est quand les conséquences ne sont pas assumées jusqu'au bout: j'ai créé deux petits fichiers, qui commençaient bien par un BOM. Et je les ai copié avec

Code :

COPY /A F1.TXT+F2.TXT SUM.TXT

Résultat, le BOM de F2.TXT est présent au mileu de SUM.TXT, ce qui n'a pas lieu d'être quand on concatène des fichiers textes si le BOM n'est qu'un indicateur de code.

Ca conforte mon idée de "bidouille" de développeur qui a été règlementée plus tard car le caractère correspondant au BOM est un "vide". Donc meme s'il y a un second BOM au milieu du document (a cause de la concaténation) ca ne devrait pas gêner.

Il peut y avoir un problème si le BOM n'est pas le même, mais on peut imaginer un parser capable de s'adapter. Cependant le standard dit qu'on de doit pas changer l'encodage au milieu d'un document.



En fait, j'en suis à me demander si il y a bien une notion claire de ce qu'est un fichier texte sous Windows (il y a ce point, il y a aussi le problème de savoir si CR LF est une marque de fin de ligne ou un séparateur de ligne; un certain nombre de messages ici et ailleurs laissent penser qu'il s'agit d'un séparateur, mais pourquoi alors un CR LF n'est pas inséré avec la commande ci-dessus?)[/QUOTE]

[Emcy]

hello,

C'est bien beau tout ça mais au final je fais quoi moi ?

Comment déterminer l'encodage sans utiliser la BOM (pour le moment, je n'ai besoin pour mon application d'identifier que les formats UTF-8 et iso-8859-1... mais si j'avais une focntion qui ferait tout ça serait encore mieux) ?

[Jean-Marc.Bourguet]

Envoyé par Emcy

hello,

C'est bien beau tout ça mais au final je fait quoi moi ?

Comment déterminer l'encodage sans utiliser la BOM (pour le moment, je n'ai besoin pour mon application d'identifier que les formats UTF-8 et iso-8859-1... mais si j'avais une focntion qui ferait tout ça serait encore mieux) ?

La réponse complète va dépendre de ta plateforme. En gros, tu fais de la détection en utilisant le BOM mais en laissant a l'utilisateur un moyen de forcer le charset.

[Jean-Marc.Bourguet]

Envoyé par pseudocode

Ca conforte mon idée de "bidouille" de développeur qui a été règlementée plus tard car le caractère correspondant au BOM est un "vide". Donc meme s'il y a un second BOM au milieu du document (a cause de la concaténation) ca ne devrait pas gêner.

Il peut empecher la coupure de ligne a un endroit qui l'aurait permise.

Quant a la bidouille, si c'en est une, elle est la depuis la premiere fois que j'ai regarde les spec d'Unicode.

Mais vu la comprehension des problemes de charset par le programmeur median, la bidouille correspondant plus ou moins (avec justement tout les problemes causes parce que ce n'est pas exactement) avec la spec n'est pas a exclure.

[Emcy]

Envoyé par Jean-Marc.Bourguet

La réponse complète va dépendre de ta plateforme. En gros, tu fais de la détection en utilisant le BOM mais en laissant a l'utilisateur un moyen de forcer le charset.

=> ok, je vais essayer de faire ça. Merci

Remarque :
Je viens de regarder comment fait le logiciel NotePad++ sous windows pour identifier les formats d'encodage.
- si le fichier commence par FE FF => UCS-2 Big Endian
- si le fichier commence par FF FE => UCS-2 Little Endian
- si le fichier commence par EF BB BF => UTF-8
- si le fichier n'a pas de BOM => AINSI ou UTF-8 sans BOM
=> pour le dernier cas, a priori il recherche les caractères spéciaux (ex : ê) et en déduit si on est en AINSI ou en UTF-8 (s'il n'y a pas de caractères spéciaux alors il se met par défaut en AINSI) : vous savez comment identifier en fonction des caractères spéciaux le format ?
Voici les différents fichiers text avec les différents encodages avec lequels j'ai fait mes tests : http://cjoint.com/?bjrdIYXp1Q

[pseudocode]

En UTF-8, les caractères sont généralement codés sur 1, 2 ou 3 octets (ca peut être plus, mais c'est rare). Ce codage respecte les règles suivantes :

codage sur 1 octet : 0xxxxxxx
codage sur 2 octets : 110xxxxx 10xxxxxx
codage sur 3 octets : 1110xxxx 10xxxxxx 10xxxxxx

(représentation en binaire des octets. "x" signifiant valeur quelconque)


Il suffit de parcourir ton fichier pour voir si les règles sont respectées. Par exemple si un octet commence par 110????? alors l'octet suivant commence par 10??????.

A la première violation des règles, tu peux arreter de parcourir le fichier et décreter que ce n'est pas de l'UTF-8.

[Emcy]

Envoyé par pseudocode

En UTF-8, les caractères sont généralement codés sur 1, 2 ou 3 octets (ca peut être plus, mais c'est rare). Ce codage respecte les règles suivantes :

codage sur 1 octet : 0xxxxxxx
codage sur 2 octets : 110xxxxx 10xxxxxx
codage sur 3 octets : 1110xxxx 10xxxxxx 10xxxxxx

(représentation en binaire des octets. "x" signifiant valeur quelconque)


Il suffit de parcourir ton fichier pour voir si les règles sont respectées. Par exemple si un octet commence par 110????? alors l'octet suivant commence par 10??????.

A la première violation des règles, tu peux arreter de parcourir le fichier et décreter que ce n'est pas de l'UTF-8.

Et pour l'AINSI, c'est quoi les règles génériques (pour info) ?
le format iso-8859-1 c'est quoi exactement ? Est-ce un format à part entière ou est-ce un sous format de l'AINSI (j'ai l'impression que c'est un sous format car notepad++ ne fait pas la différence entre AINSI et iso-8859-1) ?

[Jean-Marc.Bourguet]

Envoyé par Emcy

Et pour l'AINSI, c'est quoi les règles génériques (pour info)?

Il n'y a pas de format AINSI. Comme je l'ai deja ecrit, il y a bien Windows-1252 (nom tel qu'enregistre a l'IANA) qui est un charset defini par Microsoft et que certains -- peut-etre imitant Microsoft? -- appellent ANSI (sans I apres le A) sans bonne raison a ma connaissance(*). L'enregistrement a IANA indique Windows Code Page 1252 et cp1252 comme autres noms, mais ne les a pas enregistre comme alias officiels. A ma connaissance, il n'est pas enregiste a l'International register of coded character sets.

Les caracteres de 0x00 a 0x1F sont des caracteres de commande. Les autres sont des caracteres graphiques. Generalement, si tu as autre chose que 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x1B comme caractere de commande, ce n'est pas un fichier texte mais un fichier binaire. Et 0x1A marque la fin logique du fichier sous Windows (voir ma remarque dans un autre message sur le manque d'homogeneite de comportement des programme Windows, meme en provenance de MS).

le format iso-8859-1 c'est quoi exactement ? Est-ce un format à part entière ou est-ce un sous format de l'AINSI (j'ai l'impression que c'est un sous format car notepad++ ne fait pas la différence entre AINSI et iso-8859-1) ?

C'est un charset normalise par l'ISO qui respecte la structure de code definie par d'autres normes ISO: ISO2022 et ISO4873. En simplifiant un petit peu, windows-1252 est une extension de ISO 8859-1 qui ne respecte pas la structure normalisee et defini comme graphique les caracteres de commande de la zone C1 (0x80 a 0x9F).


(*) Je suis en train d'ecrire un petit texte sur les charsets. Si quelqu'un a une explication sur ce nom, ca m'interesse. De meme, mon texte est encore incomplet et manque de pas mal de choses, mais si vous avez des commentaires constructifs, je suis preneur.

[pseudocode]

Envoyé par Emcy

Et pour l'AINSI, c'est quoi les règles génériques (pour info) ?

Si ce n'est pas de l'UTF-8, il y a de grande chance que ce soit de l'ASCII ou de l'ANSI ou de l'ISO.

Pour l'ASCII c'est facile : toutes les valeurs sont inferieure a 128, c'est à dire que tous les octets sont de la forme 0xxxxxxx. D'ailleurs les formats UTF-8, ANSI et ISO sont compatibles avec l'ASCII.

le format iso-8859-1 c'est quoi exactement ? Est-ce un format à part entière ou est-ce un sous format de l'AINSI (j'ai l'impression que c'est un sous format car notepad++ ne fait pas la différence entre AINSI et iso-8859-1) ?

ANSI : organisme de standardisation americain
ISO : organisme de standardisation international

Par abus de langage, cela designe les formats d'encodage issus de ces 2 orgranismes.

Pour ces deux formats, on ne peut pas savoir si c'est l'un ou l'autre, ni quelle variante. Ces deux format utilisent des tables pour transformer les valeurs (8/16 bits) en caractère graphique. Ces tables sont spécifiques à chaque alphabet/langue. Si on ne te dit pas quelle table est utilisée, tu ne peux pas le deviner à partir du fichier.

Par exemple, le symbole monétaire "euro" est codé par l'octet 128 en ANSI-1252, mais il est codé par l'octet 164 en ISO-8859-15.

Donc si tu rencontre l'octet 164 dans un fichier, c'est soit le symbole "euro" si tu es en ISO-8859-15, soit un symbole curieux si tu es en ANSI-1252.

[Jean-Marc.Bourguet]

Envoyé par pseudocode

ANSI : organisme de standardisation americain
ISO : organisme de standardisation international

Par abus de langage, cela designe les formats d'encodage issus de ces 2 orgranismes.

Est-ce que tu as la moindre indication que l'ANSI a participe a la definition de windows-1252 en tant que code different de ISO 8859-1? Si oui, tu peux me donner tes sources? (J'ai le vague souvenir d'avoir lu quelque part que Microsoft etait parti d'un brouillon de ISO 8859-1, avait ajoute des caractères dans l'espace C1 et le passage ISO->ANSI est du a la tendance bien connue des americains de s'attribuer le resultat du travail fait internationalement :-) mais je ne me souviens plus où et j'aimerais controler la fiabilite de cette info avant de la propager. Et dans cette version, je me demande par quel hasard ils sont arrive au choix definitif -- peut-etre que l'assignation a ete mise a jour?).

Edit: Unicode and Windows XP:

Envoyé par Cathy Wissink, Program Manager, Windows Globalization, Microsoft Corporation

The term “ANSI” as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft, which became ISO Standard 8859-1.

Elle a l'air de dire que le terme "ANSI" designe en fait les pages de code 8 bits de Windows (ou un sous-ensemble d'entre elles?) et pas uniquement la 1252.

[pseudocode]

Envoyé par Jean-Marc.Bourguet

Elle a l'air de dire que le terme "ANSI" designe en fait les pages de code 8 bits de Windows (ou un sous-ensemble d'entre elles?) et pas uniquement la 1252.

Voila ce que j'en sais. Je ne garantis en rien l'exactitude.

Au début il y avait le standard américain ASCII.

Et puis les non-americains ont décidé qu'ils voulaient pouvoir afficher les lettres non ASCII de leur alphabet, en utilisant les valeurs 128-255. Alors sont apparues les pagecodes OEM dépendant du BIOS (et donc du constructeur/pays). Ce sont les pagecodes qui sont utilisées par le DOS.

Puis est arrivé Windows qui par soucis d'harmonisation à voulu avoir une seule codepage "générique" quelque soit le constructeur/pays. Comme il n'y avait pas encore de standard, Microsoft s'est tourné vers l'institut ANSI et a pris un de leur draft (nom temporaire du draft: 1252). MS a finalisé le draft (en y ajoutant des caractères), l'a soumis à l'ANSI pour approbation et, sans attendre la réponse, l'à utilisé dans Windows.

Mais l'ANSI n'a pas approuvé les modifs. Donc la codepage de windows n'est pas un vrai standard ANSI mais une "finalisation" faite-maison par MS : la codepage windows-1252.

Par ailleurs, le draft de l'ANSI a été finalisé par l'ISO pour devenir le ISO-8859-1. Raison pour laquelle les 2 codepages se ressemblent, car ils ont la meme base (le draft 1252)

voila, c'est la rumeur que je connais.

[Jean-Marc.Bourguet]

Envoyé par pseudocode

Voila ce que j'en sais. Je ne garantis en rien l'exactitude.

Au début il y avait le standard américain ASCII.

Si tu as lu mon document, tu sais que ce n'est pas le début de tout, mais bon, on peut commencer à partir de là. Je complète avec ce que je crois savoir -- vu que je n'en suis pas encore là dans ma petite histoire.

Et puis les non-americains ont décidé qu'ils voulaient pouvoir afficher les lettres non ASCII de leur alphabet, en utilisant les valeurs 128-255. Alors sont apparues les pagecodes OEM dépendant du BIOS (et donc du constructeur/pays). Ce sont les pagecodes qui sont utilisées par le DOS.

Après l'ASCII, il y a eu ISO 646, reprenant en gros l'ASCII et définissant comment en faire des variantes nationales. Puis au début des années 70, ISO 2022 et ISO 4873 qui définissent des structures de codes et des mécanismes de codage permettant dans un même flux d'avoir plusieurs charset différents (la première version d'ECMA 35 -- nom ECMA d'ISO 2022 -- est de 71, la première version d'ECMA 43 -- nom ECMA d'ISO 4873 -- est de 74).

En plus de ça, effectivement ont foisonné les charsets 8 bits complétant l'ASCII. Une de ceux-ci est mis dans la ROM des PC (ce charset sera connu plus tard sous le nom CP 437, je crois me souvenir qu'il y a eu quelques versions localisées de PC ayant un autre charset en ROM, mais alors les PC, même capable d'exécuter DOS, n'étaient plus 100% compatible, critère très important à l'époque). En passant, Code Page est à ma connaissance de la terminologie IBM pour charset, et elle est utilisée aussi par Microsoft et quasiment personne d'autre. C'est avec la version 2.11 du DOS qu'est introduite la possibilité de changer de code page (ce n'est pas une possibilité du BIOS) dont la 850 conseillée pour l'europe occidentale. Les codes pages utilisées par le DOS sont souvent désignées collectivement sous le nom OEM (appellation qui n'a du sens que pour celle présente en ROM, donc généralement la 437).

Puis est arrivé Windows qui par soucis d'harmonisation à voulu avoir une seule codepage "générique" quelque soit le constructeur/pays. Comme il n'y avait pas encore de standard, Microsoft s'est tourné vers l'institut ANSI et a pris un de leur draft (nom temporaire du draft: 1252). MS a finalisé le draft (en y ajoutant des caractères), l'a soumis à l'ANSI pour approbation et, sans attendre la réponse, l'à utilisé dans Windows.

Mais l'ANSI n'a pas approuvé les modifs. Donc la codepage de windows n'est pas un vrai standard ANSI mais une "finalisation" faite-maison par MS : la codepage windows-1252.

Par ailleurs, le draft de l'ANSI a été finalisé par l'ISO pour devenir le ISO-8859-1. Raison pour laquelle les 2 codepages se ressemblent, car ils ont la meme base (le draft 1252)

voila, c'est la rumeur que je connais.

Quelques remarques.

La normalisation des ISO 8859 n'est pas ANSI puis ISO mais ISO puis organismes nationaux dont l'ANSI -- c'est d'abord des normes internationales comme le sont le C et le C++ par exemple et elles ont été établies par des comités internationaux. En prime, cette normalisation s'est faite sous le double auspice de l'ISO et de l'ECMA et l'ECMA me semble avoir joué un rôle moteur (en passant, je donne souvent des références ECMA car ses normes sont publiques et leur site http://www.ecma-international.org contient un certain nombre d'éditions qui ont été remplacées, par exemple ECMA 94, 1st edition).

J'ai du mal à penser que quelqu'un au courant des processus de normalisation aurait pu s'imaginer que l'ISO aurait pu accepter l'empiètement de la zone C1, cet empiètement ne pouvant pas être perçu comme un complément (la charte était de développer des charsets respectant les structures d'ISO 2022 et ISO 4873; ISO 2022 en particulier permettant d'intégrer plusieurs charsets définis séparément, ne pas respecter la structure est fortement problématique).

Windows-1252 et ISO 8859-1 font plus que se ressembler. Windows-1252 c'est ISO 8859-1 plus des caractères dans la zone C1 (ou ISO 8859-1 n'a rien, cette norme définissant GL et GR et il faut convernir par ailleurs de la norme définissant C0 et C1) Et à propos de cette convergence parfaite dont je m'étonnais, j'ai été recherché un bouquin de 91 sur Windows, sa description du jeu ANSI diffère au moins (la fonte est mauvaise) en 2 caractères par rapport à la version actuelle. Mais ces deux caractères ne sont pas définis dans la version de 85 d'ECMA 94 (version ECMA d'ISO 8859). Et il n'y a que 2 caractères dans la zone C1, contre a peu près 30 maintenant. Windows-1252 est un charset qui évolue toujours.

Mais bon, je doute qu'Emcy voulait un cours sur l'histoire des charsets.

[pseudocode]

Envoyé par Jean-Marc.Bourguet

Mais bon, je doute qu'Emcy voulait un cours sur l'histoire des charsets.

En tout cas, moi, ça m'a bien plut. Je trouve assez intéressant ces recherches sur les bases de l'informatique actuelle. Ca à un petit coté Indiana Jones.

Qui sait ce que les futurs générations diront sur la naissance du Web.

[souviron34]

oui, très intéressant

Je rajouterais d'ailleurs un truc : dès 1988 et la publication du bouquin de Gettys, Newman et Scheifler sur XWindow, (X Window System), les charsets étaient définis avec des noms repris ensuite par ISO : Latin1 KEYSYM set, Kana KEYSIM set, arabic KEYSIM set, ...

le MIT, AT&T, DEC, SUN, IBM, HP, et ette équipe avait fait un super bon boulot...