Question

Il y a presque 5 ans, Joel Spolsky écrivait cet article : "Le minimum absolu que tout développeur de logiciels doit absolument connaître sur l'Unicode et les jeux de caractères (aucune excuse !)".

Comme beaucoup, je l'ai lu attentivement, réalisant qu'il était grand temps de me familiariser avec ce "remplacement de l'ASCII".Malheureusement, 5 ans plus tard, j'ai l'impression d'avoir repris quelques mauvaises habitudes dans ce domaine.Avez-vous?

Je n'écris pas beaucoup d'applications spécifiquement internationales, mais j'ai aidé à créer de nombreux sites Web ASP.NET accessibles sur Internet, donc je suppose que ce n'est pas une excuse.

Donc, pour mon bénéfice (et je crois bien d'autres), puis-je obtenir l'avis de personnes sur les points suivants :

  • Comment « surmonter » l’ASCII une fois pour toutes
  • Conseils fondamentaux lorsque vous travaillez avec Unicode.
  • Livres et sites Web (récents) recommandés sur Unicode (pour les développeurs).
  • État actuel d'Unicode (5 ans après l'article de Joels)
  • Directions futures.

Je dois admettre que j'ai une expérience .NET et je serais donc également heureux d'obtenir des informations sur Unicode dans le framework .NET.Bien sûr, cela ne devrait pas empêcher toute personne ayant un parcours différent de commenter.

Mise à jour:Voir cette question connexe également demandé sur StackOverflow précédemment.

Était-ce utile?

La solution

Depuis que j'ai lu l'article de Joel et quelques autres articles de I18n, j'ai toujours gardé un œil attentif sur l'encodage de mes caractères ;Et cela fonctionne réellement si vous le faites régulièrement.Si vous travaillez dans une entreprise où il est standard d'utiliser UTF-8 et que tout le monde le sait/le fait, cela fonctionnera.

Voici quelques articles intéressants (outre l'article de Joël) sur le sujet :

Une citation du premier article ;Conseils pour utiliser Unicode :

  • Adoptez Unicode, ne le combattez pas ;c'est probablement la bonne chose à faire, et si ce n'était pas le cas, vous auriez probablement dû le faire de toute façon.
  • Dans votre logiciel, stockez le texte au format UTF-8 ou UTF-16 ;c'est-à-dire, choisissez l'un des deux et respectez-le.
  • Échanger des données avec le monde extérieur en utilisant XML autant que possible ;cela fait disparaître tout un tas de problèmes potentiels.
  • Essayez de créer votre application basée sur un navigateur plutôt que d'écrire votre propre client ;les navigateurs deviennent vraiment très bons pour traiter les textes du monde.
  • Si vous utilisez le code de la bibliothèque de quelqu'un d'autre (et bien sûr vous l'êtes), supposez que sa gestion Unicode est interrompue jusqu'à ce qu'elle soit correcte.
  • Si vous effectuez une recherche, essayez de confier les problèmes linguistiques et de gestion des caractères à quelqu'un qui les comprend.
  • Allez sur Amazon ou ailleurs et achetez la dernière révision de la norme Unicode imprimée ;il contient à peu près tout ce que vous devez savoir.
  • Passez du temps à parcourir le site Web Unicode et à apprendre comment fonctionnent les tableaux de codes.
  • Si vous devez travailler sérieusement sur les langues asiatiques, achetez le livre O'Reilly sur le sujet de Ken Lunde.
  • Si vous avez un Macintosh, lancez-vous et récupérez l'outil d'inspection des polices Unicode de Lord Pixel.Totallement cool.
  • Si vous devez vraiment vous occuper des données, allez assister à l'une des conférences Unicode semestrielles.Tous les experts y vont et si vous ne savez pas ce que vous devez savoir, vous pourrez y trouver quelqu'un qui sait.

Autres conseils

J'ai passé du temps à travailler avec un logiciel de moteur de recherche. Vous n'imaginez pas combien de sites Web proposent du contenu avec des en-têtes HTTP ou des balises méta qui mentent sur l'encodage des pages.Souvent, vous obtiendrez même un document contenant à la fois des caractères ISO-8859 et des caractères UTF-8.

Une fois que vous avez résolu quelques-uns de ces types de problèmes, vous commencez à prendre très au sérieux le codage approprié des caractères des données que vous produisez.

Le .NET Framework utilise le codage par défaut de Windows pour stocker les chaînes, qui s'avère être UTF-16.Si vous ne spécifiez pas d'encodage lorsque vous utilisez la plupart des classes d'E/S de texte, vous écrirez UTF-8 sans BOM et lisez en vérifiant d'abord une nomenclature, puis en supposant UTF-8 (je sais avec certitude StreamReader et StreamWriter comportez-vous de cette façon.) C'est assez sûr pour les éditeurs de texte "stupides" qui ne comprendront pas une nomenclature, mais un peu grossier pour les plus intelligents qui pourraient afficher UTF-8 ou la situation dans laquelle vous écrivez réellement des caractères en dehors de la plage ASCII standard. .

Normalement, il est invisible, mais il peut relever la tête de manière intéressante.Hier, je travaillais avec quelqu'un qui utilisait la sérialisation XML pour sérialiser un objet en chaîne à l'aide d'un StringWriter, et il n'arrivait pas à comprendre pourquoi l'encodage était toujours UTF-16.Puisqu'une chaîne en mémoire sera UTF-16 et qu'elle est appliquée par .NET, c'est la seule chose que le framework de sérialisation XML peut faire.

Ainsi, lorsque j'écris quelque chose qui n'est pas seulement un outil jetable, je spécifie un encodage UTF-8 avec une nomenclature.Techniquement, dans .NET, vous serez toujours accidentellement conscient d'Unicode, mais seulement si votre utilisateur sait détecter votre codage en UTF-8.

Cela me fait pleurer un peu à chaque fois que je vois quelqu'un demander: "Comment puis-je obtenir les octets d'une chaîne?" Et la solution suggérée utilise Encoding.ASCII.GetBytes() :(

Règle générale :si vous ne fouillez jamais ou ne regardez jamais à l'intérieur d'une chaîne et que vous la traitez plutôt strictement comme une goutte de données, vous vous en sortirez bien mieux.

Même faire quelque chose d'aussi simple que diviser des mots ou mettre des chaînes en minuscules devient difficile si vous voulez le faire "à la manière Unicode".

Et si vous voulez le faire "à la manière Unicode", vous aurez besoin d'une très bonne bibliothèque.Ce truc est incroyablement complexe.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top