Affichage contradictoire sur l'encodage avec Vim et la commande file -i

Version imprimable

10/10/2022, 10h44
zephyre

Affichage contradictoire sur l'encodage avec Vim et la commande file -i

Bonjour,

Afin de connaitre l'encodage d'un fichier, j'ai fait une recherche sur internet et je suis tombé la dessus : https://www.shellhacks.com/linux-che...file-encoding/
La commande qui permet donc de connaitre l'encodage d'un fichier est donc file -i <nom_du_fichier>
Mon Vim est configurer en encodage UTF-8.
J'ai ajouté cette ligne dans ~/.vimrc :

Code:

set encoding=utf-8

Je produit un fichier toto.txt en ligne de commande :

Code:

vim toto.txt

Je sauvegarde le fichier.
Lorsque je reviens dans le shell (bash) et que je tape la commande suivante :

Code:

file -i toto.txt

J'obtiens le résultat suivant :

Code:

toto.txt: text/plain; charset=us-ascii

Es ce que vous avez une explication, je ne sais pas si le fichier est encodé en UTF-8 ou bien en us-ascii ?
10/10/2022, 11h11
disedorgue

Bonjour,

Pour reconnaitre si un fichier est en UTF8 ou autre, il faut avoir dans le fichier des caractères qui sortent de la zone ascii en général, donc si tu n'as aucun caractères du genre accentué ou autre qui n'est pas ascii, tu ne peux pas le savoir.

Il y a une exception qui est le bom (byte order mark) unicode qui est positionné en début de fichier texte pour dire que l'on est en unicode (entre chose) mais personnellement, je le déconseille car il y a encore des outils qui ne savent pas le gérer.
10/10/2022, 16h32
N_BaH

Citation:

Envoyé par disedorgue

Pour reconnaitre si un fichier est en UTF8 [...]si tu n'as aucun caractères du genre accentué ou autre qui n'est pas ascii, tu ne peux pas le savoir.

question : un fichier sans un caractère accentué peut-il être en UTF8 ? pour gérer les alphabets non romain ?
10/10/2022, 17h08
disedorgue

Citation:

Envoyé par N_BaH

question : un fichier sans un caractère accentué peut-il être en UTF8 ? pour gérer les alphabets non romain ?

Oui, d'où l'expression "genre accentué" et non ascii.
22/10/2022, 01h07
zephyre

Bonjour,

Merci pour vos précisions.
Effectivement j'ai ajouté un seul caractère accentué dans mon fichier toto.txt
Et j'ai effectivement cette fois ci le charset=utf-8
Je ne sais pas comment fonctionne la commande file -i, mais vraiment ça induit en erreur.
On pourrait penser que le fichier est codé en ASCII alors qu'il est bien codé en UTF8.

Je suis également allé sur cette page = https://vimhelp.org/mbyte.txt.html#encoding-names
Pour voir les différentes valeurs possibles pour l'encodage de caractères de Vim.
J'ai testé latin1.
Dans cet encodage alors ça me parait un peu bizarre mais bon impossible de taper le caractère accentué = 'é'
Lorsque j'appuie sur la touche avec mon clavier sur la touche correspondant au caractère = 'é', à la place j'ai une sorte de point d'interrogation centré à l'intersection des diagonales d'un losanges (milieu),
alors que le caractère = 'é' est bien un caractère latin.

J'ai une dernière question ici
22/10/2022, 01h07
zephyre

Bonjour,

Merci pour vos précisions.
Effectivement j'ai ajouté un seul caractère accentué dans mon fichier toto.txt
Et j'ai effectivement cette fois ci le charset=utf-8
Je ne sais pas comment fonctionne la commande file -i, mais vraiment ça induit en erreur.
On pourrait penser que le fichier est codé en ASCII alors qu'il est bien codé en UTF8.

Je suis également allé sur cette page = https://vimhelp.org/mbyte.txt.html#encoding-names
Pour voir les différentes valeurs possibles pour l'encodage de caractères de Vim.
J'ai testé latin1.
Dans cet encodage alors ça me parait un peu bizarre mais bon impossible de taper le caractère accentué = 'é'
Lorsque j'appuie sur la touche avec mon clavier sur la touche correspondant au caractère = 'é', à la place j'ai une sorte de point d'interrogation centré à l'intersection des diagonales d'un losanges (milieu),
alors que le caractère = 'é' est bien un caractère latin.

