Un de mes animaux de compagnie regarde tant de projets logiciels qui contiennent des montagnes de code pour la prise en charge des jeux de caractères. Ne vous méprenez pas, je suis pour la compatibilité et je suis heureux que les éditeurs de texte vous permettent d'ouvrir et d'enregistrer des fichiers dans plusieurs jeux de caractères. Ce qui m'agace, c'est comment la prolifération des encodages de caractères non universels est étiquetée «prise en charge Unicode appropriée» plutôt que «problème».
Par exemple, permettez-moi de choisir PostgreSQL et sa prise en charge des jeux de caractères . PostgreSQL gère deux types d'encodages:
- Encodage client: utilisé dans la communication entre le client et le serveur.
- Encodage serveur: utilisé pour stocker le texte en interne dans la base de données.
Je peux comprendre pourquoi la prise en charge de nombreux encodages client est une bonne chose. Il permet aux clients qui ne fonctionnent pas en UTF-8 de communiquer avec PostgreSQL sans avoir à effectuer eux-mêmes la conversion. Ce que je ne comprends pas, c'est: pourquoi PostgreSQL supporte-t-il plusieurs encodages de serveur ? Les fichiers de base de données sont (presque toujours) incompatibles d'une version PostgreSQL à la suivante, donc la compatibilité entre les versions n'est pas le problème ici.
UTF-8 est le seul jeu de caractères standard compatible ASCII qui peut coder tous les points de code Unicode (si je me trompe, faites le moi savoir). Je suis dans le camp que UTF-8 est le meilleur jeu de caractères, mais je suis prêt à accepter d'autres jeux de caractères universels tels que UTF-16 et UTF-32.
Je pense que tous les jeux de caractères non universels devraient être dépréciés. Y a-t-il une raison impérieuse de ne pas le faire?