Noms des variables et jeux de caractères.

Le
Otomatic
Bonjour,

Dans la documentation PHP, au sujet du nom des variables, il est écrit

« Les noms de variables suivent les mêmes règles de nommage que les
autres entités PHP.
Un nom de variable valide doit commencer par une lettre ou un souligné
(_), suivi de lettres, chiffres ou soulignés.
Exprimé sous la forme d'une expression régulière, cela donne :
'[a-zA-Z_x7f-xff][a-zA-Z0-9_x7f-xff]*' »

Cela veut-il dire que l'on a le droit d'utiliser, par exemple, les
caractères accentués dans les noms de variables et d'index de tableau ?

Cela me paraît quelque peu ambigu, car, selon l'environnement dans
lequel on se trouve, le nom de la variable n'apparaîtra pas avec les
même glyphes et même, pourra générer des problèmes, voire même des
erreurs.

En effet, une variable nommée $éléphant dans un environnement Mac (Jeu
de caractères MacRoman) comprend bien deux caractères "é" qui, en
MacRoman est codé 0x8e et se trouve bien dans la plage x7f-xff
autorisée. Mais, le même script PHP, lu dans un environnement ISO-8859-1
soit verra la variable sous le nom $?l?phant soit générera une erreur
puisque, en ISO-8859-1 la plage 0x7f-0x9f est vide de tout caractère.

N'est-il pas préférable de se limiter à [a-zA-Z_][a-zA-Z0-9_] (ASCII) et
ne jamais mettre de caractères dans la plage x7f-xff ?
--
Le logiciel de courrier d'Opera n'a rien de révolutionnaire
Forté Agent en faisait déjà autant, et même beaucoup plus, depuis trois lustres
Tout comme The Bat depuis belle lurette !
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
DuboisP
Le #24786512
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic écrit:

Bonjour,

Dans la documentation PHP, au sujet du nom des variables, il est écrit

« Les noms de variables suivent les mêmes règles de nommage que les
autres entités PHP.
Un nom de variable valide doit commencer par une lettre ou un souligné
(_), suivi de lettres, chiffres ou soulignés.
Exprimé sous la forme d'une expression régulière, cela donne :
'[a-zA-Z_x7f-xff][a-zA-Z0-9_x7f-xff]*' »

Cela veut-il dire que l'on a le droit d'utiliser, par exemple, les
caractères accentués dans les noms de variables et d'index de tableau ?

Cela me paraît quelque peu ambigu, car, selon l'environnement dans
lequel on se trouve, le nom de la variable n'apparaîtra pas avec les
même glyphes et même, pourra générer des problèmes, voire même des
erreurs.

En effet, une variable nommée $éléphant dans un environnement Mac (Jeu
de caractères MacRoman) comprend bien deux caractères "é" qui, en
MacRoman est codé 0x8e et se trouve bien dans la plage x7f-xff
autorisée. Mais, le même script PHP, lu dans un environnement ISO-8859-1
soit verra la variable sous le nom $?l?phant soit générera une erreur
puisque, en ISO-8859-1 la plage 0x7f-0x9f est vide de tout caractère.

N'est-il pas préférable de se limiter à [a-zA-Z_][a-zA-Z0-9_] (ASCII) et
ne jamais mettre de caractères dans la plage x7f-xff ?



quelle est la valeur d'un caractère accentué à l'intérieur du processeur ?
le 0 et le 1 ont-ils des accents ?
--
Utilisant le logiciel de courrier révolutionnaire d'Opera :
http://www.opera.com/mail/
Denis Beauregard
Le #24786722
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic écrivait dans fr.comp.lang.php:

Bonjour,

Dans la documentation PHP, au sujet du nom des variables, il est écrit

« Les noms de variables suivent les mêmes règles de nommage que les
autres entités PHP.
Un nom de variable valide doit commencer par une lettre ou un souligné
(_), suivi de lettres, chiffres ou soulignés.
Exprimé sous la forme d'une expression régulière, cela donne :
'[a-zA-Z_x7f-xff][a-zA-Z0-9_x7f-xff]*' »

Cela veut-il dire que l'on a le droit d'utiliser, par exemple, les
caractères accentués dans les noms de variables et d'index de tableau ?

Cela me paraît quelque peu ambigu, car, selon l'environnement dans
lequel on se trouve, le nom de la variable n'apparaîtra pas avec les
même glyphes et même, pourra générer des problèmes, voire même des
erreurs.

En effet, une variable nommée $éléphant dans un environnement Mac (Jeu
de caractères MacRoman) comprend bien deux caractères "é" qui, en
MacRoman est codé 0x8e et se trouve bien dans la plage x7f-xff
autorisée. Mais, le même script PHP, lu dans un environnement ISO-8859-1
soit verra la variable sous le nom $?l?phant soit générera une erreur
puisque, en ISO-8859-1 la plage 0x7f-0x9f est vide de tout caractère.