Juste une dernière question :
Supposons que j'ai un fichier source écris en langage C que j'appelle fichier_source.c
Ce fichier est encodé en ASCII.
Je le compile et j'obtiens un fichier binaire que j'appelle fichier_cible.obj
Je ne sais pas exactement comment fonctionne un compilateur alors je préfère demandé :
Es t'il possible d'avoir des caractères propres à l'UTF-8 lorsque j’exécute fichier_cible.obj ?
Je pense que la réponse à cette question est évidement oui.
Mais je ne comprends pas comment le compilateur fait.
En ASCII tout est codé sur 8 bits donc au niveau du fichier source, donc il est parsé par mot de taille de 8 bits.
Donc normalement au niveau du fichier cible tout est également parsé sur 8 bits ?
Pour maintenir la compatibilité des programmes il est évident que l'encodage ASCCI C UTF-8 (est inclut) peut être pas sur la même taille de mot mais sûrement au niveau de la valeur, exemple A = 0000 0001 en ASCII et 0000 0000 ... 0001 en UTF-8
A moins qu'on est un mécanisme possible d'échappement comme avec le caractère '\' en langage C ce qui permettrai de changer temporairement l'encodage, le parsage.
Je vois que ça de possible.
22/10/2022, 04h19
foetus
Je ne pense pas que le sujet est 1 rapport avec le C, mais bon je vais répondre :mrgreen:

Actuellement, il y a 3 - 4 encodages qu'on utilise le + : ASCII, MBCS (latin-1, latin-9, Shift-JIS, ... les code pages), et l'Unicode avec UTF-8 et UTF-16.
En C, 1 caractère est de type soit char (1 valeur soit signée entre -128 et 127, soit non signée entre 0 et 255) soit wchar_t (1 valeur sur 16 bits, 2 octets)

Pour ton caractère 'é', c'est très simple, la valeur est
- en latin-1, 0xE9. Regarde la page wikipedia pour la table. Tu as 1 table par code page, c'est le problème
- en UTF-8, 0xC3 0xA9
- en UTF-16, 0x00 0xE9
- en ASCII, il n'existe pas.
Utilise 1 site qui convertit les caractères comme r12a >> apps >> Unicode code converter par exemple (<- lien)

Donc, tu vois bien qu'1 encodage c'est très "virtuel", parce que si tu as 1 "caractère" (1 valeur), il te faut obligatoirement l'encodage pour le comprendre, sinon ton texte peut être illisible.
1 encodage c'est juste 1 table de caractères qui associe 1 caractère à 1 valeur ("codepoint" pour le terme technique).
L'Unicode est juste 1 grosse table qui représente TOUS les caractères alors que MBCS ce sont juste 1 table pour 1 langue précise.

Pour le MBCS, l'idée est de remplir les 127 valeurs libres de l'ASCII (c'est 128 valeurs, codé sur 7 bits). Mais certains "code pages" sont sur 16 bits (2 octets) comme le Shift-JIS.
ASCII ne contient que les caractères "américains" : pas d'accents, pas de lettres spéciales (comme le le tilde espagnol ou le o barré), ...
ANSI est 1 "code page" spécial de Microsoft. C'est le "code page" par défaut de Windows, mais différent en fonction des pays. En France c'est le Windows-1252

Pour l'UTF-8, il est compatible ASCII : c'est à dire que toutes les valeurs ASCII (de 0 à 127) sont identiques en UTF-8.
En UTF-16, l'ASCII est toujours précédé par 1 zéro (c'est 1 encodage sur 16 bits) : 0x00 0xYY (c'est d'ailleurs pour cela que si tu enregistres 1 texte ASCII en UTF-16, tu vas voir des 0 à chaque caractère :mrgreen:)

Pour l'explication technique sur l'UTF-8, regarde la page wikipedia.
1 caractère UTF-8 est codé sur 1, 2, 3 ou 4 octets. Et ce sont les bits les + à gauche qui disent le nombre d'octets : 0, 1 octet. 11, 2 octets. 111, 3 octets. 1111, 4 octets.
Comme la valeur d'1 caractère ASCII est toujours codé sur 7 bits, le 8ième octet est toujours 0.
C'est d'ailleurs pour cela que l'UTF-8 n'est pas apprécié : c'est 1 encodage qui est pénible à découper parce qu'il faut lire les caractères.
UTF-16 et UTF-32 sont des encodages fixes de 16 ou 32 bits.

Après l'UTF-16 est mauvais parce que sous Windows c'est 2 octets (16 bits) et sous Linux 4 octets (32 bits) pour 1 histoire de "plan"/ "surrogates".
C'est pour cela que rien que pour l'UTF-16, 1 type caractère long spécifique a été créé : wchar_t.

