striiiiiiiiiiiiiiing - Page 54

Ce sont des défauts quant à la "beauté" (formelle) du langage. Il est facilement imprévisible, plein de pièges, c'est une horreur à enseigner.
Mais je suis tout à fait d'accord que c'est aussi pour ça qu'on l'aime

Il y a déjà une solution pour le Unicode qui ne demande pas de redéfinir char, ça s'appelle l'UTF-8, et c'est employé par tous les systèmes d'exploitation courants à l'heure actuelle sauf un, devinez lequel…

Heu au hasard... Fedora et le Vendredi 13 maudit® ?

UTF-8, c'est un cataplasme sur une jambe de bois. Ça donne l'impression que les trucs vont marcher sans modif, mais c'est trompeur et dangereux, parce qu'en fait plein de choses changent (en particulier "un char = un caractère" n'est plus vrai). Du coup on se retrouve avec des trucs qui marchent à moitié, parce que les gens ne font pas de tests poussés.

Bah, à mon avis, il vaut beaucoup mieux qu'un programme pas du tout prévu pour l'Unicode marche presque parfaitement que qu'il soit inutilisable pour tout ce qui n'est pas dans le CP1252…

Et puis "un char = un caractère" est aussi faux pour certains codages utilisés par le système d'exploitation très répandu qui refuse l'UTF-8, notamment ceux pour le chinois, le japonais et le coréen (et du coup certains programmes boguent sur les systèmes dans ces langues et les développeurs occidentaux ne s'en rendent jamais compte vive le codage unique pour le monde entier (UTF-8)!).

Kevin Kofler (./1595) :
Bah, à mon avis, il vaut beaucoup mieux qu'un programme pas du tout prévu pour l'Unicode marche presque parfaitement que qu'il soit inutilisable pour tout ce qui n'est pas dans le CP1252...

C'est discutable. J'ai généralement tendance à privilégier la rétrocompatibilité, mais à choisir entre introduire des problèmes invisibles au premier abord et casser explicitement les choses, je préfère encore la deuxième solution : au moins ça force les gens à corriger.

Pour l'UTF-16, j'avoue que je ne suis pas fan non plus. Ça n'a ni les avantages de l'UTF-8 (économie de la place, indépendance vis-à-vis de l'endianness), ni ceux de l'UTF-32 (nombre fixe d'octets par caractère, pas de validation des chaînes nécessaire). Je ne sais pas pourquoi MS a choisi ça ; peut-être que ça remonte à l'époque des formats asiatiques à deux octets par caractère, ou à une période où Unicode n'envisageait pas plus de 65 536 caractères.

Ça remonte effectivement à une période où Unicode n'envisageait pas plus de 65536 caractères. Java et Qt sont tombés dans le même piège pour la même raison.
Cela dit, l'UTF-16 en lui-même n'est pas si lourd que ça en pratique (le seul risque, c'est d'oublier de gérer les paires de surrogats), ce qui est lourd, c'est la conversion entre UTF-16 (Qt) et UTF-8 (APIs C ISO/POSIX, fichiers texte).

y'a pas une api win32 unicode?

Si, mais justement, elle utilise l'UTF-16.

Bon ranafoot de l'UTF8 vs 16 kevin.


Folco, tu me demandais un cas reel pour le fait de masquer :

voila : http://www.schneier.com/blowfish-bug.txt



Comment faire foirer l'efficacitée d'un algo pour un pauvre masque oublié ^^

Pour moi, l'erreur c'est de travailler avec des entiers signés pour ce genre de trucs. En plus de l'extension de signe qui pose problème, les décalages de bits vers la droite peuvent être soit arithmétiques, soit logiques suivant l'implémentation. Bonjour le bordel...

Zerosquare (./1596) :
Pour l'UTF-16, j'avoue que je ne suis pas fan non plus. Ça n'a ni les avantages de l'UTF-8 (économie de la place, indépendance vis-à-vis de l'endianness), ni ceux de l'UTF-32 (nombre fixe d'octets par caractère, pas de validation des chaînes nécessaire).

Je crois que tu idéalises trop.
Commençons par le commencement, tu le sais à priori déjà), mais la grande majorité des caractères (et par grande majorité je veux dire au moins 99,99 %…) qu'on utilise aujourd'hui tiennent dans la BMP (Basic Multilingual Plane), et la BMP tient dans un seul caractère UTF-16.
D'autre part, l'unicode n'utilise PAS 2³² valeurs, tu as donc des bits qui seront toujours 0 quoi qu'il arrive.
Bref, l'UTF-32 est un gâchis d'espace énorme: Là où pour l'UTF-16, tu vas jusque gagner de l'espace par rapport à l'UTF-8 (2 ou 3 fois en moyenne…) si tu utilises pas mal de symboles asiatiques, l'UTF-32 va te quadrupler l'espace disque pour un texte en ASCII, et le doubler au moins pour tous les autres.
Un autre intérêt de l'UTF-16 étant qu'il encode au plus sur 2 "caractères" contrairement à UTF-8 qui peut aller jusqu'à 8 octets4 octets. [EDIT] J'étais shooté ce matin quand j'ai posté ça. Heureusement personne n'a vu l'erreur
Et au delà de cela, tu ne tiens pas compte de la nature de l'Unicode. Un caractère tout seul ne veut plus dire grand chose. Il y a plusieurs façon d'encoder un caractère accentué comme ê: le caractère ê, le caractère e suivi de ^ (U+0302), donc un caractère au sens où on l'entendait en ASCII n'a plus grande signification, et on peut avoir de longues séquences de caractères combinés. Il faut jouer avec les formes de normalisation de toutes façons, donc autant économiser de la place…

Je ne sais pas pourquoi MS a choisi ça ; peut-être que ça remonte à l'époque des formats asiatiques à deux octets par caractère, ou à une période où Unicode n'envisageait pas plus de 65 536 caractères.

Windows NT a supporté lUCS-2 depuis très longtemps. L'UCS-2 était l'ancêtre de l'UTF-16, et l'UTF-16 est partiellement rétro-compatble avec UCS-2

Honnêtement j'ai très peu utilisé l'Unicode donc je ne connais pas beaucoup le sujet (pour l'embarqué que je fais la plupart du temps, on est déjà content quand on peut utiliser les caractères accentués ). Kevin avait l'air de dire que des caractères asiatiques utilisés couramment n'étaient pas présents dans le BMP, tu sembles dire le contraire, perso je connais très peu ces langues donc je sais pas...

Je n'ai pas parlé de l'espace utilisé, mais j'y pensais : l'UTF-32 gaspille beaucoup d'espace. Cependant sur un PC actuel, je doute que l'espace utilisé pour stocker des chaînes soit vraiment significatif par rapport à la taille mémoire dont on dispose (mais à l'époque où se sont prises les décisions sur l'Unicode, c'était beaucoup moins vrai).

Pour ce qui est de la notion de caractère qui devient plus complexe en Unicode, tu as raison : je n'y avais pas pensé mais c'est pertinent.

(je pense qu'on devrait forker si on veut pas polluer le sujet de Folco, à moins que ça l'intéresse aussi)

Ca me dérange pas, vous avez répondré et je vous en remercie


Merci Godzil !

Zerosquare (./1601) :
En plus de l'extension de signe qui pose problème, les décalages de bits vers la droite peuvent être soit arithmétiques, soit logiques suivant l'implémentation. Bonjour le bordel...

Et vers la gauche, c'est safe ? J'imagine que oui. Vers la droite, ça veut dire que il peut faire un lsr comme un asr et que t'as aucun moyen de le savoir ?

De mémoire, pas de problème pour le décalage vers la gauche. Et pour le décalage à droite, c'est bien ce que tu décris. (faudrait que je relise le K&R pour être sûr à 100% )
EDIT :

K&R :
Les opérateurs << et >> décalent leur opérande de gauche du nombre de bits indiqué par leur opérande de droite, qui doit être positif. Ainsi, x << 2 décale la valeur de x de 2 bits vers la gauche, en remplissant les 2 bits de droite par des zéros, ce qui revient à une multiplication par 4. Si l'on décale une quantité non signée vers la droite, les bits de gauche sont toujours mis à zéro. Si cette quantité est signée, les bits de gauche se rempliront par des bits de signe sur certaines machines ("décalage arithmétique") et par des zéros sur d'autres ("décalage logique").

Quelle belle machine, hein ?

Génial Seule la division me semble safe alors dans ce cas, et le compilateur devrait optimiser en décalage s'i sait pouvoir le faire.

Oui, sauf que pour les nombres négatifs, le décalage de bits (même arithmétique) n'est pas équivalent à une division ; l'arrondi ne se fait pas de la même façon. Donc même le meilleur compilo n'utilisera pas un asr tout seul. Dômmaaaaage

Mais un certain compilo C pour la Game Boy le fait quand même
C'est aussi bien marrant qu'il soit "faux" d'écrire un truc aussi anodin que:

unsigned int i;
for (i = 0; i < 300; i++)
    printf("%d\n", i);

Pourquoi, parce que les int font 1 octet sur GB ?

Auquel cas, ton compilateur ne respecte pas le standard (un int doit avoir au moins 16 bits).

Alors peu de compilos le respectent, vu que c'est pareil pour les µC ^^

Euh, faudrait que je vérifie (j'utilise uintxx_t systématiquement pour pas me prendre la tête), mais non justement.

GoldenCrystal (./1602) :
Un autre intérêt de l'UTF-16 étant qu'il encode au plus sur 2 "caractères" contrairement à UTF-8 qui peut aller jusqu'à 8 octets4 octets. [EDIT] J'étais shooté ce matin quand j'ai posté ça. Heureusement personne n'a vu l'erreur

Mais 2 caractères UTF-16 font aussi 4 octets…

Zerosquare (./1603) :
Kevin avait l'air de dire que des caractères asiatiques utilisés couramment n'étaient pas présents dans le BMP

Non, je dis qu'ils utilisent plusieurs caractères dans les codepages 8 bits traditionnelles (même celles spécifiques à une langue), parce qu'il est impossible de les faire tenir en 8 bits.

Brunni (./1611) :
Alors peu de compilos le respectent, vu que c'est pareil pour les µC ^^

Les targets µC de GCC le respectent (et sont parfois critiqués pour ça).

Pourquoi Windows ne supporte pas nativement UTF-8? Parce que trop d'applications existantes comptent peut-être sur le fait que ça ne soit pas supporté.

Un autre intérêt de l'UTF-16 étant qu'il encode au plus sur 2 wchar_t (tout comme les anciens codages DBCS qui utilisaient au plus deux char) contrairement à UTF-8 qui peut aller jusqu'à 8 char4 char.

Ça va mieux comme ça? On a fini de pinailler?

Kevin Kofler (./1613) :

GoldenCrystal (./1602) :
Un autre intérêt de l'UTF-16 étant qu'il encode au plus sur 2 "caractères" contrairement à UTF-8 qui peut aller jusqu'à 8 octets4 octets. [EDIT] J'étais shooté ce matin quand j'ai posté ça. Heureusement personne n'a vu l'erreur

Mais 2 caractères UTF-16 font aussi 4 octets…

Mais plein de caractères que tu encodes en UTF-16 en 2 octets nécéssitent 3 octets en UTF-8. En fait, l'UTF-8 n'encode sur 2 octets que jusqu'à U+0800... Donc presque tous les caractères asiatiques prennent 3 octets (voire 4 pour les idéogrammes CJC supplémentaires). Les langues européennes tiennent sur 2 octets maximum (hors symboles spéciaux), mais ça s'arrête là.
Alors que dans la pratique, il y a vraiment très peu de langages (ça se compte encore sur les doigts de la main) hors du BMP, et ce sont souvent des langues peu répandues. Donc tous les caractères qu'on utilise fréquemment tiennent parfaitement dans un "caractère" UTF-16 (UCS-2)

Link (./1614) :

Un autre intérêt de l'UTF-16 étant qu'il encode au plus sur 2 wchar_t (tout comme les anciens codages DBCS qui utilisaient au plus deux char) contrairement à UTF-8 qui peut aller jusqu'à 8 char4 char.

Ça va mieux comme ça? On a fini de pinailler?

C'est faux. Corrige moi si tu veux, mais corrige moi sans raconter de trucs faux.
Un caractère UTF-16 fait 16 bits, alors qu'un wchar_t a une taille indéterminée (16 bits sous Windows, 32 bits sous un Unix standard...)
Quand à la référence aux DBCS, je rapelle quand même que les surrogate pair n'existent qu'en UTF-16 et que les plages de caractères ont été réservées dans Unicode juste pour ça. (Que UTF-16 puisse encoder autant de caractères que UTF-32) C'est pas *exactement* pareil...

Je parlais des wchar_t sous Windows. J'aurais aussi bien pu parler du type Char de .Net et Java, c'est juste que j'avais la flemme de chercher une traduction pour "Storage character" et me refusais à employer TCHAR parce ça m'aurait exposé à des critiques à n'en plus finir.

Et puis je n'ai jamais dit "*exactement* pareil", j'ai dit que les deux (DBCS et UTF-16) se limitaient à deux "storage characters", ce qui est vrai.

Link (./1614) :
Pourquoi Windows ne supporte pas nativement UTF-8? Parce que trop d'applications existantes comptent peut-être sur le fait que ça ne soit pas supporté.

Ça n'a pas empêché le reste du monde à passer à l'UTF-8. Sous Red Hat Linux (ce changement a été effectué avant Fedora), les locales sont passés à l'UTF-8 d'une version à la prochaine sans aucun avertissement et c'était aux applications de se mettre à jour ou être boguées. Et les applications qui font partie de la distribution ont été adaptées, évidemment. Et de toute façon, la plupart des applications n'ont nécessité aucune modification! Les outils traditionnels *nix qui travaillent sur du texte marchent avec n'importe quel surensemble de l'ASCII, voire n'importe quel codage (par exemple, cat marche même sur des fichiers binaires!), pour les logiciels graphiques, adapter le toolkit graphique a été en général suffisant.

Le problème qu'ils ont à Redmond, c'est qu'ils défendent férocement la compatibilité antérieure à tout prix, même si ça signifie d'être incompatible avec le reste du monde, bidouiller pour contourner les standards internationaux (cf. cette horrible aberration de _wmain) etc.

Pour reprendre point par point ce qu'il raconte:

To say a bit more on the topic, yes he is right -- it would make some operations much easier.

Bah oui, c'est bien pour ça que le reste du monde est passé à l'UTF-8.

But beyond that, taking the current model that ties the default system code page to the default system locale -- would this mean that you could only use such a UTF-8 ACP when dealing with Unicode-only locales?

Bah oui, c'est ce qui est fait sous GNU/Linux, on n'utilise que des locales .UTF-8 (par exemple en_US.UTF-8, fr_FR.UTF-8, de_AT.UTF-8 etc.), les locales sans ce suffixe sont obsolètes.

And would it provide easier internationalization to force a system-wide setting to be changed in order to make an application work? Ugh.

s/an application/many applications/
Y compris les applications portables qui n'utilisent pas ces pourritures de fonctions spéciales UTF-16 non-standard comme _wmain.

As would breaking any existing application relying on the current behavior.

Ces applications sont boguées et ont de fortes chances de déjà boguer dans les locales DBCS. Au moins l'UTF-8 ferait en sorte que les développeurs occidentaux s'en rendraient compte!

And then of course there is the cost is the huge PM/test/dev effort to bring every "A" API function (and underlying kernel API function as well) up to speed handling up to four bytes to character when so many of them are strictly limited to handling only one or two. Thousands of functions and whole systems (like for Window messaging). And some of these algorithms really do come from the original Win 3.x source for the "A" version!It is not exaggerating to suggest that this effort could cost billions, impact thousands of people, and take years. For code that is and has been set up as legacy. There is simply no real way to even contemplate this as an effort that would get approval to proceed....

Bah, ça c'est leur problème… Et le seul endroit où le nombre d'octets par caractère changerait quoi que ce soit, c'est pour les fonctions A qui ne sont que des wrappers pour les W, et elles devraient être faciles à corriger (on change la taille d'un buffer et c'est tout!). Les fonctions qui travaillent directement sur la représentation "A" s'en contrefichent de combien d'octets constituent un "caractère", pour elles, les octets sont les caractères, les caractères logiques ne devraient avoir aucune importance pour elles! (C'est bien comme ça que l'UTF-8 est "géré" à plein d'endroits dans *nix: on met la chaîne dans une fonction comme strcat qui travaille sur des octets et il se passe la bonne chose sans que cette fonction n'ait le moindre soupçon que ce qu'elle est en train de traîter est en fait de l'UTF-8! Elle n'a pas besoin de le savoir!)

Quoi qu'il en soit, je pense que c'est bien d'avoir 2 types bien distincts CHAR et BYTE, c'est un mauvais raccourci d'associer les deux.

Sauf qu'en C, t'es obligé de partir de ce principe si je ne m'abuse, parce que tu n'as aucun moyen de savoir ce qu'il y a réellement derrière un char.