Discussion:UTF-8

Introduction : incompréhensible

Je connais plutôt bien le domaine des jeux de caractères, des divers codages existants et j'ai du mal à comprendre la formulation de l'introduction ... je n'imagine même pas pour un néophyte. Tout est touffu, confus, inutilement compliqué. Le paragraphe sur le "point de code" illustre bien comment on peut expliquer de façon complexe un concept simple. Le "point de code" (code point en anglais) est tout simplement un index numérique, c'est à dire un entier qui sert à repérer un caractère dans la liste (répertoire ou jeux) de caractères d'Unicode. Je vais rédiger une nouvelle version, plus courte, plus simple et probablement plus juste, en renvoyant les détails techniques dans les paragraphes suivants.Baldodo (d) 12 mars 2012 à 16:33 (CET)

Analyseur lexical

Hum, dans inconviennent, ça serait pas plutot "analyseur lexical" à la place de "analyseur syntaxique" ? En effet, c'est l'analyseur lexical qui contient des règles pour ignorer certains passages ... d'ailleur je ne comprend pas pourquoi utf-8 transformer "/../" de 2 façons différentes ...

--81.56.249.22 20 mars 2006 à 09:31 (CET)

Permier octet d'une séquence

Le passage en UTF-8 c'est tous les soirs ?

- C'est plusieurs fois par jour camarade, même le matin si tu écris des textes en LaTeX avant le repas de midi. Avec latin1 c'est la galère, ton texte est truffé de hiéroglyphes à cause des accents, mais avec utf-8 c'est nickel chrome, zéro défaut. Utf-8 c'est tout bon! Balaise! Tous les TeXeurs et toutes les TeXeuses attendaient çà depuis la chute de l'empire romain. C'est-y pas beau l'progrès, hein ? Momo--2.2.145.124 (discuter) 8 février 2015 à 20:37 (CET)

"Le premier octet d'une séquence permet d'en déterminer" quoi ?

La longueur de la séquence, déterminé par le nombre de bits à un consécutifs, si j'ai le temps de le revoir il faut modifier cet article il y a des erreurs, le standard a été modifié et ne permet plus que des séquences de 4 octets au plus, il y aussi de trés intérressantes questions concernant l'utilisation d'utf-8 et les problèmes de sécurité phe 29 aoû 2004 à 04:56 (CEST)

Support sous Windows

Pas très bien supporté sous Windows ? Je m'étonne, il me semble que depuis XP tout est en UTF-8. Grimko

En fait WINDOWS NT (et suivants : 2000, XP, 2003, vista) est UNICODE 16 en interne depuis le premier NT (3.01). Il n'utilise effectivement pas UTF8. Rouletabille 25 mai 2007 à 17:54 (CEST)

