Discussion :

[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]

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).

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]

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]

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 :

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

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]

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 :

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

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]