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 !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DuboisP
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic a é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/
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic <otomatic@oto.invalid> a
é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/
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic a é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 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.
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
Le Sat, 15 Sep 2012 18:12:02 +0200, Otomatic <otomatic@oto.invalid>
é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.
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.
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.
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
DuboisP <patrickr.dubois.don' écrivait :
quelle est la valeur d'un caractère accentué à l'intérieur du processeur ? le 0 et le 1 ont-ils des accents ?
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 :
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
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 :
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
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 :
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
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…
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…
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
Bonjour,
Le 15/09/2012 18:12, Otomatic a écrit :
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]*' »
Oui. Notons que pour que l'expression rationnelle corresponde au texte en clair il faut inclure la note qui suit, et qui dit ceci : <cit.> Note: Dans nos propos, une lettre peut être a-z, A-Z, et les octets de 127 à 255 (0x7f-0xff). </cit.>
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
Bonjour,
Le 15/09/2012 18:12, Otomatic a écrit :
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]*' »
Oui. Notons que pour que l'expression rationnelle corresponde au texte
en clair il faut inclure la note qui suit, et qui dit ceci :
<cit.>
Note: Dans nos propos, une lettre peut être a-z, A-Z, et les octets de
127 à 255 (0x7f-0xff).
</cit.>
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 !
« 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 : <cit.> Note: Dans nos propos, une lettre peut être a-z, A-Z, et les octets de 127 à 255 (0x7f-0xff). </cit.>
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 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
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
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 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
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>
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
Antoine Polatouche écrivait :
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
Antoine Polatouche <antoine@galacsys.com> écrivait :
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
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
