Mon code source doit-il être en UTF-8?

Je pense que souvent vous ne choisissez pas vraiment le format de votre code. Je veux dire que la plupart de mes outils dans le passé ont décidé pour moi. Ou je n'y ai même pas vraiment pensé. J'utilisais TextPad sur Windows l'autre jour et pendant que j'enregistrais un fichier, cela m'a demandé ASCII, UTF-8/16, Unicode etc etc ...

Je suppose que presque tout le code écrit est ASCII, mais pourquoi devrait-il être ASCII? Devrions-nous réellement utiliser des fichiers UTF-8 maintenant pour le code source, et pourquoi? J'imagine que cela pourrait être utile dans des équipes multilingues. Existe-t-il des normes associées à la façon dont les équipes multilingues nomment les variables / fonctions / etc?

Le choix n'est pas entre ASCII et UTF-8. ASCII est un codage 7 bits, et UTF-8 le remplace - tout texte ASCII valide est également UTF-8 valide. Les problèmes surviennent lorsque vous utilisez des caractères non ASCII; pour ceux-ci, vous devez choisir entre UTF-8, UTF-16, UTF-32 et divers codages 8 bits (ISO-xxxx, etc.).

La meilleure solution est de s'en tenir à un jeu de caractères ASCII strict, c'est-à-dire de ne pas utiliser de caractères non ASCII dans votre code. La plupart des langages de programmation permettent d'exprimer des caractères non ASCII en utilisant des caractères ASCII, par exemple "\u1234"pour indiquer le point de code Unicode à 1234. Surtout, évitez d'utiliser des caractères non ASCII pour les identificateurs. Même s'ils fonctionnent correctement, les personnes qui utilisent une disposition de clavier différente vont vous maudire de leur avoir fait taper ces caractères.

Si vous ne pouvez pas éviter les caractères non ASCII, UTF-8 est votre meilleur pari. Contrairement à UTF-16 et UTF-32, il s'agit d'un sur-ensemble d'ASCII, ce qui signifie que quiconque l'ouvre avec le mauvais encodage obtient au moins la plupart du temps; et contrairement aux pages de codes 8 bits, il peut encoder tous les caractères dont vous aurez besoin, sans ambiguïté, et il est disponible sur tous les systèmes, indépendamment des paramètres régionaux.

Et puis vous avez l'encodage que votre code traite; cela ne doit pas nécessairement être le même que l'encodage de votre fichier source. Par exemple, je peux facilement écrire PHP en UTF-8, mais définir son codage interne multi-octets sur, disons, Latin-1; parce que l'analyseur PHP ne se soucie pas du tout des encodages, mais lit simplement les séquences d'octets, mes littéraux de chaîne UTF-8 seront mal interprétés comme Latin-1. Si je génère ces chaînes sur un terminal UTF-8, vous ne verrez aucune différence, mais les longueurs de chaîne et d'autres opérations multi-octets (par exemple substr) produiront des résultats erronés.

Ma règle d'or consiste à utiliser UTF-8 pour tout; uniquement si vous devez absolument gérer d'autres encodages, convertissez-les en UTF-8 le plus tôt possible et en UTF-8 le plus tard possible.

La plupart des IDE seront enregistrés par défaut avec un encodage UTF-8, et vous devriez presque certainement choisir UTF-8 plutôt que ASCII lorsque vous en aurez la possibilité. Cela vous permettra de ne pas rencontrer de problèmes étranges avec le code d'internationalisation.

Être en mesure de taper du texte brut dans des chaînes ou des caractères entre guillemets dans le code source et pouvoir voir le caractère réel est très agréable. Par exemple, le symbole pi 'π' ou l'idéographe '𠀊' sont beaucoup plus agréables que l'équivalent '\ u3c0' pour pi et L '\ u2000A' pour l'idéographe.

Il est possible de taper et / ou de copier et coller ces caractères directement dans le code source, tout comme vous le feriez pour des caractères ASCII, dans un éditeur décent.

Je trouve des exemples concrets utiles pour conceptualiser et comprendre des choses que les descriptions de mots ne semblent parfois pas conduire à la maison. Conceptualisez les constantes de caractères Unicode saisies dans le code source, telles que l'extrait de code ci-dessous:

const unsigned char  ASCII_0X7E      = (unsigned char)  '~';
const unsigned short UNICODE_0X3C0   = (unsigned short) 'π';
const unsigned long  UNICODE_0X2000A = (unsigned long)  '𠀊';
const unsigned long  UNICODE_0X2893D = (unsigned long)  '𨤽';

Le caractère tilde ASCII «~» peut être enregistré dans un fichier source ASCII ou UTF-8, mais les caractères Unicode ne peuvent pas être stockés sous forme ASCII. Le symbole PI 'π' est le point de code Unicode 0x3c0 et peut être stocké sous forme UTF-8 sous la forme d'une valeur à deux octets 0xcf, 0x80. Les idéogrammes aux points de code Unicode 0x2000a et 0x2893d nécessitent des séquences UTF-8 de 4 octets.

Pour que ces caractères conservent leurs valeurs prévues et que le compilateur les interprète comme prévu, le code source doit être enregistré dans un format qui prend en charge le jeu de caractères Unicode, tel que UTF-8 ou UTF-16. S'il est enregistré en UTF-8, un compilateur décent comprendra et interprétera les valeurs comme prévu et un éditeur décent chargera et affichera les caractères correctement.

Comme d'autres l'ont souligné, si vous n'avez tout simplement aucun caractère dans votre code source en dehors de la plage ASCII, l'enregistrement au format UTF-8 se traduira par un fichier qui n'est pas différent de l'enregistrement d'un fichier ASCII, car UTF- 8 est conçu pour chevaucher ASCII dans la plage de caractères ASCII. Dès que vous tapez un caractère dans votre code source qui est en dehors de la plage ASCII, un éditeur décent vous informera que vous devez choisir un encodage à utiliser pour enregistrer le fichier. UTF-8 est un bon choix car il peut gérer ASCII tel quel et pratiquement tous les autres caractères pris en charge dans votre environnement de développement.