Plus précisément, NT et 2000 utilisent UCS-2 (2000 ignorant les seizets d'indirection en les traitant comme des WCHAR "normaux"), tandis que XP et suivants UTF-16, avec les caractères hors PMB. Mais il me semble que c'est au niveau du shell que la différence se trouve. -- RasqualTwilight 25 mai 2007 à 23:51 (CEST)

Pour être clair, ce sont Windows 95, 98, 98SE, et ME à qui il manquait un support complet de l’Unicode, les API de conversion ne supportant initialement que la conversion entre les deux jeux 8 bits ANSI et OEM du système, et UCS-2, à l'aide de seulement deux tables de conversion à 256 entrées (une table par jeu 8 bits). Comme les jeux de caractères ANSI et OEM sur 8 bits supportés ne comprenaient aucun caractère hors du plan de base, il n'y avait pas non plus la logique nécessaire au support complet de l’UTF-16, donc pas de reconnaissance des paires de demi-codets haut et bas, considérés encore comme des caractères séparés (mais totalement inutilisés dans les jeux ANSI et OEM).

Ce support minimaliste a été ajouté uniquement pour supporter le système de fichier FAT32 utilisé sous Windows NT puis Windows 2000 (qui eux non plus n'utilisaient aucun point de code hors du plan multilingue de base). Tout le reste du système était basé sur les jeux de caractères sur 8 bits (et les API d'émulation en mode Unicode faisaient implicitement la conversion vers le jeu ANSI, pour les APIs graphiques, ou de la page de code OEM utilisée pour le système de fichiers, la console, et l’émulation MSDOS). Le support complet a nécessité des modifications profondes dans Windows afin d'assurer la conformité des API. Ce support conforme n'est réellement complet dans Windows que depuis 2002 dans Windows XP (ou Windows Server 2003) où les règles ont été renforcées, et depuis Internet Explorer 4 dans les autres versions de Windows (la version 3 d’IE n'était pas conforme car elle s'appuyait sur les capacités limitées du système hôte), mais il a fallu aussi que tout le système graphique soit revu pour supporter aussi les polices Unicode (support de TrueType / OpenType), capables d'afficher un jeu de caractères plus étendu, et que pas mal de modifications soient apportées à divers composants (du système de fichiers FAT32, aux protocoles réseau, en passant par le système de fichiers NTFS lui aussi modifié dans Windows Server 2003 et Windows XP), puis l'adaptation d'Internet Explorer, les clients de mail, la console et son gestionnaire de pages de code, les APIs de conversions de code, et l'extension de la taille des tables de transcodage (support des pages de code mutioctets asiatiques disponible sur toutes les installations de Windows)... Verdy p (d) 9 décembre 2009 à 12:52 (CET)

Point de code

L'expression "point de code" n'est pas définie avant d'être utilisée.

Elle n'a pas à être définie dans cet article. Voir l'article ISO/CEI 10646 à ce sujet. Ce qui importe est que l’UTF-8 ne sert pas à coder seulement des caractères, mais tous les points de codes ayant une valeur scalaire, même s'ils ne sont pas attribués à des caractères.

L'expression "point de code" ne me semble pas très appropriée : Bien que ça puisse peut être varier, un "code" exécutable, ne sera probablement pas représenté grâce à utf-8. Sauf des parties de texte qui peuvent être contenues dans le code. Comme "coucou je suis un virus"... :)

Hors sujet ! Tu n'as rien compris ! Verdy p (d) 9 décembre 2009 à 12:44 (CET)

Sur la page http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8, ils parlent du test de la sous-chaîne... Je suis parti de divers points que je ne comprenais pas bien dans la page pour rédiger l'ajout que j'ai fait : "principe et unicité du codage" et "segments interdits". Quoique conscient du fait que ce soit très mal rédigé, j'ai essayé de partir d'un exemple précis pour expliquer ce qui pouvait être fait et ce qui ne devais pas être fait. En partie du point de vue de celui qui devrait coder un codeur-décodeur. Et pour qui les choses ne peuvent pas être laissées à l'à-peu-près. Pour de multiples raisons dont seulement deux sont évoquées. (une autre est la possibilité de corriger du code (texte codé), par la propriété d'auto alignement de utf-8).

"point de code" provient d'une mauvaise traduction de l'article anglais : "Unicode also disallows the 2048 code points U+D800..U+DFFF " : "unicode interdit aussi les points allants de U+D800 à U+DFFF" ou bien "unicode interdit aussi les codes allants de ..." — Le message qui précède, non signé, a été déposé par l'IP 90.3.107.233 (discuter)

J'ai remplacé point de code par code tout simplement. -- haypo (d) 14 octobre 2008 à 10:39 (CEST)

NON surtout pas ! Cela introduit l'ambiguité avec les codes utilisés dans UTF-8, ou les valeurs scalaires. La notion de point de code sert à désigner explicitement une position dans l’espace du répertoire universel, que cette position soit utilisée ou non par un caractère. L’espace de codage (UCS-4) est défini comme un système de coordonnées en numéro de groupe (il y a 256 groupes mais un seul est aujourd'hui utilisé), numéro de plan (il y a 256 plans par groupe mais 17 seulement sont aujourd'hui utilisés), numéro de rangée (il y a 256 rangées par plan), colonne (il y a 16 colonnes par rangée) et position dans une colonne (16 positions par colonne). La combinaison des coordonnées définit entièrement l’espace de codage, mais ne définit pas un caractère tant que celui-ci n’y a pas été attribué.

De plus tous les points de code n'ont pas de valeur scalaire définie (c'est le cas des points de code attribués aux demi-codets, qui ne sont pas des caractères, ni même des non-caractères).

