XHTML und & (Ampersand) Codierung

Question

Meine Website ist XHTML Transitional konform außer einer Sache: die & (Ampersand) in der URL geschrieben werden, wie es ist, statt &

Das heißt, alle URLs in meinen Seiten sind in der Regel wie folgt aus:

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

Aber XHTML validator erzeugt diesen Fehler:

cannot generate system identifier for general entity "y"

... und es will die URL wie folgt geschrieben werden:

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

Das Problem ist, dass IE und Firefox nicht die URL korrekt verarbeiten und die y-Parameter ignorieren. Wie kann ich diesen Link korrekt arbeiten und validieren lassen?

Es scheint mir, dass es unmöglich ist, XHTML-Seiten zu schreiben, wenn die Browser nicht mit streng verschlüsselten XHTML-URLs arbeiten.

Haben Sie in Aktion sehen? Sehen Sie den Unterschied zwischen diesen beiden Links (kopieren und einfügen, wie sie sind):

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

und

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

Answer 1

Ich habe versucht, genau dies. Was Sie versucht haben, ist korrekt. In HTML, wenn Sie schreiben einen Link die & Zeichen codiert werden sollte, wie & würden Sie nur die & als %26 kodieren, wenn Sie einen Parameterwert enthält ein kaufmännisches wollte. Ich schrieb nur eine einfache HTML-Seite, die einen Link enthalten: <a href="Default2.aspx?param1=63&amp;param2=hel">Click me</a> und es funktionierte gut: default2.aspx die Parameter erhalten soll und die Quelle geleitet Validierung.

Die Codierung von & als & ist in HTML erforderlich, nicht in der Verknüpfung. Wenn der Browser die & in der HTML-Quelle für einen Link sieht, interpretiert er es als kaufmännisches Und, und das Link-Ziel wird wie beabsichtigt sein.Wenn Sie eine URL in die Adresszeile Ihres Browsers einfügen, erwartet Sie nicht, dass es sich um HTML handelt, und versucht nicht, eine eventuell vorhandene HTML-Codierung zu interpretieren. Deshalb funktionieren Ihre Beispiel-Links, von denen Sie vorschlagen, dass wir sie in einen Browser kopieren sollten, nicht und wir erwarten nicht, dass sie funktionieren.

Wenn Sie etwas mehr von Ihrem tatsächlichen Code veröffentlichen, können wir sehen, was Sie falsch gemacht haben, aber Sie scheinen die richtige Richtung zu wählen, indem Sie & in Ihren Anchor-Tags verwenden.

Answer 2

Sie & statt & in Ihrer URL innerhalb Ihrer Seite nutzen könnten.

, mit denen sollte es eine strenge xhtml ...

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

Hinweis validiert werden, von einer ASP.NET Request.QueryString Funktion verwendet, wenn die Abfrage-Zeichenfolge nicht XML-Codierung nicht verwendet, verwendet es URL encoding:

/mypath/mypage?b=%26stuff 

So haben Sie eine Funktion übersetzen '&' in% 26

Hinweis zur Verfügung stellen müssen: in diesem Fall Server.URLEncod e (“Neetu & geetu“), die Neetu +% 26 + geetu produzieren würde, ist nicht das, was Sie wollen, da Sie & in% 26, nicht nur '&' übersetzen müssen. Sie müssen einen replace() -Aufruf für das URLEncode-Ergebnis hinzufügen, um "% 26amp;" zu ersetzen. nach '% 26'.

Answer 3

Es war meine Schuld: die Hyperlink Steuerung bereits & codiert, so http://foo?x=1&y=2 meine URL http://foo?x=1&y=2

Normalerweise wird die & amp innerhalb der URL korrekt von Browsern behandelt wird, wie Sie sagten codiert wurde. Danke

Answer 4

Das Problem ist schlimmer als Sie denken - versuchen Sie es in Safari. & Ampere; wird konvertiert in & # 38; und der Hash beendet die URL. Die richtige Antwort ist, XHTML nicht auszugeben - es gibt keinen Grund, der mehr Zeit für die Entwicklung und die Entfremdung von Mac-Benutzern rechtfertigt.

Answer 5

Um noch gründlicher zu sein: Verwenden Sie &, eine numerische Zeichenreferenz.

Da & ist ein Charakter Entitätsverweis:

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).

, die von den weisen Menschen auf W3C kommt (this für mehr lesen).

Natürlich ist dies keine sehr große Sache, aber der Vorschlag von W3C ist, dass der numerische gültig und überall und immer verwendbar ist, während der genannte für HTML "fein" ist, aber nichts mehr.