Pour info, pour une fois que MS ne fait pas tout après tout le monde, MS est passé à Unicode à l'époque de WinNT 3.
A cette époque, UTF-32 n'existait pas, tout bêtement parce que le consortium Unicode avait imaginé que 2 octets (65536 caractères maxi) pour coder les caractères (il y avait de la place, et on imaginait pas le "succès d'Unicode, et le besoin de coder des caractère très rares... Mais l'informatique se démocratise...). MS a été "victime" d'avoir voulu passer à Unicode avant les autres. Il a du du coup passer de UCS-16 à UTF-16 (qui ne sont pas égaux, ie l'UCS-16 ne permet pas d'avoir les caractères unicode supérieurs à 0xFFFF, UTF-16 si) avec Windows 2000. MS aurait bien amié ne plus se faire chier avec les "multi-byte character" avec les codage qu'il avait pris, mais raté, et ça l'embête bien.
Unicode est passé après la sortie de WinNT 3 à 4 octets (et hop Linux a pris 4 octets tout de suite...)
Par contre, pour Java j'ai plus de mal à expliquer (bouffer 2x moins de mémoire en RAM dans 99.99% des cas? mais bon, la RAM ne manque pas trop et on n'a pas souvent 10 millions de caractères en RAM donc les inconvénients dépassent les avantages...)
Sinon,
UTF-16 c'est vraiment ce qu'on fait de pire, ça cumule les tares de (...)
On s'en fout, c'est en RAM, c'est sur une seule machine à la fois, c'est donc transparent pour le programmeur qui ne gère qu'un truc à la fois, de façon transparente. Perso je programme pour Windows et Linux en C++, donc la taille du wchar_t change d'Endianess et de taille, mais je programme de la même façon (bon, je dois avouer que je ne me suis pas encore trouvé confronté à un caractère supérieur à 0x8FFF en Unicode, donc peut-être que des trucs merderont sous Windows plus tard, mais ça va être rare).
Les fichiers stockés doivent être en UTF-8, pour le reste (comment l'OS s'y prend) n'est pas gênant en soit.
[^] # Re: hg
Posté par Zenitram (site web personnel) . En réponse au journal Explosion d'UNICODE sur le web. Évalué à 5.
A cette époque, UTF-32 n'existait pas, tout bêtement parce que le consortium Unicode avait imaginé que 2 octets (65536 caractères maxi) pour coder les caractères (il y avait de la place, et on imaginait pas le "succès d'Unicode, et le besoin de coder des caractère très rares... Mais l'informatique se démocratise...). MS a été "victime" d'avoir voulu passer à Unicode avant les autres. Il a du du coup passer de UCS-16 à UTF-16 (qui ne sont pas égaux, ie l'UCS-16 ne permet pas d'avoir les caractères unicode supérieurs à 0xFFFF, UTF-16 si) avec Windows 2000. MS aurait bien amié ne plus se faire chier avec les "multi-byte character" avec les codage qu'il avait pris, mais raté, et ça l'embête bien.
Unicode est passé après la sortie de WinNT 3 à 4 octets (et hop Linux a pris 4 octets tout de suite...)
Par contre, pour Java j'ai plus de mal à expliquer (bouffer 2x moins de mémoire en RAM dans 99.99% des cas? mais bon, la RAM ne manque pas trop et on n'a pas souvent 10 millions de caractères en RAM donc les inconvénients dépassent les avantages...)
Sinon,
UTF-16 c'est vraiment ce qu'on fait de pire, ça cumule les tares de (...)
On s'en fout, c'est en RAM, c'est sur une seule machine à la fois, c'est donc transparent pour le programmeur qui ne gère qu'un truc à la fois, de façon transparente. Perso je programme pour Windows et Linux en C++, donc la taille du wchar_t change d'Endianess et de taille, mais je programme de la même façon (bon, je dois avouer que je ne me suis pas encore trouvé confronté à un caractère supérieur à 0x8FFF en Unicode, donc peut-être que des trucs merderont sous Windows plus tard, mais ça va être rare).
Les fichiers stockés doivent être en UTF-8, pour le reste (comment l'OS s'y prend) n'est pas gênant en soit.