UTF-8 permet de coder TOUS les points de code ayant une valeur scalaire définie, et seulement ceux-là.

Voir les définitions précises des concepts dans le texte officiel des normes (publiées en anglais seulement pour Unicode, mais en anglais et en français dans ISO/CEI 10646) où les distinctions sont très importantes pour la conformité !

Ni l'un ni b'autre vous n'avez compris les nuances et vous avez introduit des ambiguïtés inexistantes dans les normes. Attention aux traductions, on ne peut pas simplifier à outrance les définitions et concepts ! Verdy p (d) 9 décembre 2009 à 12:44 (CET)

Il y a un soucis de clarté avec cet article. Je suppose qu'un article wikipedia, ou au moins son chapeau, est destiné à être lu potentiellement par n'importe qui. Le soucis majeur ici c'est que même pour un informaticien il est difficile de lire le chapeau de l'article. Je suis d'accord que les concepts doivent être bien définis, mais ici à force de définitions pas évidentes concentrées dans le chapeau de l'article, même un informaticien confirmé est susceptible d'être perdu (et je suis pas le seul à penser ça) ... Il faut absolument simplifier le chapeau de l'article et reléguer plus loin les multiples concepts introduits pour définir un peu plus précisément tout ça. Il n'est pas nécessaire de se perdre dans la définition précise d'un "point de code", qui est un concept que peu de gens maîtrisent et de précisément dans quel norme il est ou pas défini, pour avoir une idée de ce qu'est Unicode. Se perdre dans les détails de la norme ne donne pas vraiment d'idées générale de ce qu'est UTF-8, ce que devrait faire le chapeau de l'article ... TomT0m (d) 20 janvier 2011 à 23:17 (CET)

Byte Order Mark (BOM)

Cela peut paraitre trop technique, mais il y a un sujet qui revient fréquemment dans l'encodage UTF-8 c'est le Byte Order Mark (BOM), moins connu sous le terme de "boutianité"[1]. Lorsque l'on parle de utf8 il est nécessaire de distinguer le "UTF-8 avec BOM" du "UTF-8 avec BOM", et la problématique est très fréquemment abordée, voici quelques exemples variés :

• Décrit dans les spécification de la rfc3629 (voir : [2])
• plateforme microsoft et langage c# [3]
• plateforme SUN et langage JAVA (angl.)[4]
• Recommandation ORACLE [5]
• Programmation en C++ et l'UTF8 [6]
• etc..

On constate que c'est une problématique récurrente et transversale à tous les langages et plate-formes.

Il me semble donc que cet aspect, si il ne devait être pas être détaillé, devrait au moins apparaitre dans la description de l'UTF8, et ce d'autant plus que l'article wiki sur l'unicode [7] l'aborde dans la partie "Mécanisme de sérialisation des caractères".

A mon humble avis, j'inclurait (a minima) la notion avant la partie "avantage - inconvénient", puis ajouterais ensuite dans les inconvénients le fait de devoir distinguer ces 2 sous-types d'utf8 (sous peine de bug).

Les Byte Order Marks n'étant pas nécessaires à l'UTF-8 ne font pas partie de la définition de l’encoding transform scheme UTF-8. Ils n'apparaissent pas non plus dans l’encoding transform format UTF-8, mais seulement dans les charsets utilisés dans MIME et les standards du Web et des systèmes d'exploitation et applications.

Il y a des passages entiers très précis dans le standard Unicode (pas dans la norme ISO/CEI 10646) à leur sujet, mentionnant quand ils sont autorisés et quand ils ne doivent pas apparaître.

Initialement UTF-8 n'avait pas de BOM, mais depuis que la fonction de contrôle de césure du caractère ZWNBSP (U+FEFF) nécessaire à certaines langues (qui toutefois ne l'utilisaient jamais en début de texte) a été réencodée spécifiquement vers un autre caractère (afin que cette fonction puisse être manipulée isolément), le caractère ZWNBSP ne sert plus guère que comme BOM, et un BOM (codé avec ZWNBSP) peut apparaitre de façon optionnelle dans les documents UTF-8, comme aussi dans d'autres codages MIME (UTF-16, UTF-32, CESU-8, BOCU...).

