Pourquoi Java autorise-t-il les caractères Unicode échappés dans le code source?

J’ai récemment appris qu’Unicode est autorisé dans le code source Java non seulement en tant que caractères Unicode (par exemple, double π = Math.PI; ) mais aussi en tant que séquences d’ double \u03C0 = Math.PI; (par exemple, double \u03C0 = Math.PI; ).

La première variante a un sens pour moi – elle permet aux programmeurs de nommer les variables et les méthodes dans une langue internationale de leur choix. Cependant, je ne vois aucune application pratique de la seconde approche.

Voici quelques morceaux de code pour illustrer l’utilisation, testés avec Java SE 6 et NetBeans 6.9.1:

Ce code sera imprimé 3.141592653589793

 public static void main(Ssortingng[] args) { double π = Math.PI; System.out.println(\u03C0); } 

Explication: π et \ u03C0 sont les mêmes caractères Unicode

Ce code n’imprimera rien

 public static void main(Ssortingng[] args) { double π = Math.PI; /\u002A System.out.println(π); /* a comment */ } 

Explication: Le code ci-dessus code en fait:

 public static void main(Ssortingng[] args) { double π = Math.PI; /* System.out.println(π); /* a comment */ } 

Ce qui commente le satement d’impression.

Juste à partir de mes exemples, je remarque un certain nombre de problèmes potentiels avec cette fonctionnalité de langage.

Tout d’abord, un mauvais programmeur pourrait l’utiliser pour commenter secrètement des bits de code, ou créer plusieurs façons d’identifier la même variable. Peut-être y a-t-il d’autres choses horribles qui peuvent être faites et auxquelles je n’ai pas pensé.

Deuxièmement, les IDE semblent manquer de soutien. Ni NetBeans ni Eclipse n’ont fourni la mise en évidence correcte du code pour les exemples. En fait, NetBeans a même marqué une erreur de syntaxe (bien que la compilation n’était pas un problème).

Enfin, cette fonctionnalité est mal documentée et n’est généralement pas acceptée. Pourquoi un programmeur utiliserait-il quelque chose dans son code que d’autres programmeurs ne pourraient pas reconnaître et comprendre? En fait, je ne pouvais même pas trouver quelque chose à ce sujet sur la question des fonctionnalités cachées de Java .

Ma question est la suivante:

Pourquoi Java autorise-t-il l’utilisation de séquences Unicode échappées dans la syntaxe? Quels sont les “avantages” de cette fonctionnalité qui lui ont permis de restr une partie de Java, malgré ses nombreux “inconvénients”?

Les séquences d’échappement Unicode vous permettent de stocker et de transmettre votre code source en ASCII pur, tout en utilisant toute la gamme des caractères Unicode. Cela présente deux avantages:

  • Aucun risque que des caractères non-ASCII ne soient brisés par des outils qui ne les supportent pas. Cela a été une véritable préoccupation au début des années 1990 lorsque Java a été conçu. Envoyer un email contenant des caractères non-ASCII et le faire arriver en pièces détachées était l’exception plutôt que la norme.

  • Inutile d’indiquer au compilateur et à l’éditeur / IDE quel encodage utiliser pour interpréter le code source. C’est toujours une préoccupation très valable. Bien sûr, une solution bien meilleure aurait été d’avoir le codage en tant que métadonnées dans un en-tête de fichier (comme en XML), mais cela n’avait pas encore émergé comme une meilleure pratique à l’époque.

La première variante a un sens pour moi – elle permet aux programmeurs de nommer les variables et les méthodes dans une langue internationale de leur choix. Cependant, je ne vois aucune application pratique de la seconde approche.

Les deux généreront exactement le même code d’octet et auront la même puissance qu’une fonctionnalité de langage. La seule différence réside dans le code source.

Tout d’abord, un mauvais programmeur pourrait l’utiliser pour commenter secrètement des bits de code, ou créer plusieurs façons d’identifier la même variable.

Si vous craignez qu’un programmeur ne sabote délibérément la lisibilité de votre code, cette fonctionnalité linguistique est le moindre de vos problèmes.

Deuxièmement, les IDE semblent manquer de soutien.

C’est à peine la faute de la fonctionnalité ou de ses concepteurs. Mais alors, je ne pense pas que cela ait jamais été destiné à être utilisé “manuellement”. Idéalement, l’EDI aurait l’option de vous demander d’entrer les caractères normalement et de les afficher normalement, mais de les enregistrer automatiquement en tant que séquences d’échappement Unicode. Il peut même y avoir déjà des plugins ou des options de configuration permettant aux IDE de se comporter de la sorte.

Mais en général, cette fonctionnalité semble être très rarement utilisée et donc probablement mal supscope. Mais comment les gens qui ont conçu Java vers 1993 ont-ils pu le savoir?

La bonne chose à propos du codage \u03C0 est qu’il est beaucoup moins probable qu’un éditeur de texte avec des parameters de codage incorrects vous le transmette. Par exemple, un bug dans mon logiciel a été causé par la transformation accidentelle de UTF-8 é en MacRoman é par un éditeur de texte mal configuré. En spécifiant le sharepoint code Unicode, ce que vous voulez dire est sans ambiguïté.

La syntaxe \ uXXXX permet aux caractères Unicode d’être représentés sans ambiguïté dans un fichier avec un codage non capable de les exprimer directement, ou si vous souhaitez qu’une représentation soit utilisable même dans le plus petit dénominateur commun, à savoir un codage ASCII 7 bits.

Vous pourriez représenter tous vos personnages avec \ uXXXX, même des espaces et des lettres, mais il est rarement nécessaire de le faire.

Tout d’abord, merci pour la question. Je pense que c’est très intéressant. Deuxièmement, le fichier source Java est un texte qui peut utiliser différents jeux de caractères. Par exemple, le jeu de caractères par défaut dans Eclipse est Cp1255. Cet endodage ne supporte pas les caractères comme π. Je pense qu’ils ont pensé aux programmeurs qui doivent travailler sur des systèmes qui ne prennent pas en charge unicode et souhaitent permettre à ces programmeurs de créer des logiciels compatibles Unicode. C’était la raison de soutenir la notation.