Dans ce cas tu es d'accord qu'un shell UTF-8 pur n'a de sens que si tout le monde utilise un shell UTF-8 pur depuis des années. Parceque sinon les problèmes évoqués sont pour le moins génant.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
Même avec le smiley, ca ne me fait pas trop rire. Comme tous les trucs qui deviennent des dogmes plutôt que des solutions techniques.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
UTF-16 et UCS-2 sont proches au niveau character map, mais au niveau du concept ca n'a rien à voir. En UCS-2 tout est sur deux octets et puis c'est tout. Alors que vache UTF-16 pour décoder une chaine il faut sortir la tronconneuse (et encore de gros efforts on été fait pour simplifier les boulot des devs par rapport aux premières versions, on est plus obligé de parser toute la chaine pour connaitre la valeur d'un caractère). Les high et les low surrogate c'est d'une lourdeur. Je veux extraire le 27ème caractère d'une chaine UCS-2, je fais un bon de 54 octets depuis le début la chaine. En UTF-8 ou 16….
Pas mal de programme utilisent UCS-2 en interne et n'utilisent UTF que pour le stockage et la lecture.
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Non juste non utilisés pour faciliter le mapping. Mais tout à fait légaux, il ne correspondent juste pas à un glyphe.
Et c'est à Pékin qu'on écrit les normes. ;-)
Autant le Tibet d'accord, autant Taiwan les normes de Pekin….
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 0.
Parce que j'ai rien à dire dessus.
Dans ce cas tu es d'accord qu'un shell UTF-8 pur n'a de sens que si tout le monde utilise un shell UTF-8 pur depuis des années. Parceque sinon les problèmes évoqués sont pour le moins génant.
T'es contre l'utilisation d'UTF-8 partout et pour tout, donc t'es contre UTF-8. ;-)
Même avec le smiley, ca ne me fait pas trop rire. Comme tous les trucs qui deviennent des dogmes plutôt que des solutions techniques.
Ben UCS-2 (ou UTF-16, parce que c'est pas loin d'être la même chose) apporte rien à un occidental par rapport à UTF-8 à part que ça prend plus de place en mémoire et sur les disques durs. (oui j'ai conscience d'alimenter un dialogue de sourds)
UTF-16 et UCS-2 sont proches au niveau character map, mais au niveau du concept ca n'a rien à voir. En UCS-2 tout est sur deux octets et puis c'est tout. Alors que vache UTF-16 pour décoder une chaine il faut sortir la tronconneuse (et encore de gros efforts on été fait pour simplifier les boulot des devs par rapport aux premières versions, on est plus obligé de parser toute la chaine pour connaitre la valeur d'un caractère). Les high et les low surrogate c'est d'une lourdeur. Je veux extraire le 27ème caractère d'une chaine UCS-2, je fais un bon de 54 octets depuis le début la chaine. En UTF-8 ou 16….
Pas mal de programme utilisent UCS-2 en interne et n'utilisent UTF que pour le stockage et la lecture.
Et il y a des caractères interdits en UCS-2 (enfin des caractères réservés, qui justement rendent UTF-16 possible).
Non juste non utilisés pour faciliter le mapping. Mais tout à fait légaux, il ne correspondent juste pas à un glyphe.
Et c'est à Pékin qu'on écrit les normes. ;-)
Autant le Tibet d'accord, autant Taiwan les normes de Pekin….