XHTML et & (esperluette) encodage

Question

Mon site est XHTML conforme de transition sauf pour une chose: le & (esperluette) dans l'URL sont écrits comme il est, au lieu de &

C'est, tous les urls dans mes pages sont généralement comme ceci:

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

Mais XHTML validator génère cette erreur:

cannot generate system identifier for general entity "y"

... et il veut l'URL pour être écrit comme ceci:

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

Le problème est que IE et Firefox ne et gérer correctement l'pas URL ignorer le paramètre y. Comment puis-je faire fonctionner ce lien et valider correctement?

Il me semble qu'il est impossible d'écrire des pages XHTML si les navigateurs ne fonctionnent pas avec des URL XHTML codées strictes.

Voulez-vous voir en action? Voyez la différence entre ces deux liens (les copier et les coller comme ils sont):

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

et

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

Answer 1

Je viens d'essayer ça. Ce que vous avez essayé de faire est correct. En HTML si vous écrivez un lien les caractères & doivent être codés comme & Vous ne coderiez que le & comme %26 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 cela a bien fonctionné: default2.aspx a reçu les paramètres prévus et la source a passé la validation.

Le codage de & en tant que & est requis en HTML, pas dans le lien. Lorsque le navigateur voit le & dans la source HTML d'un lien, il l'interprète comme une esperluette et la cible du 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 le codage HTML qu'elle peut contenir. C'est pourquoi vos liens d'exemples que vous suggérez que nous devrions copier/coller dans un navigateur ne fonctionnent pas et pourquoi nous ne nous attendrions pas à ce qu'ils fonctionnent. Si vous publiez un peu plus de votre code actuel, nous pourrions voir ce que vous avez fait de mal, mais vous semblez être dans la bonne direction en utilisant & dans vos balises d'ancrage.

Answer 2

vous pouvez utiliser & au lieu de & dans votre URL de votre page.

Cela devrait permettre de valider un xhtml strict ...

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

Remarque, si elle est utilisée par une fonction ASP.NET Request.QueryString, la chaîne de requête n'utilise pas l'encodage XML, il utilise URL encoding:

/mypath/mypage?b=%26stuff 

Alors vous devez fournir une traduction de la fonction '&' en% 26

note: dans ce cas, Server.URLEncod e ("neetu & geetu"), qui produirait neetu +% 26 + geetu, n'est pas ce que vous voulez, puisque vous devez traduire & en% 26, pas seulement '&'. Vous devez ajouter un appel replace() appliqué au résultat URLEncode, afin de remplacer '% 26amp'. par '% 26'.

Answer 3

C'était ma faute: le contrôle Hyperlink déjà codé &, donc mon url http://foo?x=1&y=2 a été codé pour http://foo?x=1&y=2

Normalement, l'ampli & l'intérieur de l'URL est traitée correctement par les navigateurs, comme vous l'avez dit. Merci

Answer 4

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

Answer 5

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

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

Character entity references are defined in the markup language definition. This means, for example, that for HTML only a specific range of characters (defined by the HTML specification) can be represented as character entity references (and that includes only a small subset of the Unicode range).

qui vient des sages au sein du W3C (lire this pour plus). Bien sûr, ce n'est pas une grosse affaire, mais la suggestion du W3C est que le numérique sera valide et utilisable partout et toujours, alors que le nom donné est "bien" pour le HTML mais rien de plus.