Discussion :

[PeD012]

Bonjour,

Je dois avouer que je ne sais trop dans quel forum poster mon problème.
Comme il s’agit d’un problème rencontré en VB, je le poste donc ici.

Description

J’ai deux fichiers textes à comparer en VB.

L’un, ALPHA, commence par les caractères EF BB BF ce qui je suppose le caractérise comme UTF8.
L’autre OMEGA n’a rien en préfixe. Ce qui en fait un ASCII pur ?

La lecture par VB via LineInput semble se passer bien, et VB tient compte de ce décalage de 3 positions. Cela ne semble pas faire de problème.

A un endroit du fichier, je compare le nom LAVALLÉ avec un accent aigu sur le E.

Quand je vais voir en hexa dans le fichier ALPHA (UTF8 ) il y a
4C 41 56 41 4C 4C C3 89 où le C3 89 représente le É.

Quand je vais voir en hexa dans le fichier ALPHA (ASCII) il y a
4C 41 56 41 4C 4C C9 où le C9 représente le É

A la comparaison If .. = ... en VB, le programme pointe cela comme une différence. Pour moi c’est bon.
Et écrit cette différence dans un fichier rapport OCMP001D de type texte.

Voici comment VB écrit dans ce fichier :

Pour ce qui vient de ALPHA ( UTF8 ) :
4C 51 56 41 4C 4C C3 83 E2 80 B0 où le É est devenu C3 83 E2 80 B0
ouaahh tant de caractères pour juste C3 89

Pour ce qui vient de OMEGA ( ASCII ) :
4C 41 56 41 4C 4C C3 83 C6 92 C3 A2 E2 82 AC C2 B0 où le É est
devenu C3 83 C6 92 C3 A2 E2 82 AC C2 B0
re-ooouuuahhhhh record du monde battu 11 caractères pour le seul C9
( d'ailleurs 11 caractères est un nombre bizarre : pas un nombre pair ?? pourtant c'est bien cela ).

Oh simplicté quand tu nous tiens !!

Alors quand j'édite le fichier, je reçois
LAVALLÉ ( <---> | LAVALLÉ (


Comment gérer cela s’il vous plait, je croule sous les caractères, moi !!!

Merci de m’éclairer.

Pierre

[tomlev]

L’un, ALPHA, commence par les caractères EF BB BF ce qui je suppose le caractérise comme UTF8.

Oui

L’autre OMEGA n’a rien en préfixe. Ce qui en fait un ASCII pur ?

Pas forcément. Un fichier encodé en UTF-8 peut inclure le "byte order mark" (les 3 octets que tu mentionnes plus haut), mais ce n'est pas obligatoire. Et dans ce cas tu ne peux pas vraiment savoir... en général on considère que c'est au programme qui utilise le fichier de savoir quel encodage utiliser. Sinon, il est possible de "deviner" l'encodage utilisé d'après les caractères rencontrés dans le fichier (la plupart des éditeurs de texte le font), mais c'est compliqué...

Soit dit en passant, si ce n'est pas de l'UTF-8, ce n'est sûrement pas de l'ASCII : le jeu ASCII ne comporte que 128 caractères, et aucun n'est accentué. Par contre c'est peut-être de l'ISO-8859-1 (aussi appelé Windows-1252 ou ANSI, bien que ce ne soit pas tout à fait pareil)


Le plus simple est que tu ouvres le fichier dans un éditeur de texte avancé (Notepad2 ou Notepad++ par exemple), il t'indiquera l'encodage dans la barre de statut.

La lecture par VB via LineInput semble se passer bien, et VB tient compte de ce décalage de 3 positions. Cela ne semble pas faire de problème.

LineInput ? Tu es sûr que c'est bien du VB.NET, et pas du VB6 ou VBA ? Normalement on n'utilise plus LineInput en VB.NET, on utilise la classe StreamReader.

Quand je vais voir en hexa dans le fichier ALPHA (ASCII) il y a
4C 41 56 41 4C 4C C9 où le C9 représente le É

Comme je le disais, c'est de l'ISO-8859-1

A la comparaison If .. = ... en VB, le programme pointe cela comme une différence. Pour moi c’est bon.
Et écrit cette différence dans un fichier rapport OCMP001D de type texte.

FileOpen/LineInput ne permettent pas de spécifier l'encodage, c'est pourquoi il faut utiliser StreamReader...

[PeD012]

Merci pour les réponses.

Juste une mise au point.
J'utilise bine LineInput car d'abord débutant c'est ce que j'utilisais en VB6.
Je n'ai jamais créé énormément de programmes en VB6 mais seulement des costauds.

Malgré cela, je ne comprends pas par quel mécanisme il y a cette transformation de caractères.

Néanmoins je vais remplacer mes LineInput par des streamreader ( et streamwriter ) et voir si là le comportement est différent.
( Note : sans avoir regardé de plus près encore, il me semblait aussi que la gestion de fin de fichier est traitée différemment avec le LineInput ou avec le StreamReader - cela m'avait arrêté - car je manquais de temps pour voir la théorie ).
J'ai cru comprendre entre les lignes qu'il y aurait moyen de donner des options à l'open?? Je vais voir la doc.

Sinon, il est possible de "deviner" l'encodage utilisé d'après les caractères rencontrés dans le fichier (la plupart des éditeurs de texte le font), mais c'est compliqué...

Cela doit être possible, et cela ne m'effraie pas. Sans prétention, mais j'ai quelques millions de lignes de programmation dans ma P.... de vie d'informaticien, mais merveilleuse vie d'informaticien, qui est suffisamment longue pour que je porte un Tshirt avec un beau dinausore dessus.

Au travail donc !!
Je reviendrai sans doute avec mes conclusions.

Pierre

[tomlev]

Malgré cela, je ne comprends pas par quel mécanisme il y a cette transformation de caractères.

Bah c'est juste que les caractères sont encodés différemment dans les 2 fichiers... En UTF-8, le nombre d'octets occupés par un caractère est variable (de 1 à 6 octets), alors qu'en ISO il est fixe (1 octet). Par exemple 'é' occupe 2 octets en UTF-8.

Néanmoins je vais remplacer mes LineInput par des streamreader ( et streamwriter ) et voir si là le comportement est différent.

Si tu ne précises pas l'encodage, ça ne résoudra rien : par défaut StreamReader utilise UTF-8. Si tu sais que le fichier OMEGA est en ISO, il faut préciser Encoding.Default dans le constructeur.

( Note : sans avoir regardé de plus près encore, il me semblait aussi que la gestion de fin de fichier est traitée différemment avec le LineInput ou avec le StreamReader - cela m'avait arrêté - car je manquais de temps pour voir la théorie ).

StreamReader.ReadLine renvoie null (Nothing) quand tu es arrivé à la fin du fichier, il n'y a pas besoin d'une fonction "EOF"