IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Shell et commandes GNU Discussion :

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


Sujet :

Shell et commandes GNU

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre actif
    Homme Profil pro
    Ingénieur
    Inscrit en
    Avril 2020
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2020
    Messages : 88
    Par défaut 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 :
    Je produit un fichier toto.txt en ligne de commande :
    Je sauvegarde le fichier.
    Lorsque je reviens dans le shell (bash) et que je tape la commande suivante :
    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 ?

  2. #2
    Expert confirmé Avatar de disedorgue
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    Décembre 2012
    Messages
    4 347
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Décembre 2012
    Messages : 4 347
    Par défaut
    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.

  3. #3
    Modérateur
    Avatar de N_BaH
    Profil pro
    Inscrit en
    Février 2008
    Messages
    7 652
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 7 652
    Par défaut
    Citation Envoyé par disedorgue Voir le message
    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 ?
    N'oubliez pas de consulter les cours shell, la FAQ, et les pages man.

  4. #4
    Expert confirmé Avatar de disedorgue
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    Décembre 2012
    Messages
    4 347
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Décembre 2012
    Messages : 4 347
    Par défaut
    Citation Envoyé par N_BaH Voir le message
    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.

  5. #5
    Membre actif
    Homme Profil pro
    Ingénieur
    Inscrit en
    Avril 2020
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2020
    Messages : 88
    Par défaut
    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

  6. #6
    Expert confirmé
    Homme Profil pro
    Développeur informatique en retraite
    Inscrit en
    Avril 2008
    Messages
    2 102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique en retraite

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 102
    Par défaut
    Citation Envoyé par zephyre Voir le message
    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...

  7. #7
    Membre actif
    Homme Profil pro
    Ingénieur
    Inscrit en
    Avril 2020
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2020
    Messages : 88
    Par défaut
    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.

  8. #8
    Membre prolifique
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 832
    Billets dans le blog
    1
    Par défaut
    Bonjour
    Citation Envoyé par zephyre Voir le message
    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.

    Citation Envoyé par jack-ft Voir le message
    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
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  9. #9
    Membre actif
    Homme Profil pro
    Ingénieur
    Inscrit en
    Avril 2020
    Messages
    88
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2020
    Messages : 88
    Par défaut
    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.

  10. #10
    Membre prolifique
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 832
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par zephyre Voir le message
    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 Voir le message
    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 Voir le message
    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.
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  11. #11
    Expert confirmé
    Homme Profil pro
    Développeur informatique en retraite
    Inscrit en
    Avril 2008
    Messages
    2 102
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique en retraite

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 102
    Par défaut
    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...

  12. #12
    Expert confirmé
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 766
    Par défaut
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Spool avec paramètre sur l'encodage en utf-8 sans BOM
    Par saidna123 dans le forum Oracle
    Réponses: 5
    Dernier message: 02/05/2013, 10h04
  2. Réponses: 4
    Dernier message: 24/02/2010, 06h37
  3. Affichage Image sur n colonnes avec Crystal Report
    Par callo dans le forum Windows Forms
    Réponses: 1
    Dernier message: 09/09/2009, 18h41
  4. pb d'affichage de form sur une jsp avec tomcat
    Par startin dans le forum Tomcat et TomEE
    Réponses: 2
    Dernier message: 25/05/2007, 09h32
  5. Affichage pourri sur DEBIAN avec ATI RADEON 7000
    Par jibouze dans le forum Matériel
    Réponses: 2
    Dernier message: 07/04/2005, 00h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo