Tu sais, les encodages où tous les caractères ont le même nombre de bits ne concernent que les écritures occidentales simples; les encodages chinois, coréens ou japonais ont *toujours* été avec des caractères de taille variable en octets.
Et puis, avec l'extension de l'espace d'unicode à plusieurs plans, l'UTF-16, qui était sensé être justemment un encodage à longuer fixe d'octets, ne l'est plus, et UTF-16 présente tous les inconvenients de UTF-8 sans en presenter les avantages.
De plus, il est impossible de travailler sur des chaînes de texte unicode caractère par caractère en ignorant le contexte; parcequ'il y a des caractères combinatoires, et des écritures où la forme depends du contexte; donc même en UTF-32 (qui, tout comme UTF-16, est incompatible avec lui même en clair, car il y a des petits et des grands boutistes; alors que UTF-8 est le même partout, encore un avantage de UTF-8), même avec 4 octets par caractère, on ne pourrait pas faire des manipulations aveugles et avoir un programme correct.
UTF-8 est le meilleur encodage à utiliser sur un système de type Unix, vu ces avantages, sa philosophie (c'est en fait une sorte de continuation de EUC (Extended Unix Coding), et, tout simplement, le fait que c'est ce qui est utilisé presque partout (note qu'en interne des boîtes noires que sont pour l'utilisateur les bibliothèques de fonctions, un autre encodage peut être utilisé; ainsi la libc utilise un encodage fixe sur 32 bits il me semble).
[^] # Re: UTF-8 le standard des noms de fichier
Posté par Pablo Saratxaga . En réponse à la dépêche GTK+ 2.6 est disponible. Évalué à 4.
Et puis, avec l'extension de l'espace d'unicode à plusieurs plans, l'UTF-16, qui était sensé être justemment un encodage à longuer fixe d'octets, ne l'est plus, et UTF-16 présente tous les inconvenients de UTF-8 sans en presenter les avantages.
De plus, il est impossible de travailler sur des chaînes de texte unicode caractère par caractère en ignorant le contexte; parcequ'il y a des caractères combinatoires, et des écritures où la forme depends du contexte; donc même en UTF-32 (qui, tout comme UTF-16, est incompatible avec lui même en clair, car il y a des petits et des grands boutistes; alors que UTF-8 est le même partout, encore un avantage de UTF-8), même avec 4 octets par caractère, on ne pourrait pas faire des manipulations aveugles et avoir un programme correct.
UTF-8 est le meilleur encodage à utiliser sur un système de type Unix, vu ces avantages, sa philosophie (c'est en fait une sorte de continuation de EUC (Extended Unix Coding), et, tout simplement, le fait que c'est ce qui est utilisé presque partout (note qu'en interne des boîtes noires que sont pour l'utilisateur les bibliothèques de fonctions, un autre encodage peut être utilisé; ainsi la libc utilise un encodage fixe sur 32 bits il me semble).