Discussion :

[zephyre]

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 :

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

set encoding=utf-8

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

Code :

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

vim toto.txt

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

Code :

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

file -i toto.txt

J'obtiens le résultat suivant :

Code :

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

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 ?

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

[N_BaH]

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 ?

[disedorgue]

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.

[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

[jack-ft]

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 :

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

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 :

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

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

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

[Sve@r]

Bonjour

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

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

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

[Sve@r]

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

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.

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.

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

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

[foetus]

Je ne pense pas que le sujet est 1 rapport avec le C, mais bon je vais répondre

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 )

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