Pour ta question, en C (et autres langages), tu as l'échappement des caractères : \xhh, \uhhhh (code point Unicode en dessous de 10000 hexadecimal), \Uhhhhhhhh.
Regarde la table des échappements sur wikipedia

Donc pour ton caractère 'é', en C :
- en UTF-8, char c[2] = "\xC3\xA9"; (ou char c[2] = {0xC3, 0xA9};)
- en UTF-16, wchar_t c = L'é'; (ou wchar_t c = '\u00E9';) avec l'entête wchar.h

Citation:

Envoyé par zephyre

Effectivement j'ai ajouté un seul caractère accentué dans mon fichier toto.txt
Et j'ai effectivement cette fois ci le charset=utf-8
Je ne sais pas comment fonctionne la commande file -i, mais vraiment ça induit en erreur.
On pourrait penser que le fichier est codé en ASCII alors qu'il est bien codé en UTF8.

Oui mais non, ou plutôt non mais oui!

Comme l'a bien dit foetus: "Pour l'UTF-8, il est compatible ASCII : c'est à dire que toutes les valeurs ASCII (de 0 à 127) sont identiques en UTF-8."

Donc, si un fichier ne contient aucun caractère accentué, c'est-à-dire qu'il ne contient que des caractères ASCII, alors "file" le considère comme un fichier ASCII. Normal !

En fait, ASCII est un sous-ensemble de UTF-8. Donc un fichier ASCII peut très bien être considéré comme un fichier UTF-8... ne contenant aucun caractère accentué!

Mais "file", en disant que c'est de l'ASCII est plus précis que s'il disait que c'est de l'UTF-8.

C'est comme si tu me demandais quel animal c'est et que je te réponds "un labrador". C'est plus précis que si je te dis "un chien" ou "un animal". Évidemment, il faut savoir qu'un labrador est un chien, comme il faut savoir qu'un ASCII est un UTF-8...

Si, dans ton fichier ASCII, tu rajoutes un 'é' codé en UTF-8, alors "file", qui fait bien son boulot verra que ce n'est plus un fichier ASCII "pur", car il contient un truc qui n'est pas de l'ASCII, il reconnaitra que c'est un caractère UTF-8 et te dira donc que c'est un fichier codé en UTF-8.

De la même manière, si tu avais rajouté un 'é' codé en ISO-8859-1 (très courant en France), alors "file", qui fait bien son boulot aurait vu que ce n'est plus un fichier ASCII, car il contient un truc qui n'est pas de l'ASCII, il reconnaitra que c'est un caractère ISO-8859-1 et te dira donc que c'est un fichier codé en ISO-8859-1.

Il m'est arrivé, lors d'une mauvaise manip de "cat" avec des fichiers encodés différemment, d'avoir, dans le même fichier, à la fois des caractères codés en UTF-8 et d'autres codés en ISO-8859-1. Dans ce cas, l'algorithme de "file", qui est une heuristique, a du mal à donner un résultat cohérent:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 $ echo $LANG fr_FR.UTF-8 $ echo 'çà et là, cet été' > celce-utf-8.txt $ file celce-utf-8.txt celce-utf-8.txt: UTF-8 Unicode text $ od -cx celce-utf-8.txt 0000000 ç ** à ** e t l à ** , c e t a7c3 a0c3 6520 2074 c36c 2ca0 6320 7465 0000020 é ** t é ** \n c320 74a9 a9c3 000a 0000027 $ iconv -f UTF-8 -t ISO8859-1 celce-utf-8.txt > celce-iso8859-1.txt $ file celce-iso8859-1.txt celce-iso8859-1.txt: ISO-8859 text $ od -cx celce-iso8859-1.txt 0000000 347 340 e t l 340 , c e t 351 t e0e7 6520 2074 e06c 202c 6563 2074 74e9 0000020 351 \n 0ae9 0000022 $ cat celce-utf-8.txt celce-iso8859-1.txt > celce-mix.txt $ file celce-mix.txt celce-mix.txt: ISO-8859 text $ od -cx celce-mix.txt 0000000 ç ** à ** e t l à ** , c e t a7c3 a0c3 6520 2074 c36c 2ca0 6320 7465 0000020 é ** t é ** \n 347 340 e t l 340 , c320 74a9 a9c3 e70a 20e0 7465 6c20 2ce0 0000040 c e t 351 t 351 \n 6320 7465 e920 e974 000a 0000051 $ cat celce-mix.txt çà et là, cet été ?? et l?, cet ?t?
Au passage, on note aussi que:
Code:

1 2 3 4 5 6 % echo 'AB' | od -cx 0000000 A B \n 4241 000a % echo ' AB ' | od -cx 0000000 A B \n 4120 2042 000a
Sachant, cher sachem, que A (41) est bien avant B (42)... Une question de petit Sioux ou de grand Cheyenne, mais c'est une autre histoire...

22/10/2022, 10h25
Flodelarab

:roll: Qu'est-ce qu'il est près de ses sioux celui-là !
:dehors:
31/10/2022, 22h02
Sve@r

Bonjour

Citation:

Envoyé par zephyre

Juste une dernière question :
Supposons que j'ai un fichier source écris en langage C que j'appelle fichier_source.c
Ce fichier est encodé en ASCII.
Je le compile et j'obtiens un fichier binaire que j'appelle fichier_cible.obj
Je ne sais pas exactement comment fonctionne un compilateur alors je préfère demandé :
Es t'il possible d'avoir des caractères propres à l'UTF-8 lorsque j’exécute fichier_cible.obj ?
Je pense que la réponse à cette question est évidement oui.
Mais je ne comprends pas comment le compilateur fait.
En ASCII tout est codé sur 8 bits donc au niveau du fichier source, donc il est parsé par mot de taille de 8 bits.
Donc normalement au niveau du fichier cible tout est également parsé sur 8 bits ?
Pour maintenir la compatibilité des programmes il est évident que l'encodage ASCCI C UTF-8 (est inclut) peut être pas sur la même taille de mot mais sûrement au niveau de la valeur, exemple A = 0000 0001 en ASCII et 0000 0000 ... 0001 en UTF-8
A moins qu'on est un mécanisme possible d'échappement comme avec le caractère '\' en langage C ce qui permettrai de changer temporairement l'encodage, le parsage.
Je vois que ça de possible.