Il n'y a aucun BOM dans les encoding transform scheme qui ne travaille pas au niveau des octets mais directement au niveau des « unités de code » (distinctes des « points de code ») qui ont une taille indéfinie mais seulement assez grande pour contenir toutes les valeurs scalaires nécessaires à la représentation des points de code. Les BOM ne sont donc pas des caractères (même si des encoding transform formats utilisent un caractère pour le représenter, un caractère qui ne sera donc pas disponible sans précaution prise au niveau supérieur).

Si un caractère ZWNBSP doit apparaître en tant que tel au début d’un document codé et sérialisé avec un encoding transform format, le seule moyen de le représenter sera de le coder deux fois (le premier sera un BOM, le second sera le caractère lui-même).

Verdy p (d) 9 décembre 2009 à 12:44 (CET)

Erreur dans le tableau des codages ?

les deux derniers points de code dans le tableau m'ont l'air incorrectement codé : le point de code 10FFFF devrait être codé F4 8F BF BF et non F4 BF BF BF .

mise à jour : j'ai effectué la correction dans l'article après vérification

Baldodo (d) 19 novembre 2010 à 11:14 (CET)

Le passage en UTF-8 c'est tous les soirs ?

Cette page de discussion a été entamée en 2004, avec la question: «Le passage en UTF-8 c'est tous les soirs ?»

Quel était le sens de cette question? Pourquoi cette question se retrouve au milieu de la conversation traitant d'autres sujets?

Question au sujet du codage des caractères, UTF8 en particulier

Je me demande pourquoi on a choisi une façon aussi compliquée de coder des caractères en maintenant à l'identique l'ASCII

En effet, un octet comporte 256 valeurs possibles. Si on maintient les 128 premières valeurs (0-127), alors les 128 autres valeurs (128-255) peuvent servir d'octet de contrôle.

Avec 3 octets seulement au maximum, on peut donc coder plus de 2 millions de caractères :

n= 128 ! les caractères ASCII seuls

+ 128 * 128 ! caractères ASCII précédés d'un octet de contrôle
+ 128 * 128 * 128 ! caractères ASCII précédés de 2 octets de contrôle
= 2113664 valeurs possibles

Un considérant un octet au hasard, si sa valeur dépasse 127 alors c'est un octet de contrôle : on doit juste examiner l'octet précédent et l'octet suivant pour trouver le code du caractère associé. Si c'est un octet de valeur inférieure à 127, alors on examine juste au plus les deux octets précédents. --Labidibidou (discuter) 27 février 2018 à 12:11 (CET)

Mettre un passage pour expliquer pourquoi UTF-8 (le nom)

Suite à une erreur que j'avais faite et corrigée (merci) par FrançoisD, je souhaiterais suggérer une modification.
Lorsque je lis:
UTF-8 (abréviation de l’anglais Universal Character Set Transformation Format - 8 bits)
je me figure que l'UTF-8 est codé sur 8bits! (d'où mon réflexe de corriger - à tort- en 8bytes).
Alors qu'en fait, si on parle de 8bits, c'est parce que l'UTF-8 autorise le codage par groupes de 8bit (si j'ai bien compris):
8bit, 2*8bits, 3*8bits.
Ce serait bien de faire un paragraphe "origine du nom".
La confusion entre bit et byte est fréquente chez les francophones...
--Oc.Gal. (discuter) 9 juillet 2018 à 03:34 (CEST)

Pour éviter la confusion, il est possible de dire: 8 bits — c'est-à-dire 8 chiffres binaires — — Le message qui précède, non signé, a été déposé par l'IP 86.67.202.154 (discuter), le 3 septembre 2021 à 21:40 (CEST)

Pourquoi 110ƀ·ƀƀƀƀ plutôt que 110x·xxxx?

Pourquoi 110ƀ·ƀƀƀƀ plutôt que 110x·xxxx? — Le message qui précède, non signé, a été déposé par l'IP 86.67.202.154 (discuter), le 3 septembre 2021 à 21:38 (CEST)