XHTML et & (Esperluette) encodage

mon site web est compatible XHTML Transitional sauf pour une chose : le & (ampersand) dans L'URL sont écrits comme il est, au lieu de &

C'est-à-dire que toutes les urls de mes pages sont habituellement comme ceci:

<a href="http://www.foo.com/page.aspx?x=1&y=2">Foo</a>

mais validateur XHTML génère cette erreur:

ne peut pas générer d'Identificateur de système pour l'entité générale" y "

... et il veut que l'url soit écrite comme ceci:

<a href="http://www.foo.com/page.aspx?x=1&amp;y=2">Foo</a>

le problème est QU'IE et Firefox ne gèrent pas l'URL correctement et ignorent le paramètre Y. Comment faire fonctionner ce lien et le valider correctement?

il me semble qu'il est impossible d'écrire des pages XHTML si les navigateurs ne fonctionnent pas avec des URLs strictement encodées XHTML.

voulez-vous voir en action? Voir la différence entre ces deux liens (copiez et collez-les tels quels):

http://stackoverflow.com/search?q=ff&sort=newest

et

http://stackoverflow.com/search?q=ff&amp;sort=newest
35
demandé sur doppelgreener 2008-11-08 23:27:53

5 réponses

je viens d'essayer ceci. Ce que vous avez essayé de faire est correcte. En HTML si vous écrivez un lien, les caractères & devraient être encodés comme &amp; vous encoderiez & comme %26 seulement si vous vouliez qu'une valeur de paramètre contienne une esperluette. Je viens d'écrire une page HTML simple qui contenait un lien: <a href="Default2.aspx?param1=63&amp;param2=hel">Click me</a> et ça a bien fonctionné: default2.aspx a reçu les paramètres prévus et la source a passé la validation.

le l'encodage de & comme &amp; est requis en HTML, pas dans le lien. Lorsque le navigateur voit le &amp; dans la source HTML pour un lien, il l'interprétera comme une ampère et la cible de lien sera comme prévu. Si vous collez une URL dans la barre d'adresse de votre navigateur, elle ne s'attend pas à ce qu'elle soit HTML et n'essaie pas d'interpréter un encodage HTML qu'elle pourrait contenir. C'est pourquoi votre exemple de liens que vous suggérez que nous devrions copier/coller dans un navigateur ne fonctionne pas et pourquoi nous ne le ferions pas s'attendre à travailler.

si vous postez un peu plus de votre code réel, nous pourrions être en mesure de voir ce que vous avez fait de mal, mais vous semblez vous diriger dans la bonne direction en utilisant &amp; dans vos étiquettes d'ancrage.

56
répondu pipTheGeek 2012-12-04 19:44:04

C'était ma faute: le contrôle Hyperlink déjà encodé &, donc mon url http://foo?x=1&amp;y=2 était encodé en http://foo?x=1&amp;amp;y=2

Normalement, le & à l'intérieur de l'url est correctement géré par les navigateurs, comme vous l'avez déclaré. Merci

6
répondu 2008-11-08 23:28:31

vous pouvez utiliser &amp; au lieu de & dans votre url dans votre page.

Qui devrait lui permettre d'être validé xhtml strict...

<a href="http://www.foo.com/page.aspx?x=1&amp;y=2">Foo</a>

Note, si elle est utilisée par un ASP.NET demande.La fonction QueryString, la chaîne de requête n'utilise pas L'encodage XML, elle utilise l'encodage URL :

/mypath/mypage?b=%26stuff

vous devez donc fournir une fonction traduisant ' & 'en %26

Remarque: dans ce cas, le Serveur.URLEncode ("neetu & geetu"), qui produirait neetu+%26+geetu, n'est pas ce que vous voulez, puisque vous avez besoin de traduire & dans %26, pas juste '&'. Vous devez ajouter un appel replace () appliqué au résultat URLEncode, afin de remplacer '%26amp;' par '%26'.

5
répondu VonC 2008-11-08 21:34:41

pour être encore plus complet: utilisez &#38; , un référence de caractère numérique .

parce que &amp; est une référence d'entité de caractère :

les références des entités de caractères sont définies dans le langage de balisage définition. Cela signifie, par exemple, que pour HTML seulement un la gamme de caractères (définie par la spécification HTML) peut être représentée comme entité de caractère références (et qui ne comprend qu'un petit sous-ensemble de la gamme Unicode).

ça vient des sages du W3C (lisez pour en savoir plus).

bien sûr, ce n'est pas très important, mais la suggestion de W3C est que le numérique sera valide et utilisable partout et toujours, tandis que le nommé est 'bien' pour HTML mais rien de plus.

-1
répondu kasimir 2014-09-25 19:00:30

le problème est pire que vous le pensez - essayez-le en Safari. et est converti en & et le hachage termine l'URL. La bonne réponse est de ne pas produire XHTML - il n'y a aucune raison qui justifie de passer plus de temps sur le développement et les utilisateurs Mac aliéner.

-4
répondu Simon 2008-11-11 09:20:13