La classification "ascii"/"utf" ne s'applique qu'à des fichiers textes (plus explicitement "human readable"). Un binaire ce n'est plus de l'ascii ou utf ou isoX, c'est juste du binaire.
Plus explicitement: tu affiches un 'A', ton source sera fputc('A', stdout). En assembleur ce sera un truc imbitable style .mov 0x41 0xff et en binaire ce sera peut-être 00 41 ED 41 FF.
Le premier "41" du binaire représente là un ordre, et le second "41" représente le caractère 'A' (merci jack-ft, je n'ai pas eu à me casser la tête pour trouver ma valeur :D). Il n'est nulle-part question d'ascii ici.
Et si on applique à l'utf, alors tu veux afficher 'é', ton source sera fputc('é', stdout). En assembleur ce sera un truc imbitable style .mov 0xc3 0xa9 0xff et en binaire ce sera peut-être 00 41 ED C3 A9 FF. Et là encore on ne parle plus d'encodage. Le 0xc3 0xa9 du "é" utf-8 est devenu deux octets à suivre sans aucun lien entre eux en binaire.
C'est ensuite, quand le 0xc3 0xa9 arriveront à l'écran que là le driver écran se dira "oh oh, ces deux trucs ils vont ensembles donc je vais les accoler et montrer le résultat".

L'encodage c'est juste la retranscription humaine d'une valeur binaire. Si le truc n'est pas lu par un humain, ça n'a aucun sens.

Citation:

Envoyé par jack-ft

C'est comme si tu me demandais quel animal... c'est plus précis que si je te dis "un chien" ou "un animal".

Surtout que répondre "c'est un animal" à la question "quel animal" ça fait pas vraiment avancer le schmilblik :D
01/11/2022, 15h56
zephyre

Je vous remercie pour vos précisions chacun d'entre vous même si j'ai pas tout compris.
Je n'ai pas compris par exemple pourquoi l'encodage est dit "virtuel".
Je retiens que l'encodage ASCII C (est inclut) UTF-8. Ainsi si j'ai un fichier encodé en ASCII et que je passe en UTF-8 => aucun problème à l'horizon.
UTF-8 peut être codé sur 1,2,3, ou 4 octet, donc c'est une taille de mot variable.
Et que la taille de l'encodage du caractère est indiqué dans les bits de poids faibles.
Je pense que ça suffira dans ma pratique au quotidien, même si je suis loin d'en avoir saisi toutes les subtilités.
Merci encore pour vos précisions.
Je clos le sujet.
01/11/2022, 16h31
Sve@r

Citation:

Envoyé par zephyre

Je n'ai pas compris par exemple pourquoi l'encodage est dit "virtuel".

Je pense que foetus n'a pas trouvé le bon terme. Peut-être que le terme "traduction" aurait été plus adapté...

Citation:

Envoyé par zephyre

Je retiens que l'encodage ASCII C (est inclut) UTF-8.

Comme ascii est plus ancien, moi j'aurais dit que l'utf-8 était une évolution.
C'est un peu pareil avec les maths. Au début de son histoire, les proto-humains conceptualisaient péniblement la numérotation simple (un coquillage, deux femmes, trois bananes, etc, d'ailleurs leur numérotation s'arrétait à 1, 2, 3, beaucoup) => d'où la notion de nombres entiers dit "naturels", parce que présents dans la nature. Puis il a fallu conceptualiser la notion de "dette" (parce que celui qui a 5 coquillages mais qui en doit 4 est moins riche que celui qui en a juste 2). De là sont arrivés les nombres relatifs (lesquels englobent les naturels tout en leur rajoutant des nombres "non-naturels" parce que placés avant le 0). Puis les grecs, fanas de divisions (ils divisaient leurs ennemis en 2), ont voulu conceptualiser la notion de "demi" ("hey Ionysos, tu me sers un demi") et de là sont arrivés les fractions, qui englobent les naturels (parce que si on compte les oreilles et qu'on divise par 2 on a bien un nombre de têtes entières) et les relatifs. Et etc où chaque nouveau groupe numérique englobe toujours le groupe précédent.
Donc pareil, tu as l'ascii, et l'utf-8 qui englobe l'ascii plus les caractères non-ascii.

Citation:

Envoyé par zephyre

Ainsi si j'ai un fichier encodé en ASCII et que je passe en UTF-8 => aucun problème à l'horizon.

Absolument aucun. D'ailleurs, avec les éditeurs actuels, les fichiers sont tous en utf-8 par défaut.
05/11/2022, 10h28
jack-ft

Je voudrais pas chipoter (enfin, si, quand même un peu..) mais jusqu'aux grecs, je suis à peu près d'accord.

Mais, d'après ce que j'ai lu, il semble que:

Citation:

Envoyé par Benoit Rittaud p37

Pour les mathématiciens grecs de l'antiquité, seuls ont droit au titre de nombre les entiers positifs, à l'exclusion du zéro (inventé en Inde au VIIe siècle de notre ère) et... du un, au moins pour les premiers pythagoriciens, au motif que l'unité est ce qui engendre les nombres et non un nombre elle-même.

Les quantités fractionnaires, quant à elles, comme 1/2 ou 3/4, sont vues comme des rapports entre nombres (NdM: et non comme des nombres fractionnaires).

L'absence de concept clair et de notation symbolique pour les fractions rend les énoncés assez lourds:
pour exprimer une égalité aussi simple que 3/4 = 6/8, les Grecs doivent écrire quelque chose comme "3 est à 4 ce que 6 est à 8".

Plutôt que d'envisager, comme nous le faisons, les rapports 3/4 et 6/8 comme deux représentations interchangeables d'un même objet (que, nous, nous qualifions de nombre), les mathématiciens de la Grèce antique considèrent la séquence 3, 4, 6 et 8 comme un tout, une "proportion".

En revanche, si on considère la tablette babylonienne YBC 7289, datée d'entre 1900 et 1600 avant notre ère (soit plus de 1000 ans avant Pythagore), elle contient clairement, le long de la diagonale d'un carré, le "nombre", écrit avec des "clous" dans la notation babylonienne, et que nous représentons par 1;24,51,10, c'est-à-dire un nombre en base soixante avec le ";" qui sépare la partie entière de la partie fractionnaire, et la "," qui sépare les "chiffres" entre eux.

En base soixante, les "chiffres", que nous notons ici en base dix, vont évidemment de "0" à "59".

Ainsi, un scribe babylonien a écrit quelque chose comme: "√2 = 1;24,51,10", ou, en langage "moderne" (enfin, pour nous): "√2 = 1 + 24/60 + 51/60^2 + 10/60^3".

Comme ce nombre vaut environ 1,41421296 et que √2 vaut environ 1,4142135620, on voit que l'approximation babylonienne de l'ordre de 4*10^-7 est assez excellente !

En Inde, dans le Sulvasutras du mathématicien Apastamba (Ve ou IVe siècle avant notre ère), il écrit (chap 1.6):

"Allonger l'unité d'un tiers, puis ce tiers d'un quart de lui-même, moins le 34ème de cette dernière proportion."

En notation moderne, cette estimation s'écrit: √2 = 1 + 1/3 + 1/3*4 - 1/3*4*34 = 1.414215686, ce qui est également très précis (1,5*10^-6).

Là, oui, on peut parler de nombres pour les fractions, mais pour les grecs...