J'ai un pb alakon : je récupère un nom qui contient des accents en iso
latin, et je voudrais faire un fichier avec ce nom... il faut que je
recode en quoi pour que ça marche avec OSX ?
Apparament un é est codé avec e\341\201 (en octal) mais c'est quoi comme
codage ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
La totale discutabilité du sens de neutraliser ici rend cette proposition totalement incorrecte.
Moi, je propose caractère de bravitude, et bravituder un caractère. Ça le fait pas ? -- F. J.
Paul Gaborit
À (at) Wed, 10 Jan 2007 19:10:12 +0100, (JPaul) écrivait (wrote): [...]
Maintenant on peut aussi dire simplement "guillemets" puisque c'est de ces caractères qu'il s'agissait. D'autres caractères de neutralisations sont parfois les "apostrophes", les deux étant parfois remplacés par le mot anglais "quote" qui conduit à l'affreux : "les caractères entre quotes sont neutralisés" ;-) Enfin on peut souvent neutraliser avec un "back-slash", et là désolé, je n'ai pas de traduction.
Attention, il ne faut pas confondre le nom du caractère lui-même et son rôle. Il se trouve que parfois le caractère barre oblique inversée (le backslash) est le caractère d'échappement. Mais ce n'est pas toujours ce caractère qui est choisi.
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser le n qui suit mais bien au contraire de lui donner un autre sens que le sens habituel dans le contexte d'une chaîne entre guillemets.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Jan 2007 19:10:12 +0100,
blanc@empty.org (JPaul) écrivait (wrote):
[...]
Maintenant on peut aussi dire simplement "guillemets" puisque c'est de
ces caractères qu'il s'agissait.
D'autres caractères de neutralisations sont parfois les "apostrophes",
les deux étant parfois remplacés par le mot anglais "quote" qui conduit
à l'affreux : "les caractères entre quotes sont neutralisés" ;-)
Enfin on peut souvent neutraliser avec un "back-slash", et là désolé, je
n'ai pas de traduction.
Attention, il ne faut pas confondre le nom du caractère lui-même et
son rôle. Il se trouve que parfois le caractère barre oblique inversée
(le backslash) est le caractère d'échappement. Mais ce n'est pas
toujours ce caractère qui est choisi.
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des
caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une
manière de spécifier une chaîne de caractères avec ou sans
interpolation (comme en dit Perl).
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit
également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque
j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser
le n qui suit mais bien au contraire de lui donner un autre sens que
le sens habituel dans le contexte d'une chaîne entre guillemets.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 10 Jan 2007 19:10:12 +0100, (JPaul) écrivait (wrote): [...]
Maintenant on peut aussi dire simplement "guillemets" puisque c'est de ces caractères qu'il s'agissait. D'autres caractères de neutralisations sont parfois les "apostrophes", les deux étant parfois remplacés par le mot anglais "quote" qui conduit à l'affreux : "les caractères entre quotes sont neutralisés" ;-) Enfin on peut souvent neutraliser avec un "back-slash", et là désolé, je n'ai pas de traduction.
Attention, il ne faut pas confondre le nom du caractère lui-même et son rôle. Il se trouve que parfois le caractère barre oblique inversée (le backslash) est le caractère d'échappement. Mais ce n'est pas toujours ce caractère qui est choisi.
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser le n qui suit mais bien au contraire de lui donner un autre sens que le sens habituel dans le contexte d'une chaîne entre guillemets.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Vincent Lefevre
Dans l'article <1hrhega.7k2cee8tkhpaN%, FiLH écrit:
Hum... de mon expérience iconv est chiantissime... qu'on puisse préférer controller sa propre version.
Et surtout, la version Mac (1.9) a 4 ans de retard!
Au moins, avec la dernière version, on peut écrire quelque chose du genre:
Si tu parles de Mac OS X, alors pour écrire un fichier en utilisant un appel système du noyau (open avec O_CREAT), il faut que le nom soit de l'UTF-8 valide. Tout caractère binaire, type ISO-8859-1, entraînera une erreur.
Même dans un shell, en utilisant des guillemets ?
Le shell va interpréter selon la locale qu'il aura. Mais il est plus simple d'avoir son mac tout en utf-8 avec un shell qui le supporte, comme un zsh récent.
Le shell ne prend pas la locale en compte. Avec des locales ISO-8859-1:
Dans l'article <873b6r9kdk.fsf@nez-casse.depot.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
bgrandin@bdzone.com (Benoît Grandin) écrivait :
Eric Levenez <news@levenez.com> wrote:
Si tu parles de Mac OS X, alors pour écrire un fichier en
utilisant un appel système du noyau (open avec O_CREAT), il faut
que le nom soit de l'UTF-8 valide. Tout caractère binaire, type
ISO-8859-1, entraînera une erreur.
Même dans un shell, en utilisant des guillemets ?
Le shell va interpréter selon la locale qu'il aura. Mais il est plus
simple d'avoir son mac tout en utf-8 avec un shell qui le supporte,
comme un zsh récent.
Le shell ne prend pas la locale en compte. Avec des locales ISO-8859-1:
Si tu parles de Mac OS X, alors pour écrire un fichier en utilisant un appel système du noyau (open avec O_CREAT), il faut que le nom soit de l'UTF-8 valide. Tout caractère binaire, type ISO-8859-1, entraînera une erreur.
Même dans un shell, en utilisant des guillemets ?
Le shell va interpréter selon la locale qu'il aura. Mais il est plus simple d'avoir son mac tout en utf-8 avec un shell qui le supporte, comme un zsh récent.
Le shell ne prend pas la locale en compte. Avec des locales ISO-8859-1:
Le mkdir fonctionne car tu es en UTF-8. Ton LC_CTYPE=fr_FR.UTF-8, c'est bien une locale de définie. La méthode standard (POSIX) pour avoir l'encodage courant est "locale charmap", mais Mac OS X et POSIX, ça fait deux:
et aussi : $ ls "éè" donne rien tout comme : $ ls 'éè'
C'est normal, car le répertoire éè ne contient rien. Concernant l'erreur du "ls éè", c'est probablement que ton shell n'est pas compatible UTF-8 et fait quelque chose de bizarre avec les octets avec le 8e bit à 1.
ça doit-être lié au C-standard cette behaviour non ?
Non, le C laisse beaucoup de choses à l'implémentation concernant les noms de fichiers et les locales. À quand une fonction wcsfopen prenant un wchar_t * au lieu d'un char * pour le chemin?
Le mkdir fonctionne car tu es en UTF-8. Ton LC_CTYPE=fr_FR.UTF-8,
c'est bien une locale de définie. La méthode standard (POSIX) pour
avoir l'encodage courant est "locale charmap", mais Mac OS X et
POSIX, ça fait deux:
et aussi :
$ ls "éè"
donne rien tout comme :
$ ls 'éè'
C'est normal, car le répertoire éè ne contient rien. Concernant
l'erreur du "ls éè", c'est probablement que ton shell n'est pas
compatible UTF-8 et fait quelque chose de bizarre avec les octets
avec le 8e bit à 1.
ça doit-être lié au C-standard cette behaviour non ?
Non, le C laisse beaucoup de choses à l'implémentation concernant
les noms de fichiers et les locales. À quand une fonction wcsfopen
prenant un wchar_t * au lieu d'un char * pour le chemin?
Le mkdir fonctionne car tu es en UTF-8. Ton LC_CTYPE=fr_FR.UTF-8, c'est bien une locale de définie. La méthode standard (POSIX) pour avoir l'encodage courant est "locale charmap", mais Mac OS X et POSIX, ça fait deux:
et aussi : $ ls "éè" donne rien tout comme : $ ls 'éè'
C'est normal, car le répertoire éè ne contient rien. Concernant l'erreur du "ls éè", c'est probablement que ton shell n'est pas compatible UTF-8 et fait quelque chose de bizarre avec les octets avec le 8e bit à 1.
ça doit-être lié au C-standard cette behaviour non ?
Non, le C laisse beaucoup de choses à l'implémentation concernant les noms de fichiers et les locales. À quand une fonction wcsfopen prenant un wchar_t * au lieu d'un char * pour le chemin?
Moi, je propose caractère de bravitude, et bravituder un caractère. Ça le fait pas ?
:-))
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
blanc
Paul Gaborit wrote:
Attention, il ne faut pas confondre le nom du caractère lui-même et son rôle. Il se trouve que parfois le caractère barre oblique inversée (le backslash) est le caractère d'échappement. Mais ce n'est pas toujours ce caractère qui est choisi.
N'est-ce pas ce que je dis ?
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Jamais ? Désolé mais dans tous les shells, les guillemets et les apostrophes ont un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord). Extrait du man de sh :
A non-quoted backslash () is the escape character. It preserves the literal value of the next character that follows, with the exception of <newline>. If a <newline> pair appears, and the backslash is not itself quoted, the <newline> is treated as a line continuation (that is, it is removed from the input stream and effectively ignored).
Enclosing characters in single quotes preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash.
Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, and . The characters $ and ` retain their special meaning within double quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", , or <newline>. A double quote may be quoted within double quotes by preceding it with a back- slash.
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser le n qui suit mais bien au contraire de lui donner un autre sens que le sens habituel dans le contexte d'une chaîne entre guillemets.
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui se passe dans un shell. Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se termine par .c dans le répertoire courant, et le shell enverra cette liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas interprété par le shell. C'est àmha exactement une banalisation.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Attention, il ne faut pas confondre le nom du caractère lui-même et
son rôle. Il se trouve que parfois le caractère barre oblique inversée
(le backslash) est le caractère d'échappement. Mais ce n'est pas
toujours ce caractère qui est choisi.
N'est-ce pas ce que je dis ?
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des
caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une
manière de spécifier une chaîne de caractères avec ou sans
interpolation (comme en dit Perl).
Jamais ?
Désolé mais dans tous les shells, les guillemets et les apostrophes ont
un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord).
Extrait du man de sh :
A non-quoted backslash () is the escape character. It preserves
the literal value of the next character that follows, with the
exception of <newline>. If a <newline> pair appears, and the
backslash is not itself quoted, the <newline> is treated as a line
continuation (that is, it is removed from the input stream and
effectively ignored).
Enclosing characters in single quotes preserves the literal
value of each character within the quotes. A single quote may not
occur between single quotes, even when preceded by a backslash.
Enclosing characters in double quotes preserves the literal
value of all characters within the quotes, with the exception of $,
`, and . The characters $ and ` retain their special
meaning within double quotes. The backslash retains its special
meaning only when followed by one of the following characters: $,
`, ", , or <newline>. A double quote may be quoted within double
quotes by preceding it with a back- slash.
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit
également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque
j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser
le n qui suit mais bien au contraire de lui donner un autre sens que
le sens habituel dans le contexte d'une chaîne entre guillemets.
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui
se passe dans un shell. Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se
termine par .c dans le répertoire courant, et le shell enverra cette
liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe
quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas
interprété par le shell.
C'est àmha exactement une banalisation.
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Attention, il ne faut pas confondre le nom du caractère lui-même et son rôle. Il se trouve que parfois le caractère barre oblique inversée (le backslash) est le caractère d'échappement. Mais ce n'est pas toujours ce caractère qui est choisi.
N'est-ce pas ce que je dis ?
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Jamais ? Désolé mais dans tous les shells, les guillemets et les apostrophes ont un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord). Extrait du man de sh :
A non-quoted backslash () is the escape character. It preserves the literal value of the next character that follows, with the exception of <newline>. If a <newline> pair appears, and the backslash is not itself quoted, the <newline> is treated as a line continuation (that is, it is removed from the input stream and effectively ignored).
Enclosing characters in single quotes preserves the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash.
Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, and . The characters $ and ` retain their special meaning within double quotes. The backslash retains its special meaning only when followed by one of the following characters: $, `, ", , or <newline>. A double quote may be quoted within double quotes by preceding it with a back- slash.
Ou bien "neutraliser un caractère", ou encore (comme cela a déjà été dit également) "banaliser un caractère".
La notion de banalisation est ici un contre-sens. En C, lorsque j'écris "n", la barre oblique inversée n'a pas pour rôle de banaliser le n qui suit mais bien au contraire de lui donner un autre sens que le sens habituel dans le contexte d'une chaîne entre guillemets.
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui se passe dans un shell. Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se termine par .c dans le répertoire courant, et le shell enverra cette liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas interprété par le shell. C'est àmha exactement une banalisation.
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Paul Gaborit
À (at) Thu, 11 Jan 2007 22:04:57 +0100, (JPaul) écrivait (wrote):
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Jamais ? Désolé mais dans tous les shells, les guillemets et les apostrophes ont un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord).
Mais ce ne sont pas des caractères d'échappement... Ne serait-ce que parce que leur influence à une portée longue (jusqu'à la rencontre de l'apostrophe ou du guillemet fermant correspondant). En fait ce sont, le plus souvent, des caractères de changement de contexte lexicographique (comme les parenthèses ou les crochets).
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui se passe dans un shell.
Je ne parle pas que du C... je donne un exemple en C. Mais on pourrait prendre des exemples comme cela dans tous les langages : C, Perl, Pyton, Jav, Javascript, sh, csh, etc.
D'ailleurs on peut prendre le même exemple en shell (ici un tcsh) :
set prompt="%S%n-%m%s[%C02]n"
Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se termine par .c dans le répertoire courant, et le shell enverra cette liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas interprété par le shell. C'est àmha exactement une banalisation.
Certes. Il se trouve qu'ici la caractère d'échappement a pour influence de "neutraliser" la comportement du "joker" '*' ou du caractère de redirection '>'. Mais c'est un cas particulier spécifique au shell qui de plus n'entre pas en contradiction avec la notion de caractère d'échappement. Mais, et c'est pour cela que je donnais un exemple en C, la notion de caractère d'échappement est plus générale et, souvent, n'a pas pour rôle de "neutraliser" le caractère qui suit mais plutôt d'échapper à son rôle habituel.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 11 Jan 2007 22:04:57 +0100,
blanc@empty.org (JPaul) écrivait (wrote):
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des
caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une
manière de spécifier une chaîne de caractères avec ou sans
interpolation (comme en dit Perl).
Jamais ?
Désolé mais dans tous les shells, les guillemets et les apostrophes ont
un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord).
Mais ce ne sont pas des caractères d'échappement... Ne serait-ce que
parce que leur influence à une portée longue (jusqu'à la rencontre de
l'apostrophe ou du guillemet fermant correspondant). En fait ce sont,
le plus souvent, des caractères de changement de contexte
lexicographique (comme les parenthèses ou les crochets).
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui
se passe dans un shell.
Je ne parle pas que du C... je donne un exemple en C. Mais on pourrait
prendre des exemples comme cela dans tous les langages : C, Perl,
Pyton, Jav, Javascript, sh, csh, etc.
D'ailleurs on peut prendre le même exemple en shell (ici un tcsh) :
set prompt="%S%n-%m%s[%C02]n"
Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se
termine par .c dans le répertoire courant, et le shell enverra cette
liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe
quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas
interprété par le shell.
C'est àmha exactement une banalisation.
Certes. Il se trouve qu'ici la caractère d'échappement a pour
influence de "neutraliser" la comportement du "joker" '*' ou du
caractère de redirection '>'. Mais c'est un cas particulier spécifique
au shell qui de plus n'entre pas en contradiction avec la notion de
caractère d'échappement. Mais, et c'est pour cela que je donnais un
exemple en C, la notion de caractère d'échappement est plus générale
et, souvent, n'a pas pour rôle de "neutraliser" le caractère qui suit
mais plutôt d'échapper à son rôle habituel.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 11 Jan 2007 22:04:57 +0100, (JPaul) écrivait (wrote):
Quant aux guillemets ou à l'apostrophe, ce ne sont jamais des caractères d'échappement (sauf l'apostrophe en LISP). C'est juste une manière de spécifier une chaîne de caractères avec ou sans interpolation (comme en dit Perl).
Jamais ? Désolé mais dans tous les shells, les guillemets et les apostrophes ont un rôle de neutralisation (ce n'est pas le cas en C je suis d'accord).
Mais ce ne sont pas des caractères d'échappement... Ne serait-ce que parce que leur influence à une portée longue (jusqu'à la rencontre de l'apostrophe ou du guillemet fermant correspondant). En fait ce sont, le plus souvent, des caractères de changement de contexte lexicographique (comme les parenthèses ou les crochets).
La encore, tu ne parles que de C, alors que je pensais plutôt à ce qui se passe dans un shell.
Je ne parle pas que du C... je donne un exemple en C. Mais on pourrait prendre des exemples comme cela dans tous les langages : C, Perl, Pyton, Jav, Javascript, sh, csh, etc.
D'ailleurs on peut prendre le même exemple en shell (ici un tcsh) :
set prompt="%S%n-%m%s[%C02]n"
Si par exemple tu tapes la commande :
ls *.c>truc
la commande ls cherchera à lister tous les fichiers dont le nom se termine par .c dans le répertoire courant, et le shell enverra cette liste dans le répertoire truc, tandis que la commande :
ls *.c>truc
cherchera à lister un fichier ou répertoire dont le nom est exactement
*.c>truc
Et de la même façon, l'antislash neutralisera ou banalisera n'importe quel caractère (y compris lui-même) de telle sorte qu'il ne sera pas interprété par le shell. C'est àmha exactement une banalisation.
Certes. Il se trouve qu'ici la caractère d'échappement a pour influence de "neutraliser" la comportement du "joker" '*' ou du caractère de redirection '>'. Mais c'est un cas particulier spécifique au shell qui de plus n'entre pas en contradiction avec la notion de caractère d'échappement. Mais, et c'est pour cela que je donnais un exemple en C, la notion de caractère d'échappement est plus générale et, souvent, n'a pas pour rôle de "neutraliser" le caractère qui suit mais plutôt d'échapper à son rôle habituel.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
