Étant donné que l'Unicode a été autour depuis 18 ans, pourquoi il y a encore des applications qui n'ont pas de support de l'Unicode? Même mes expériences avec certains systèmes d'exploitation et Unicode ont été douloureuses pour dire le moins. Comme Joel Spolsky souligné en 2003, il n'est pas difficile. Alors quel est le problème? Pourquoi ne pouvons-nous faire ensemble?
Réponses
Trop de publicités?
Commencer par poser quelques questions
Comment souvent...
- avez-vous besoin d'écrire une application qui traite d'autre chose que de l'ascii?
- avez-vous besoin d'écrire un multi-langue de l'application?
- avez-vous écrire une application qui a pour être multi-langue dans sa première version?
- avez-vous entendu parler de l'Unicode est utilisé pour représenter les caractères non-ascii?
- avez-vous lu que l'Unicode est un jeu de caractères? Unicode est un encodage?
- voyez-vous les gens à confusion codé en UTF-8 bytestrings et des données Unicode?
Connaissez-vous la différence entre un classement et un encodage?
Où avez-vous entendu parler de l'Unicode?
- À l'école? (vraiment?)
- au travail?
- sur une tendance de blog?
Avez-vous déjà, dans votre jeune jours, a connu le déplacement de la source de fichiers à partir d'un système de localisation d'un système de paramètres régionaux B, a édité une faute de frappe sur le système B, enregistré les fichiers, b0rking tous les non-ascii, les commentaires et... finissant par perdre beaucoup de temps à essayer de comprendre ce qui s'est passé? (a votre éditeur de mélanger les choses? le compilateur? le système? l'... ?)
Vous êtes-vous décidé que plus jamais vous commenter votre code à l'aide des caractères non-ascii?
Jetez un oeil à ce qui se fait ailleurs
Python
Ai-je mentionné sur de SORTE que j'aime Python? Non? Eh bien, j'aime Python.
Mais jusqu'à ce que Python3.0, son support de l'Unicode aspiré. Et il y avait toutes ces recrue programmeurs, qui savait à peine comment écrire une boucle, l'obtention d' UnicodeDecodeError et UnicodeEncodeError de nulle part en essayant de composer avec les caractères non-ascii. Bien ils ont essentiellement eu la vie traumatisés par l'Unicode monstre, et je sais que beaucoup de très efficace/expérimenté Python codeurs qui sont encore peur aujourd'hui à propos de l'idée d'avoir à traiter avec des données Unicode.
Et avec Python3, il existe une séparation claire entre Unicode et bytestrings, mais... regardez comment beaucoup de peine c'est au port d'une application à partir de Python 2.x de Python 3.x si vous l'avez déjà fait pas beaucoup de soins au sujet de la séparation/si vous n'avez pas vraiment comprendre ce que l'Unicode.
Les bases de données, PHP
Connaissez-vous un populaire site commercial, qui stocke ses international de texte en Unicode?
Vous aurez (peut-être) être surpris d'apprendre que Wikipédia backend ne pas stocker ses données à l'aide de l'Unicode. Tout le texte est encodé en UTF-8 et sont stockées en tant que données binaires dans la Base de données.
Une question clé ici est de savoir comment trier les données de texte si vous le stocker comme Unicode codepoints. Voici l'Unicode classements, définir un ordre de tri sur Unicode codepoints. Mais bon soutien pour les classements dans les Bases de données est manquant/est en développement actif. (Il y a probablement beaucoup de problèmes de performance, trop. -- IANADBA) en outre, il n'existe pas de norme reconnue sur le marché pour les classements encore: pour certaines langues, les gens ne sont pas d'accord sur la façon dont les mots/lettres/wordgroups doivent être triés.
Avez-vous entendu parler de la normalisation Unicode? (En gros, vous devez convertir vos données Unicode à une représentation canonique avant de le ranger) bien sûr, il est essentiel pour le stockage de Base de données, locales ou des comparaisons. Mais PHP par exemple ne fournit un soutien pour la normalisation depuis 5.2.4 qui est sorti en août 2007.
Et en fait, PHP ne prend pas complètement en charge Unicode encore. Nous allons devoir attendre PHP6 pour obtenir Unicode compatible avec les fonctions de partout.
Alors, pourquoi n'est-ce pas tout ce que nous faisons en Unicode?
- Certaines personnes n'ont pas besoin d'Unicode.
- Certaines personnes ne se soucient pas.
- Certaines personnes ne comprennent pas qu'ils auront besoin de support de l'Unicode plus tard.
- Certaines personnes ne comprennent pas l'Unicode.
- Pour certains autres, l'Unicode est un peu comme l'accessibilité pour les webapps: vous commencez sans, et va ajouter le support plus tard
- Beaucoup de bibliothèques populaires/les langues/les applications de manque correctes, complètes support de l'Unicode, pour ne pas mentionner le classement et la normalisation des questions. Et jusqu'à ce que tous les éléments dans votre pile de développement complètement en charge Unicode, vous ne pouvez pas écrire un propre application Unicode.
L'Internet clairement contribuant à la diffusion de l'Unicode tendance. Et c'est une bonne chose. Des Initiatives comme Python3 modifications importantes aider à éduquer les gens sur la question. Mais il nous faudra patienter un peu plus pour voir Unicode partout et les nouveaux programmeurs instinctivement à l'aide d'Unicode à la place des cordons où il le faut.
Pour l'anecdote, parce que FedEx ne pas apparemment support des adresses internationales, le Google Summer of Code '09 élèves de tous a été demandé par Google de fournir un ascii-nom et adresse pour l'expédition. Si vous pensez que la plupart des acteurs de comprendre les enjeux derrière le support de l'Unicode, vous êtes tout simplement faux. FedEx ne pas comprendre, et leurs clients ne se soucient pas vraiment. Encore.
Gerard
Points
1672
- De nombreux développeurs de produits ne considèrent pas leurs applications utilisées en Asie ou dans d'autres régions où l'Unicode est une exigence.
- La conversion des applications existantes vers Unicode est coûteux et généralement motivés par des opportunités de vente.
- De nombreuses entreprises ont des produits maintenue sur les anciens systèmes et de la migration vers Unicode signifie une toute nouvelle plate-forme de développement.
- Vous seriez surpris de voir comment de nombreux développeurs de ne pas comprendre toutes les implications de l'Unicode dans un environnement multilingue. Ce n'est pas seulement un cas de l'utilisation de l'échelle de cordes.
Ligne du bas - coût.
Eric
Points
35647
PeterAllenWebb
Points
4731
La disponibilité généralisée des outils de développement pour travailler avec Unicode peut être plus récente de l'événement que vous le supposez. Travailler avec Unicode a été, jusqu'à il y a quelques années, une pénible tâche de convertir entre les formats de caractères et de traiter avec incomplètes ou buggy implémentations. Vous dites qu'il n'est pas difficile, et que les outils d'améliorer qui est de plus en plus vrai, mais il y a beaucoup de façons de voyage, sauf si les détails sont masqués par les bons langues et des bibliothèques. Hell, il suffit de couper et coller des caractères unicode pourrait être une proposition discutable quelques années en arrière. Développeur de l'éducation a également pris un certain temps, et vous pouvez encore voir les gens faire une tonne d'erreurs de base.
Le standard Unicode pèse probablement de dix livres. Même juste un aperçu de il aurait à discuter les distinctions subtiles entre les personnages, les glyphes, codepoints, etc. Maintenant, pensez à l'ASCII. C'est de 128 caractères. Je peux vous expliquer la chose entière pour quelqu'un qui sait binaire en environ 5 minutes.
Je crois que presque tous les logiciels doivent être écrits avec support complet Unicode ces jours, mais il a été un long chemin pour arriver à un véritable jeu de caractères internationaux avec le codage de s'adapter à une variété de fins, et il n'est pas encore terminé.
Quinn Taylor
Points
29688
Un facteur important est le support de langages de programmation, dont la plupart utilisent un jeu de caractères qui correspond à 8 bits (ASCII par exemple) comme valeur par défaut pour les chaînes. Java de la classe String utilise UTF-16, et il ya d'autres qui prennent en charge les variantes de l'Unicode, mais de nombreuses langues, optez pour la simplicité. L'espace est donc triviale d'une préoccupation ces jours-ci que les codeurs qui s'accrochent à "efficace de l'espace" les chaînes doivent être giflé. La plupart des gens ne sont tout simplement pas en cours d'exécution sur les systèmes embarqués, et même des appareils comme les téléphones cellulaires (le grand le calcul de la vague de l'avenir proche) peut facilement manipuler 16 bits jeux de caractères.
Un autre facteur est que de nombreux programmes sont écrits uniquement en anglais, et les développeurs (1) n'est pas plan (ou même de savoir comment) pour localiser leur code pour plusieurs langues, et (2) ils n'ont souvent pas même de penser à la manipulation d'entrée dans la non-langues Romaines. L'anglais est la dominante naturelle de la langue parlée par les programmeurs (au moins, de communiquer les uns avec les autres) et, dans une large mesure, qui a porté sur le logiciel que nous produisons. Cependant, l'apathie et/ou l'ignorance ne peut certainement pas durer éternellement... compte tenu du fait que le marché de la téléphonie mobile en Asie complètement éclipse la plupart du reste du monde, les programmeurs vont avoir à traiter avec Unicode assez vite, qu'ils le veuillent ou non.
Pour ce que ça vaut, je ne pense pas que la complexité de la norme Unicode n'est pas que les grandes d'un facteur de contribution pour les programmeurs, mais plutôt à ceux qui doivent mettre en œuvre support de la langue. Lors de la programmation dans une langue où le travail a déjà été fait, il y a encore moins de raison de ne pas utiliser les outils à portée de main. C est la vie, les vieilles habitudes ont la vie dure.
