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