N'est-il pas préférable de se limiter à [a-zA-Z_][a-zA-Z0-9_] (ASCII) et
ne jamais mettre de caractères dans la plage x7f-xff ?



Je viens de regarder la documentation officielle et il y a un exemple
avec des lettres grecques.

http://php.net/manual/fr/language.variables.basics.php

Il me semble évident que si on change d'environnement, les caractères
du nouvel environnement auront été convertis et donc que éléphant sur
un Mac va rester éléphant sur Windows ou Linux. Je dirais que ce qui
est permis, c'est tout caractère dans le jeu courant s'il fait 7 ou 8
octets, donc pas de UTF16.


Denis
Otomatic
Le #24786772
DuboisP
quelle est la valeur d'un caractère accentué à l'intérieur du processeur ?
le 0 et le 1 ont-ils des accents ?



Non... mais... j'ai quand même un doute en utf-8

<?php
$éléphant = 22;

00000000h: 3C 3F 70 68 70 0A 24 C3 A9 6C C3 A9 70 68 61 6E ; <?php.$éléphan
00000010h: 74 20 3D 20 32 32 3B 0A 0A 2F 2A 2A 2A 2A 2A 2A ; t = 22;../******



Doute qui n'a pas lieu d'être puisque chaque octet du nom de la variable
est dans la bonne plage autorisée. Ce n'est que la visualisation du nom
qui changera en fonction de l'environnement :

$éléphant en utf-8

$éléphant en iso-8859-1

PHP, lui s'en fout, mais *j'étais* quand même réticent à utiliser des
caractères accentués dans les noms des variables ou des index de
tableau.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
Antoine Polatouche
Le #24789852

$éléphant en utf-8

$éléphant en iso-8859-1

PHP, lui s'en fout, mais *j'étais* quand même réticent à utiliser des
caractères accentués dans les noms des variables ou des index de
tableau.



Utilise $mammouth alors, c'est plus sûr.

Trève de plaisanterie, je ne comprends pas comment on peut encore, en
2012 utiliser des fichiers php en iso-8859, ou autre relique d'un âge passé.

Utiliser systématiquement UTF8 et n'utiliser que des éditeurs dignes de
ce nom, c'est-à-dire qui acceptent d'office l'utf8, permet d'avoir des
fichiers php lisibles partout par les bons éditeurs.

Le problème ne se pose pas seulement pour les noms de variables, toutes
les chaînes de caractères seront bouzillées également par les éditeurs
qui ne reconnaissent pas correctement l'encodage…
Olivier Miakinen
Le #24789972
Bonjour,

Le 15/09/2012 18:12, Otomatic a écrit :

Dans la documentation PHP, au sujet du nom des variables, il est écrit



http://www.php.net/manual/fr/language.variables.basics.php

« Les noms de variables suivent les mêmes règles de nommage que les
autres entités PHP.
Un nom de variable valide doit commencer par une lettre ou un souligné
(_), suivi de lettres, chiffres ou soulignés.
Exprimé sous la forme d'une expression régulière, cela donne :
'[a-zA-Z_x7f-xff][a-zA-Z0-9_x7f-xff]*' »



Oui. Notons que pour que l'expression rationnelle corresponde au texte
en clair il faut inclure la note qui suit, et qui dit ceci :
Note: Dans nos propos, une lettre peut être a-z, A-Z, et les octets de
127 à 255 (0x7f-0xff).

Cela veut-il dire que l'on a le droit d'utiliser, par exemple, les
caractères accentués dans les noms de variables et d'index de tableau ?



Oui, tant que les caractères accentués sont constitués uniquement
d'octets dont les valeurs sont celles spécifiées. C'est le cas pour
les jeux de caractères mono-octets dont la partie basse est identique
à US-ASCII (ISO-8859-n, CP1252, CP850, MacRoman, ...) mais aussi pour
UTF-8 (tout caractère en dehors de US-ASCII est constitué d'au moins
deux octets, tous dans 0x7f-0xff).

Attention, ce n'est *pas* le cas pour UTF-16 par exemple. Mais qui
utilise UTF-16 ? D'ailleurs le problème existe déjà sans les
caractères accentués.

Cela me paraît quelque peu ambigu,



Ce n'est pas ambigu, c'est juste que la définition de « lettre » est en
contradiction avec l'usage courant. ;-) En réalité, la définition basée
sur les valeurs d'octets est indépendante du jeu de caractères choisi,
pourvu que la table US-ASCII soit respectée dans ce jeu de caractères.

car, selon l'environnement dans
lequel on se trouve, le nom de la variable n'apparaîtra pas avec les
même glyphes et même, pourra générer des problèmes, voire même des
erreurs.



L'interpréteur PHP se fout pas mal des glyphes. Si un programme PHP
écrit dans un éditeur de texte avec un charset donné est lu ensuite
en supposant un autre charset, effectivement le relecteur humain
verra des trucs bizarres, mais ça n'empêchera pas le programme de
fonctionner.

Cela dit, tu as raison, il peut y avoir des problèmes si celui qui
a édité le fichier décide de le sauver sur disque, éventuellement
après l'avoir modifié, et que certains des octets lus sont modifiés
par l'éditeur de texte du fait qu'ils ne correspondaient pas à des
encodages valides !

En effet, une variable nommée $éléphant dans un environnement Mac (Jeu
de caractères MacRoman) comprend bien deux caractères "é" qui, en
MacRoman est codé 0x8e et se trouve bien dans la plage x7f-xff
autorisée. Mais, le même script PHP, lu dans un environnement ISO-8859-1
soit verra la variable sous le nom $?l?phant soit générera une erreur
puisque, en ISO-8859-1 la plage 0x7f-0x9f est vide de tout caractère.



Oui, c'est possible. Plus probablement, surtout si la machine utilisée
est un Windows ou un Linux, ce « é » MacRoman sera affiché comme un
« ´ » CP1252 car de nombreux éditeurs ne distinguent pas CP1252 de
ISO-8859-1...
http://www.miakinen.net/vrac/charsets/?or=6&pr2

Mais ça buguera plus probablement si tu lis du MacRoman comme si c'était
de l'UTF-8, car aucun texte UTF-8 ne peut contenir un octet 0x8e entouré
de deux octets inférieurs à 0x7f.

N'est-il pas préférable de se limiter à [a-zA-Z_][a-zA-Z0-9_] (ASCII) et
ne jamais mettre de caractères dans la plage x7f-xff ?



Beaucoup le pensent, surtout parmi ceux dont la langue maternelle a
une écriture basée sur le latin (avec ou sans accents). Pour ma part,
par habitude, je continue à ne pas accentuer mes noms de variables,
alors que je n'hésite pas à mettre des accents dans les chaînes de
caractères et dans les commentaires.

Cela étant dit, ce qui serait « préférable », ce serait de se limiter
au seul jeu de caractères UTF-8 (comme environnement) plutôt que
US-ASCII (comme répertoire de caractères). C'est quand même de plus
en plus souvent le cas.

Et puis surtout, voyons un peu plus loin que le bout de notre nez
occidental et latin : pour ceux dont la langue s'écrit avec des
caractères cyrilliques, des idéogrammes, des lettres grecques,
etc., pourvoir ne pas se limiter à US-ASCII est quand même d'un
confort extraordinaire !

Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Le #24790572
Le 15/09/2012 19:52, Otomatic a écrit :

[...]

Doute qui n'a pas lieu d'être puisque chaque octet du nom de la variable
est dans la bonne plage autorisée. [...]



Oui. Désolé d'avoir répondu à ton premier article sans voir que tu
avais déjà levé tout doute concernant UTF-8. Quoi qu'il en soit, je
le confirme : tant que tu ne changes pas de jeu de caractères d'un
éditeur à un autre, il est sans danger d'utiliser les caractères
accentués dans n'importe lequel des cas suivants :
- ISO-8859-n (quel que soit n)
- MacRoman
- CP1252 (et même CP850, mais pas les smileys CP437 !)
- UTF-8

Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Le #24790562
Le 16/09/2012 23:05, Antoine Polatouche a écrit :

Trève de plaisanterie, je ne comprends pas comment on peut encore, en
2012 utiliser des fichiers php en iso-8859, ou autre relique d'un âge passé.

Utiliser systématiquement UTF8



<mode pointilleux ON>
UTF-8
<mode coupeur de cheveux en quatre OFF>

et n'utiliser que des éditeurs dignes de
ce nom, c'est-à-dire qui acceptent d'office l'utf8, permet d'avoir des
fichiers php lisibles partout par les bons éditeurs.



Oui. Ajoutons comme critère d'un bon éditeur UTF-8 qu'il ne doit
pas écrire d'indicateur d'ordre des octets Unicode (BOM, Byte Order
Mark) au début du fichier. Outre que c'est stupide dans le cas
d'UTF-8, cela empêche généralement les scripts PHP de fonctionner.

Le problème ne se pose pas seulement pour les noms de variables, toutes
les chaînes de caractères seront bouzillées également par les éditeurs
qui ne reconnaissent pas correctement l'encodage



Exactement.





<mode moqueur ON>
À propos de relique d'un âge passé, sans ce caractère je crois que ton
article n'aurait pas été émis en Windows-1252. ;-)
<OFF>

--
Olivier Miakinen
Otomatic
Le #24790742
Antoine Polatouche
Utiliser systématiquement UTF8 et n'utiliser que des éditeurs dignes de
ce nom, c'est-à-dire qui acceptent d'office l'utf8, permet d'avoir des
fichiers php lisibles partout par les bons éditeurs.


Bonjour,

Merci à tous. Les dernières « réticences » sont parties en fumée.

Nota : Comme éditeur(s) j'utilise principalement UltraEdit et parfois
Notepad++ et jamais Notepad de Windows (Sauf pour visualiser un fichier)
qui m'a déjà joué des tours en sauvegardant avec BOM subrepticement.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche
Publicité
Poster une réponse
Anonyme