DvC wrote:
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers.
Oulalalalala, c'est à la fois simple et compliqué.
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
$ ls -l
total 0
-rw-r--r-- 1 laurent staff 0 Nov 4 02:29 texte du 4:11:2008.txt
Enfer et damnation les jolis "/" sont devenus des ":", alors que le
Finder n'arrête pas de dire que ben non, il ne faut pas utiliser ce
caractère.
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
Bref, moi, je connais, donc je sais gérer, si on ne fait pas de ligne de
commande, pas de soucis majeurs à prévoir (enfin, sauf à utiliser des
trucs non maîtrisés soit-disant là pour aider l'utilisateur ne
connaissant pas, hein) et si on passe côté ligne de commande, bah, il
faut étudier un peu quoi.
> De toute évidence ceci ne s'est pas avéré, mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
Ah ben ça, va falloir faire un feature request pour la prochaine version
en pleine réécriture si on en croit les rumeurs :-D
DvC <nospam@odyssee.net> wrote:
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers.
Oulalalalala, c'est à la fois simple et compliqué.
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
$ ls -l
total 0
-rw-r--r-- 1 laurent staff 0 Nov 4 02:29 texte du 4:11:2008.txt
Enfer et damnation les jolis "/" sont devenus des ":", alors que le
Finder n'arrête pas de dire que ben non, il ne faut pas utiliser ce
caractère.
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
Bref, moi, je connais, donc je sais gérer, si on ne fait pas de ligne de
commande, pas de soucis majeurs à prévoir (enfin, sauf à utiliser des
trucs non maîtrisés soit-disant là pour aider l'utilisateur ne
connaissant pas, hein) et si on passe côté ligne de commande, bah, il
faut étudier un peu quoi.
> De toute évidence ceci ne s'est pas avéré, mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
Ah ben ça, va falloir faire un feature request pour la prochaine version
en pleine réécriture si on en croit les rumeurs :-D
DvC wrote:
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers.
Oulalalalala, c'est à la fois simple et compliqué.
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
$ ls -l
total 0
-rw-r--r-- 1 laurent staff 0 Nov 4 02:29 texte du 4:11:2008.txt
Enfer et damnation les jolis "/" sont devenus des ":", alors que le
Finder n'arrête pas de dire que ben non, il ne faut pas utiliser ce
caractère.
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
Bref, moi, je connais, donc je sais gérer, si on ne fait pas de ligne de
commande, pas de soucis majeurs à prévoir (enfin, sauf à utiliser des
trucs non maîtrisés soit-disant là pour aider l'utilisateur ne
connaissant pas, hein) et si on passe côté ligne de commande, bah, il
faut étudier un peu quoi.
> De toute évidence ceci ne s'est pas avéré, mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
Ah ben ça, va falloir faire un feature request pour la prochaine version
en pleine réécriture si on en croit les rumeurs :-D
> Ah ben ça, va falloir faire un feature request pour la prochaine version
> en pleine réécriture si on en croit les rumeurs :-D
Oui, bizarre que ça n'ait pas été fait avant.
Mais merci pour ta
fascinante explication.
> Ah ben ça, va falloir faire un feature request pour la prochaine version
> en pleine réécriture si on en croit les rumeurs :-D
Oui, bizarre que ça n'ait pas été fait avant.
Mais merci pour ta
fascinante explication.
> Ah ben ça, va falloir faire un feature request pour la prochaine version
> en pleine réécriture si on en croit les rumeurs :-D
Oui, bizarre que ça n'ait pas été fait avant.
Mais merci pour ta
fascinante explication.
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
[..]
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers. De toute évidence ceci ne s'est pas avéré,
> mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
[..]
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers. De toute évidence ceci ne s'est pas avéré,
> mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
Donc, en gros, quand tu es dans l'interface graphique, le caractère
interdit reste le ":" mais si tu passes en ligne de commande, il est
autorisé alors que le "/" lui pose soucis (et pour cause) alors qu'il
passe très bien en GUI.
Là où ça devient plus fun c'est quand tu compares les deux visions.
Supposons un fichier appelé "texte du 4/11/2008.txt" que tu as créé dans
une appli graphique et que tu vois ainsi nommé dans le Finder. On
remarquera les "/" qui ont toujours été autorisés depuis la nuit des
temps sur Mac OS. Eh bien, ils sont là. Et là, normalement, l'unixien
s'interroge. Et il a raison.
Donc il va voir en ligne de commande ce que ça donne et, ô surprise, il
constate l'étendue des dégâts (ou de la finesse, au choix) :
[..]
Et là où ça devient tordant c'est que si en ligne de commande tu essaies
de créer un élément avec un "/" dans le nom, il n'aime pas, mais si tu
mets des ":", il le prend très bien. Et de retour dans le Finder, les
":" sont devenus des "/" :-)
Bref, si on scripte côté unix, il faut plutôt se méfier (à moins qu'il
n'y ait une astuce, cela dit) mais c'est pareil côté graphique, hein,
méfiance.
> 2) À l'époque de la venue de Mac OS X, il était fortement question (si
> mes souvenirs sont bons) que l'oblique (/) devienne le nouveau deux
> points (:) comme signe de ponctuation interdit dans le noms de fichiers
> et de dossiers. De toute évidence ceci ne s'est pas avéré,
> mais y a-t-il
> une raison pour laquelle ce gros système aux possibilités infinies ne
> soit pas capable de les remplacer automatiquement par un tiret comme
> l'humble 9 le faisait ?
DvC wrote:
> > Ah ben ça, va falloir faire un feature request pour la prochaine version
> > en pleine réécriture si on en croit les rumeurs :-D
>
> Oui, bizarre que ça n'ait pas été fait avant.
Bah, il n'est jamais trop tard pour bien faire et plus il y aura de
demandes, plus on a de chances que ce soit pris en compte.
DvC <nospam@odyssee.net> wrote:
> > Ah ben ça, va falloir faire un feature request pour la prochaine version
> > en pleine réécriture si on en croit les rumeurs :-D
>
> Oui, bizarre que ça n'ait pas été fait avant.
Bah, il n'est jamais trop tard pour bien faire et plus il y aura de
demandes, plus on a de chances que ce soit pris en compte.
DvC wrote:
> > Ah ben ça, va falloir faire un feature request pour la prochaine version
> > en pleine réécriture si on en croit les rumeurs :-D
>
> Oui, bizarre que ça n'ait pas été fait avant.
Bah, il n'est jamais trop tard pour bien faire et plus il y aura de
demandes, plus on a de chances que ce soit pris en compte.
Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
de la difficulté à comprendre qu'ils chipottent sur ces détails après
avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
jusqu'en 3D !
Mais je revenais là-dessus surtout pour savoir comment ça
se faisait un "Feature request" ?
Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
de la difficulté à comprendre qu'ils chipottent sur ces détails après
avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
jusqu'en 3D !
Mais je revenais là-dessus surtout pour savoir comment ça
se faisait un "Feature request" ?
Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
de la difficulté à comprendre qu'ils chipottent sur ces détails après
avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
jusqu'en 3D !
Mais je revenais là-dessus surtout pour savoir comment ça
se faisait un "Feature request" ?
Ben... c'est pourtant simple : le "/" sous Unix est le séparateur entre
répertoire (dossiers) dans un chemin. C'est-à- dire que par exemple le
chemin suivant :
/Users/machin/Mes_Documents/monfichier.txt
signifie : le fichier "monfichier.txt" dans le dossier "Mes_Documents"
qui lui-même est dans le dossier "machin", lui-même dans le dossier
"Users" dans la racine du disque.
Donc pour cette raison le caract "/" est interdit dans un nom de fichier
ou de dossier.
Historiquement dans Mac OS (Classic) c'était le caractère ":" qui jouait
ce rôle de séparateur de dossiers dans un chemin. Donc c'était lui qui
était interdit.
Lorsque Mac OS X a été créé, Apple n'a pas voulu dérouter les macounets
et surtout il a voulu permettre que les anciens fichiers dont le nom
contenait des "/" soient accessibles. Il y avait aussi les Applescripts
qui contenaient des chemins avec ":" comme séparateurs.
Mais comme la base est Unix, il a donc créé un mécanisme dans le Finder
(et dans Applescript et peut-être dans quelques autres logiciels),
mécanisme qui échange les deux caractères "/" et ":" aussi bien à
l'affichage que dans l'autre sens (lors d'une modif d'un nom ou d'un
chemin). A partir du moment où on est conscient de ce fait, il me semble
que tout est simple.
Ben... c'est pourtant simple : le "/" sous Unix est le séparateur entre
répertoire (dossiers) dans un chemin. C'est-à- dire que par exemple le
chemin suivant :
/Users/machin/Mes_Documents/monfichier.txt
signifie : le fichier "monfichier.txt" dans le dossier "Mes_Documents"
qui lui-même est dans le dossier "machin", lui-même dans le dossier
"Users" dans la racine du disque.
Donc pour cette raison le caract "/" est interdit dans un nom de fichier
ou de dossier.
Historiquement dans Mac OS (Classic) c'était le caractère ":" qui jouait
ce rôle de séparateur de dossiers dans un chemin. Donc c'était lui qui
était interdit.
Lorsque Mac OS X a été créé, Apple n'a pas voulu dérouter les macounets
et surtout il a voulu permettre que les anciens fichiers dont le nom
contenait des "/" soient accessibles. Il y avait aussi les Applescripts
qui contenaient des chemins avec ":" comme séparateurs.
Mais comme la base est Unix, il a donc créé un mécanisme dans le Finder
(et dans Applescript et peut-être dans quelques autres logiciels),
mécanisme qui échange les deux caractères "/" et ":" aussi bien à
l'affichage que dans l'autre sens (lors d'une modif d'un nom ou d'un
chemin). A partir du moment où on est conscient de ce fait, il me semble
que tout est simple.
Ben... c'est pourtant simple : le "/" sous Unix est le séparateur entre
répertoire (dossiers) dans un chemin. C'est-à- dire que par exemple le
chemin suivant :
/Users/machin/Mes_Documents/monfichier.txt
signifie : le fichier "monfichier.txt" dans le dossier "Mes_Documents"
qui lui-même est dans le dossier "machin", lui-même dans le dossier
"Users" dans la racine du disque.
Donc pour cette raison le caract "/" est interdit dans un nom de fichier
ou de dossier.
Historiquement dans Mac OS (Classic) c'était le caractère ":" qui jouait
ce rôle de séparateur de dossiers dans un chemin. Donc c'était lui qui
était interdit.
Lorsque Mac OS X a été créé, Apple n'a pas voulu dérouter les macounets
et surtout il a voulu permettre que les anciens fichiers dont le nom
contenait des "/" soient accessibles. Il y avait aussi les Applescripts
qui contenaient des chemins avec ":" comme séparateurs.
Mais comme la base est Unix, il a donc créé un mécanisme dans le Finder
(et dans Applescript et peut-être dans quelques autres logiciels),
mécanisme qui échange les deux caractères "/" et ":" aussi bien à
l'affichage que dans l'autre sens (lors d'une modif d'un nom ou d'un
chemin). A partir du moment où on est conscient de ce fait, il me semble
que tout est simple.
DvC wrote:
> Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> de la difficulté à comprendre qu'ils chipottent sur ces détails après
> avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> jusqu'en 3D !
Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
mets différents enrichissements (gras...), j'en fais un extrait texte,
je ferme le document, j'en crée un autre, je glisse mon extrait texte,
il a gardé les styles.
DvC <nospam@odyssee.net> wrote:
> Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> de la difficulté à comprendre qu'ils chipottent sur ces détails après
> avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> jusqu'en 3D !
Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
mets différents enrichissements (gras...), j'en fais un extrait texte,
je ferme le document, j'en crée un autre, je glisse mon extrait texte,
il a gardé les styles.
DvC wrote:
> Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> de la difficulté à comprendre qu'ils chipottent sur ces détails après
> avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> jusqu'en 3D !
Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
mets différents enrichissements (gras...), j'en fais un extrait texte,
je ferme le document, j'en crée un autre, je glisse mon extrait texte,
il a gardé les styles.
In article <1iq1nsk.1f7qninrrsvcwN%,
(Laurent Pertois) wrote:
> DvC wrote:
>
> > Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> > reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> > de la difficulté à comprendre qu'ils chipottent sur ces détails après
> > avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> > jusqu'en 3D !
>
> Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
> mets différents enrichissements (gras...), j'en fais un extrait texte,
> je ferme le document, j'en crée un autre, je glisse mon extrait texte,
> il a gardé les styles.
Oui, c'est juste le Finder qui ignore les styles quand il affiche
l'extrait.
Patrick
In article <1iq1nsk.1f7qninrrsvcwN%laurent.pertois@alussinan.org>,
laurent.pertois@alussinan.org (Laurent Pertois) wrote:
> DvC <nospam@odyssee.net> wrote:
>
> > Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> > reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> > de la difficulté à comprendre qu'ils chipottent sur ces détails après
> > avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> > jusqu'en 3D !
>
> Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
> mets différents enrichissements (gras...), j'en fais un extrait texte,
> je ferme le document, j'en crée un autre, je glisse mon extrait texte,
> il a gardé les styles.
Oui, c'est juste le Finder qui ignore les styles quand il affiche
l'extrait.
Patrick
In article <1iq1nsk.1f7qninrrsvcwN%,
(Laurent Pertois) wrote:
> DvC wrote:
>
> > Et un coup sur place, on pourrait aussi leur suggérer qu'ils nous
> > reconcoctent des "extraits de texte" qui sauvegardent les styles. J'ai
> > de la difficulté à comprendre qu'ils chipottent sur ces détails après
> > avoir créé un successeur à SimpleText (TextEdit) qui se permet d'écrire
> > jusqu'en 3D !
>
> Mmmm, ben, je viens de regarder et je prends un texte dans TextEdit, je
> mets différents enrichissements (gras...), j'en fais un extrait texte,
> je ferme le document, j'en crée un autre, je glisse mon extrait texte,
> il a gardé les styles.
Oui, c'est juste le Finder qui ignore les styles quand il affiche
l'extrait.
Patrick
Un serveur intermédiaire qui aurait eu des vapeurs ?
Un serveur intermédiaire qui aurait eu des vapeurs ?
Un serveur intermédiaire qui aurait eu des vapeurs ?
SbM wrote:
> Un serveur intermédiaire qui aurait eu des vapeurs ?
Nan. C'est en répondant à un message en UTF-8 que NW bascule dans ce
mode.
SbM <sebastienmarty@yahoo.fr> wrote:
> Un serveur intermédiaire qui aurait eu des vapeurs ?
Nan. C'est en répondant à un message en UTF-8 que NW bascule dans ce
mode.
SbM wrote:
> Un serveur intermédiaire qui aurait eu des vapeurs ?
Nan. C'est en répondant à un message en UTF-8 que NW bascule dans ce
mode.