Peut-on ou pas utiliser des caractères non ascii dans la valeur de
l'attribut href en html ? Tidy semble les considérer comme légaux mais
seulement s'il sont « échappés » (par exemple %C3%A9 pour un « é » dans un
document encodé en utf-8). La seule référence que je trouve à ce sujet (RFC
1738) dit que le non-ascii n'est pas autorisé, mais cette RFC date de 94.
Enfin, wikipedia a souvent plein de caractères accentués dans les noms de
pages, pour l'instant je ne leur ai jamais accordé de traitement
particulier dans mes pages, et sans rencontrer de problème mais ça ne
prouve rien.
Alors, quelles sont les bonnes pratiques et les standards en la matière ?
À (at) Mon, 13 Oct 2008 16:49:35 +0200, Olivier Miakinen <om+ écrivait (wrote):
Le 13/10/2008 13:14, Pierre Goiffon a écrit :
Le passage de caractères hors us-ascii est à priori assez problématique : rien n'indique en effet dans l'échange entre client et serveur sur quel codage est basé l'échappement ! On a donc tendance à préférer le post, ou au moins à forcer UTF-8...
Voir ce document de référence sur le sujet : <http://web.archive.org/web/20060427015200/ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html>
C'est vrai, mais ceci ne concerne que les paramètres qui pourraient être éventuellement passés dans un formulaire plutôt que dans l'URL. Utiliser un POST ne résoudra rien dans le cas où la page appelée se nomme http:///www.example.com/écrire.php
En revanche, vu que cette partie est statique, il n'y a aucun problème à référencer <a href="http:///www.example.com/%C3%A9crire.php">.
Certainement mais rien dans la RFC sur les URI ne permet de dire si l'URL cité ci-dessus référence un fichier nommé Écrire.php !
Pour bien comprendre les différents niveaux d'interprétation, il faut lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez parlants.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 16:49:35 +0200,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):
Le 13/10/2008 13:14, Pierre Goiffon a écrit :
Le passage de caractères hors us-ascii est à priori assez problématique :
rien n'indique en effet dans l'échange entre client et serveur sur
quel codage est basé l'échappement ! On a donc tendance à préférer le
post, ou au moins à forcer UTF-8...
Voir ce document de référence sur le sujet :
<http://web.archive.org/web/20060427015200/ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html>
C'est vrai, mais ceci ne concerne que les paramètres qui pourraient être
éventuellement passés dans un formulaire plutôt que dans l'URL. Utiliser
un POST ne résoudra rien dans le cas où la page appelée se nomme
http:///www.example.com/écrire.php
En revanche, vu que cette partie est statique, il n'y a aucun problème à
référencer <a href="http:///www.example.com/%C3%A9crire.php">.
Certainement mais rien dans la RFC sur les URI ne permet de dire si
l'URL cité ci-dessus référence un fichier nommé Écrire.php !
Pour bien comprendre les différents niveaux d'interprétation, il faut
lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez
parlants.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 16:49:35 +0200, Olivier Miakinen <om+ écrivait (wrote):
Le 13/10/2008 13:14, Pierre Goiffon a écrit :
Le passage de caractères hors us-ascii est à priori assez problématique : rien n'indique en effet dans l'échange entre client et serveur sur quel codage est basé l'échappement ! On a donc tendance à préférer le post, ou au moins à forcer UTF-8...
Voir ce document de référence sur le sujet : <http://web.archive.org/web/20060427015200/ppewww.ph.gla.ac.uk/~flavell/charset/form-i18n.html>
C'est vrai, mais ceci ne concerne que les paramètres qui pourraient être éventuellement passés dans un formulaire plutôt que dans l'URL. Utiliser un POST ne résoudra rien dans le cas où la page appelée se nomme http:///www.example.com/écrire.php
En revanche, vu que cette partie est statique, il n'y a aucun problème à référencer <a href="http:///www.example.com/%C3%A9crire.php">.
Certainement mais rien dans la RFC sur les URI ne permet de dire si l'URL cité ci-dessus référence un fichier nommé Écrire.php !
Pour bien comprendre les différents niveaux d'interprétation, il faut lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez parlants.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Mon, 13 Oct 2008 17:08:40 +0200, Paul Gaborit écrivait (wrote): [...]
l'URL cité ci-dessus référence un fichier nommé Écrire.php !
[...]
Problément d'encodage ! Je voulais écrire "écrire.php" ! ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 17:08:40 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
[...]
l'URL cité ci-dessus référence un fichier nommé Écrire.php !
[...]
Problément d'encodage ! Je voulais écrire "écrire.php" ! ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
Pour bien comprendre les différents niveaux d'interprétation, il faut lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez parlants.
Oui.
Je vais aller les lire alors.
Merci à tous pour vos réponses, Manuel.
Le (on) lundi 13 octobre 2008 17:20, Olivier Miakinen a écrit (wrote) :
Le 13/10/2008 17:08, Paul Gaborit a écrit :
En revanche, vu que cette partie est statique, il n'y a aucun problème à
référencer <a href="http:///www.example.com/%C3%A9crire.php">.
Certainement mais rien dans la RFC sur les URI ne permet de dire si
l'URL cité ci-dessus référence un fichier nommé Écrire.php !
C'est absolument exact. Mais d'un autre côté on s'en fiche complètement,
non ?
Euh, justement, je ne comprends pas pourquoi, et l'argument ci-dessus me
fait justement penser que non, on ne s'en fiche pas.
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à
arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un
vrai fichier à l'URI demandé par le client ?
Pour bien comprendre les différents niveaux d'interprétation, il faut
lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez
parlants.
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
Pour bien comprendre les différents niveaux d'interprétation, il faut lire la section 2.5 de la RFC 3986. Les exemples donnés sont assez parlants.
Oui.
Je vais aller les lire alors.
Merci à tous pour vos réponses, Manuel.
Paul Gaborit
À (at) Tue, 14 Oct 2008 00:59:34 +0200, mpg écrivait (wrote):
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
En fait, c'est au serveur de se débrouiller avec la suite d'octets qu'il récupère. Libre à lui de l'interpréter comme il le souhaite. D'ailleurs, rien ne dit qu'il y a un fichier au bout... ;-)
En fait, on est un peu dans la situation inverse des systèmes de fichiers. De nombreux systèmes de fichiers ne considèrent pas l'encodage des noms de fichiers : ils interdisent juste quelques caractères (par exemple / et NUL) et le reste, ils ne s'en préoccupent pas (si ce n'est peut-être la longueur totale). Après, les couches au-dessus décident si telle ou telle suite d'octets doit apparaître comme un caractère accentué, un idéogramme ou juste de l'ascii...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 14 Oct 2008 00:59:34 +0200,
mpg <mpg@elzevir.fr> écrivait (wrote):
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à
arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un
vrai fichier à l'URI demandé par le client ?
En fait, c'est au serveur de se débrouiller avec la suite d'octets
qu'il récupère. Libre à lui de l'interpréter comme il le
souhaite. D'ailleurs, rien ne dit qu'il y a un fichier au bout... ;-)
En fait, on est un peu dans la situation inverse des systèmes de
fichiers. De nombreux systèmes de fichiers ne considèrent pas
l'encodage des noms de fichiers : ils interdisent juste quelques
caractères (par exemple / et NUL) et le reste, ils ne s'en préoccupent
pas (si ce n'est peut-être la longueur totale). Après, les couches
au-dessus décident si telle ou telle suite d'octets doit apparaître
comme un caractère accentué, un idéogramme ou juste de l'ascii...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 14 Oct 2008 00:59:34 +0200, mpg écrivait (wrote):
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
En fait, c'est au serveur de se débrouiller avec la suite d'octets qu'il récupère. Libre à lui de l'interpréter comme il le souhaite. D'ailleurs, rien ne dit qu'il y a un fichier au bout... ;-)
En fait, on est un peu dans la situation inverse des systèmes de fichiers. De nombreux systèmes de fichiers ne considèrent pas l'encodage des noms de fichiers : ils interdisent juste quelques caractères (par exemple / et NUL) et le reste, ils ne s'en préoccupent pas (si ce n'est peut-être la longueur totale). Après, les couches au-dessus décident si telle ou telle suite d'octets doit apparaître comme un caractère accentué, un idéogramme ou juste de l'ascii...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Olivier Miakinen
Le 14/10/2008 00:59, mpg a écrit :
Euh, justement, je ne comprends pas pourquoi, et l'argument ci-dessus me fait justement penser que non, on ne s'en fiche pas.
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
C'est parce qu'on prend la question du mauvais côté. C'est du côté serveur que l'on définit la forme des URL, que ce soient celles écrites dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères par défaut de la machine, c'est le webmestre qui décide s'il veut que l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire %82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple est de l'EBCDIC).
Bien sûr, choisir autre chose que la conversion en UTF-8 empêche de taper directement la chaîne avec accents dans l'URL et de voir son navigateur favori la traduire tout seul comme un grand, mais ça c'est vraiment au choix du webmestre.
Le 14/10/2008 00:59, mpg a écrit :
Euh, justement, je ne comprends pas pourquoi, et l'argument ci-dessus me
fait justement penser que non, on ne s'en fiche pas.
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à
arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un
vrai fichier à l'URI demandé par le client ?
C'est parce qu'on prend la question du mauvais côté. C'est du côté
serveur que l'on définit la forme des URL, que ce soient celles écrites
dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères
par défaut de la machine, c'est le webmestre qui décide s'il veut que
l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire
%82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple
est de l'EBCDIC).
Bien sûr, choisir autre chose que la conversion en UTF-8 empêche de
taper directement la chaîne avec accents dans l'URL et de voir son
navigateur favori la traduire tout seul comme un grand, mais ça c'est
vraiment au choix du webmestre.
Ou alors on s'en fiche juste quand on écrit le lien, mais on commence à arrêter de s'en ficher quand on est côté serveur et qu'il faut associer un vrai fichier à l'URI demandé par le client ?
C'est parce qu'on prend la question du mauvais côté. C'est du côté serveur que l'on définit la forme des URL, que ce soient celles écrites dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères par défaut de la machine, c'est le webmestre qui décide s'il veut que l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire %82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple est de l'EBCDIC).
Bien sûr, choisir autre chose que la conversion en UTF-8 empêche de taper directement la chaîne avec accents dans l'URL et de voir son navigateur favori la traduire tout seul comme un grand, mais ça c'est vraiment au choix du webmestre.
Pierre Goiffon
Olivier Miakinen wrote:
C'est du côté serveur que l'on définit la forme des URL, que ce soient celles écrites dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères par défaut de la machine, c'est le webmestre qui décide s'il veut que l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire %82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple est de l'EBCDIC).
Certes...
Au passage, j'imagine le cas de migration d'un serveur qui hébergeait des url contenant des caractères échappés, mettons en windows-1252. Et on passe sur un système où le codage par défaut est UTF-8. Existe-t-il des quelconques techniques permettant de forcer sur le serveur l'échappement des url avec un codage déterminé qui serait différent de la plateforme ? Sur tomcat on a un UriEncoding qui je crois fait un peu ça ?
Olivier Miakinen wrote:
C'est du côté
serveur que l'on définit la forme des URL, que ce soient celles écrites
dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères
par défaut de la machine, c'est le webmestre qui décide s'il veut que
l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire
%82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple
est de l'EBCDIC).
Certes...
Au passage, j'imagine le cas de migration d'un serveur qui hébergeait
des url contenant des caractères échappés, mettons en windows-1252. Et
on passe sur un système où le codage par défaut est UTF-8. Existe-t-il
des quelconques techniques permettant de forcer sur le serveur
l'échappement des url avec un codage déterminé qui serait différent de
la plateforme ? Sur tomcat on a un UriEncoding qui je crois fait un peu ça ?
C'est du côté serveur que l'on définit la forme des URL, que ce soient celles écrites dans les liens <a href...> ou bien celles attendues en réponse.
Ainsi, pour un fichier qui se nomme écrire.php dans le jeu de caractères par défaut de la machine, c'est le webmestre qui décide s'il veut que l'URL correspondante contienne %C3%A9crire.php ou %E9crire.php, voire %82crire.php ou encore %CB%83%99%89%99%85K%97%88%97 (le dernier exemple est de l'EBCDIC).
Certes...
Au passage, j'imagine le cas de migration d'un serveur qui hébergeait des url contenant des caractères échappés, mettons en windows-1252. Et on passe sur un système où le codage par défaut est UTF-8. Existe-t-il des quelconques techniques permettant de forcer sur le serveur l'échappement des url avec un codage déterminé qui serait différent de la plateforme ? Sur tomcat on a un UriEncoding qui je crois fait un peu ça ?
