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 ?
Peut-on ou pas utiliser des caractères non ascii dans la valeur de l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire directement et ceux qui sont réservés, la doc est la : http://www.ietf.org/rfc/rfc2396.txt
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).
Oui, c'est normal. Et assez logique à mon avis. Voir aussi http://www.la-grange.net/w3c/html4.01/appendix/notes.html#non-ascii-chars
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.
Le RFC 2398 date de 1998.
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.
Il n'y aucun caractère hors Ascii dans les URI de Wikipedia : http://fr.wikipedia.org/wiki/Anton%C3%ADn_Dvo%C5%99%C3%A1k
Alors, quelles sont les bonnes pratiques et les standards en la matière ?
J'espère que les documents qui précèdent répondent à tes questions.
Le 12/10/2008 22:30, mpg a écrit :
Peut-on ou pas utiliser des caractères non ascii dans la valeur de
l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce
qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire
directement et ceux qui sont réservés, la doc est la :
http://www.ietf.org/rfc/rfc2396.txt
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).
Oui, c'est normal. Et assez logique à mon avis. Voir aussi
http://www.la-grange.net/w3c/html4.01/appendix/notes.html#non-ascii-chars
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.
Le RFC 2398 date de 1998.
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.
Il n'y aucun caractère hors Ascii dans les URI de Wikipedia :
http://fr.wikipedia.org/wiki/Anton%C3%ADn_Dvo%C5%99%C3%A1k
Alors, quelles sont les bonnes pratiques et les standards en la matière ?
J'espère que les documents qui précèdent répondent à tes questions.
Peut-on ou pas utiliser des caractères non ascii dans la valeur de l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire directement et ceux qui sont réservés, la doc est la : http://www.ietf.org/rfc/rfc2396.txt
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).
Oui, c'est normal. Et assez logique à mon avis. Voir aussi http://www.la-grange.net/w3c/html4.01/appendix/notes.html#non-ascii-chars
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.
Le RFC 2398 date de 1998.
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.
Il n'y aucun caractère hors Ascii dans les URI de Wikipedia : http://fr.wikipedia.org/wiki/Anton%C3%ADn_Dvo%C5%99%C3%A1k
Alors, quelles sont les bonnes pratiques et les standards en la matière ?
J'espère que les documents qui précèdent répondent à tes questions.
Patrick Mevzek
Le Sun, 12 Oct 2008 23:43:45 +0200, Olivier Miakinen a écrit:
Peut-on ou pas utiliser des caractères non ascii dans la valeur de l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire directement et ceux qui sont réservés, la doc est la : http://www.ietf.org/rfc/rfc2396.txt
Les URIs sont remis au goût du jour par les IRIs : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Sun, 12 Oct 2008 23:43:45 +0200, Olivier Miakinen a écrit:
Peut-on ou pas utiliser des caractères non ascii dans la valeur de
l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce
qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire
directement et ceux qui sont réservés, la doc est la :
http://www.ietf.org/rfc/rfc2396.txt
Les URIs sont remis au goût du jour par les IRIs :
ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Sun, 12 Oct 2008 23:43:45 +0200, Olivier Miakinen a écrit:
Peut-on ou pas utiliser des caractères non ascii dans la valeur de l'attribut href en html ?
Aucun octet de valeur supérieure à 127 n'est légal dans une URI. En ce qui concerne les caractères Ascii, pour savoir ceux que tu peux écrire directement et ceux qui sont réservés, la doc est la : http://www.ietf.org/rfc/rfc2396.txt
Les URIs sont remis au goût du jour par les IRIs : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Olivier Miakinen
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URIs sont remis au goût du jour par les IRI[] : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986 STD: 66 Updates: 1738 Obsoletes: 2732, 2396, 1808 January 2005
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URIs sont remis au goût du jour par les IRI[] :
ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986
STD: 66
Updates: 1738
Obsoletes: 2732, 2396, 1808
January 2005
[ Message republié car je trouve ridicule de ma part d'avoir corrigé une coquille à un endroit et pas aux deux autres... ]
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URI[] sont remis au goût du jour par les IRI[] : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986 STD: 66 Updates: 1738 Obsoletes: 2732, 2396, 1808 January 2005
Paul Gaborit
À (at) Mon, 13 Oct 2008 01:15:14 +0200, Olivier Miakinen <om+ écrivait (wrote):
[ Message republié car je trouve ridicule de ma part d'avoir corrigé une coquille à un endroit et pas aux deux autres... ]
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URI[] sont remis au goût du jour par les IRI[] : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986 STD: 66 Updates: 1738 Obsoletes: 2732, 2396, 1808 January 2005
Ceci étant, ta réponse au PO reste d'actualité. Voici un extrait concernant les IRIs:
A protocol or format element should be explicitly designated to be able to carry IRIs. The intent is not to introduce IRIs into contexts that are not defined to accept them. For example, XML schema [XMLSchema] has an explicit type "anyURI" that includes IRIs and IRI references. Therefore, IRIs and IRI references can be in attributes and elements of type "anyURI". On the other hand, in the HTTP protocol [RFC2616], the Request URI is defined as a URI, which means that direct use of IRIs is not allowed in HTTP requests.
Donc, pas d'IRI dans le contexte HTTP qui nous intéresse ici.
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 01:15:14 +0200,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):
[ Message republié car je trouve ridicule de ma part d'avoir corrigé
une coquille à un endroit et pas aux deux autres... ]
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URI[] sont remis au goût du jour par les IRI[] :
ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986
STD: 66
Updates: 1738
Obsoletes: 2732, 2396, 1808
January 2005
Ceci étant, ta réponse au PO reste d'actualité. Voici un extrait
concernant les IRIs:
A protocol or format element should be explicitly designated to be
able to carry IRIs. The intent is not to introduce IRIs into
contexts that are not defined to accept them. For example, XML
schema [XMLSchema] has an explicit type "anyURI" that includes
IRIs and IRI references. Therefore, IRIs and IRI references can be
in attributes and elements of type "anyURI". On the other hand,
in the HTTP protocol [RFC2616], the Request URI is defined as a
URI, which means that direct use of IRIs is not allowed in HTTP
requests.
Donc, pas d'IRI dans le contexte HTTP qui nous intéresse ici.
Et pour compléter... Les caractères autorisés dans les URI sont pris
dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et
en plus, ça varie selon l'endroit où le caractère est utilisé dans
l'URI.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 01:15:14 +0200, Olivier Miakinen <om+ écrivait (wrote):
[ Message republié car je trouve ridicule de ma part d'avoir corrigé une coquille à un endroit et pas aux deux autres... ]
Le 13/10/2008 00:25, Patrick Mevzek a écrit :
http://www.ietf.org/rfc/rfc2396.txt
Les URI[] sont remis au goût du jour par les IRI[] : ftp://ftp.rfc-editor.org/in-notes/rfc3987.txt
Ah, j'étais en retard de deux métros pour les URI :
Request for Comments: 3986 STD: 66 Updates: 1738 Obsoletes: 2732, 2396, 1808 January 2005
Ceci étant, ta réponse au PO reste d'actualité. Voici un extrait concernant les IRIs:
A protocol or format element should be explicitly designated to be able to carry IRIs. The intent is not to introduce IRIs into contexts that are not defined to accept them. For example, XML schema [XMLSchema] has an explicit type "anyURI" that includes IRIs and IRI references. Therefore, IRIs and IRI references can be in attributes and elements of type "anyURI". On the other hand, in the HTTP protocol [RFC2616], the Request URI is defined as a URI, which means that direct use of IRIs is not allowed in HTTP requests.
Donc, pas d'IRI dans le contexte HTTP qui nous intéresse ici.
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Pierre Goiffon
Paul Gaborit wrote:
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Paul Gaborit wrote:
Et pour compléter... Les caractères autorisés dans les URI sont pris
dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et
en plus, ça varie selon l'endroit où le caractère est utilisé dans
l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Pierre Goiffon
mpg wrote:
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).
Bonjour,
Le passage de caractères hors us-ascii est à prioris 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>
mpg wrote:
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).
Bonjour,
Le passage de caractères hors us-ascii est à prioris 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>
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).
Bonjour,
Le passage de caractères hors us-ascii est à prioris 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>
Paul Gaborit
À (at) Mon, 13 Oct 2008 13:11:33 +0200, Pierre Goiffon écrivait (wrote):
Paul Gaborit wrote:
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
C'est par exemple la section 2.2 de la RFC 3986 qui indique les caractères "délimiteurs" qui doivent être %-encodés pour ne pas être considérés comme délimiteur. Le fait d'être "délimiteur" dépend du schéma d'URL utilisé et du "component" où le caractère apparait..
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 13:11:33 +0200,
Pierre Goiffon <pgoiffon@free.fr.invalid> écrivait (wrote):
Paul Gaborit wrote:
Et pour compléter... Les caractères autorisés dans les URI sont pris
dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et
en plus, ça varie selon l'endroit où le caractère est utilisé dans
l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
C'est par exemple la section 2.2 de la RFC 3986 qui indique les
caractères "délimiteurs" qui doivent être %-encodés pour ne pas être
considérés comme délimiteur. Le fait d'être "délimiteur" dépend du
schéma d'URL utilisé et du "component" où le caractère apparait..
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 13 Oct 2008 13:11:33 +0200, Pierre Goiffon écrivait (wrote):
Paul Gaborit wrote:
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
C'est par exemple la section 2.2 de la RFC 3986 qui indique les caractères "délimiteurs" qui doivent être %-encodés pour ne pas être considérés comme délimiteur. Le fait d'être "délimiteur" dépend du schéma d'URL utilisé et du "component" où le caractère apparait..
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Olivier Miakinen
Le 13/10/2008 13:11, Pierre Goiffon a écrit :
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Par exemple on peut avoir une virgule « , » ou deux points de suite « .. » dans la partie droite d'une URI mais pas dans le nom de host.
Le 13/10/2008 13:11, Pierre Goiffon a écrit :
Et pour compléter... Les caractères autorisés dans les URI sont pris
dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et
en plus, ça varie selon l'endroit où le caractère est utilisé dans
l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Par exemple on peut avoir une virgule « , » ou deux points de suite
« .. » dans la partie droite d'une URI mais pas dans le nom de host.
Et pour compléter... Les caractères autorisés dans les URI sont pris dans un ensemble très limités (c'est un sous-ensemble de l'ASCII). Et en plus, ça varie selon l'endroit où le caractère est utilisé dans l'URI.
Pas bien compris ce que vous vouliez dire... précisions ?
Par exemple on peut avoir une virgule « , » ou deux points de suite « .. » dans la partie droite d'une URI mais pas dans le nom de host.
Olivier Miakinen
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">.
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">.
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">.
