Kodiere ich kaufmännisches Und in <a href…>?


157

Ich schreibe Code, der automatisch HTML generiert, und ich möchte, dass er die Dinge richtig codiert.

Angenommen, ich generiere einen Link zu der folgenden URL:

http://www.google.com/search?rls=en&q=stack+overflow

Ich gehe davon aus, dass alle Attributwerte HTML-codiert sein sollten. (Bitte korrigieren Sie mich, wenn ich falsch liege.) Wenn ich also die obige URL in ein Ankertag einfüge, sollte ich das kaufmännische Und wie folgt codieren &amp;:

<a href="http://www.google.com/search?rls=en&amp;q=stack+overflow">

Ist das korrekt?



6
@CiroSantilli: Hier geht es um tatsächliche URL-Zeichenfolgen. Hier geht es darum, wie sie codiert werden, wenn sie in HTML-Attributen angezeigt werden.
JW.

Wie ich sehe, ist die Codierung von kaufmännischem Und in HTML5 nicht immer erforderlich, und die Antworten sind veraltet.
Qdinar

Antworten:


175

Ja, so ist es. HTML-Entitäten werden in HTML-Attributen analysiert, und ein Streuner &würde eine Mehrdeutigkeit erzeugen. Deshalb sollten Sie immer schreiben und &amp;nicht nur &in alle HTML-Attribute.

Das heißt, nur &und Anführungszeichen müssen codiert werden. Wenn éIhr Attribut Sonderzeichen enthält , müssen Sie diese nicht codieren, um den HTML-Parser zu erfüllen.

Früher mussten URLs speziell mit Nicht-ASCII-Zeichen behandelt werden, z é. Sie mussten diese mit Prozent-Escapezeichen codieren, und in diesem Fall würde dies ergeben %C3%A9, da sie durch RFC 1738 definiert wurden . RFC 1738 wurde jedoch durch RFC 3986 (URIs, Uniform Resource Identifiers) und RFC 3987 (IRIs, Internationalized Resource Identifiers) ersetzt, auf deren Grundlage die WhatWG ihre Arbeit basierte, um zu definieren, wie sich Browser verhalten sollen, wenn sie eine URL mit Nicht-ASCII sehen Zeichen darin seit HTML5 . Es ist daher jetzt sicher, Nicht-ASCII-Zeichen in URLs aufzunehmen, ob prozentual codiert oder nicht.


1
Ich war mir ziemlich sicher, aber ich hatte einen seltenen Moment des Zweifels. Danke für die Bestätigung.
JW.

1
Sie können Leerzeichen auch als "+" anstatt als% 20 codieren, wodurch die URL leichter lesbar ist.
NickG

1
+ wird derzeit in Mailto-Links im nativen iPhone-Mail-Client nicht berücksichtigt, was es wert ist.
Ryan Olson


4
Ich würde hinzufügen (da ich gerade in diesen Fehler geraten bin), dass Sie, wenn Sie sich auf eine Vorlagen-Engine verlassen , prüfen sollten, ob dies automatisch dafür sorgt, dass HTML-Entitäten entkommen oder nicht. In meinem Fall tat Twig das, und ich konnte das Schreiben &amp;in das Tag-Attribut fälschlicherweise doppelt umgehen, anstatt es direkt zu verwenden &.
Kamafeather

24

Nach den aktuellen offiziellen HTML-Empfehlungen muss das kaufmännische Und beispielsweise &amp;in solchen Kontexten maskiert werden . Browser benötigen dies jedoch nicht, und die HTML5-CR schlägt vor, dies zu einer Regel zu machen , sodass spezielle Regeln für Attributwerte gelten. Aktuelle HTML5-Validatoren sind in dieser Hinsicht veraltet (siehe Fehlerbericht mit Kommentaren).

Es bleibt weiterhin möglich, kaufmännisches Und in Attributwerten zu umgehen, aber abgesehen von der Validierung mit aktuellen Tools besteht keine praktische Notwendigkeit, diese in hrefWerten zu maskieren (und es besteht ein geringes Risiko, Fehler zu machen, wenn Sie anfangen, ihnen zu entkommen).


4
XHTML ( echtes XHTML gesendet als application/xhtml+xml) wird es jedoch höchstwahrscheinlich immer erfordern.
Zneak

4
Eine Einschränkung dieser Änderung, die immer noch diskutiert, diskutiert und missverstanden wird, ist, dass das &jetzt in Ordnung sein soll, solange es " nicht mehrdeutig" ist. Eine naheliegende Möglichkeit, das kaufmännische Und mehrdeutig zu machen, besteht darin, ihm zuerst Nicht-Leerzeichen und dann ein Semikolon zu folgen. Das Ampersand ist jetzt zweideutig, und wird ein Parse - Fehler verursachen.
Matty

Wie Jukka sagte, besteht mit Sicherheit das Risiko, alle kaufmännischen Und-Zeichen zu codieren. Überlegen Sie also, wie wahrscheinlich es ist, dass eine Ihrer href-URLs ein Semikolon enthält. Eher unwahrscheinlich, da ich nicht sicher bin, ob ich jemals eine URL mit einem Semikolon gesehen habe. Nicht dass es nicht geht. Praktisch gesehen halte ich es nicht für wahrscheinlich, dass unsere Verwendung &nicht eindeutig ist. Daher verwenden wir es weiterhin nicht codiert in href-Attributen.
Matty

Der ganze Grund, warum das Entkommen notwendig ist, liegt genau in der Möglichkeit einer Mehrdeutigkeit . Dieses spezielle Problem führt möglicherweise in 99,99% der Fälle nicht zu XSS-Angriffsvektoren, schlechtem Rendering oder irgendwelchen Auswirkungen, aber das ist kein Grund, sich nicht darum zu kümmern. Richtig zu entkommen ist schwierig und es besteht immer die Möglichkeit, Fehler zu machen.
Phil

5

Ich poste eine neue Antwort, weil ich finde, dass die Antwort von zneak nicht genügend Beispiele enthält, die HTML- und URI-Behandlung nicht als unterschiedliche Aspekte und Standards anzeigt und einige kleinere Dinge fehlen.

Sie haben zwei Standards bezüglich URLs in links ( <a href).

Der erste Standard ist RFC 1866 (HTML 2.0), wo Sie in "3.2.1. Datenzeichen" die Zeichen lesen können, die maskiert werden müssen, wenn sie als Wert für ein HTML-Attribut verwendet werden. (Attribute selbst erlauben überhaupt keine Sonderzeichen, zB <a hr&ef="http://...sind sie weder erlaubt noch <a hr&amp;ef="http://....)

Später wurde dies in den HTML 4- Standard aufgenommen. Die Zeichen, denen Sie entkommen müssen, sind:

<   to   &lt;
>   to   &gt;
&   to   &amp;
"   to   &quote;
'   to   &apos;

Der andere Standard ist RFC 3986 "Generischer URI-Standard", in dem URLs behandelt werden (dies geschieht, wenn der Browser einem Link folgt, weil der Benutzer auf das HTML-Element geklickt hat).

reserved    = gen-delims / sub-delims

gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

Es ist wichtig, diese Zeichen zu maskieren, damit der Client weiß, ob sie Daten oder ein Trennzeichen darstellen.

Beispiel ohne Flucht:

https://example.com/?user=test&password&te&st&goto=https://google.com

Beispiel, voll legitime URL

https://example.com/?user=test&password&te%26st&goto=https%3A%2F%2Fgoogle.com

Beispiel für eine vollständig legitime URL im Wert des HTML-Attributs:

https://example.com/?user=test&amp;password&amp;te%26st&amp;goto=https%3A%2F%2Fgoogle.com

Auch wichtige Szenarien:

  • Javascript als Wert:

    <img src="..." onclick="window.location.href = &quot;https://example.com/?user=test&amp;password&amp;te%26st&amp;goto=https%3A%2F%2Fgoogle.com&quot;;">...</a>(Ja, ;;ist richtig.)

  • JSON als Wert:

    <a href="..." data-analytics="{&quot;event&quot;: &quot;click&quot;}">...</a>

  • Entkommene Dinge in entflohenen Dingen, doppelte Codierung, URL in URL innerhalb des Parameters usw., ...

    http://x.com/?passwordUrl=http%3A%2F%2Fy.com%2F%3Fuser%3Dtest&amp;password=&quot;&quot;123


3

Ja, sollten Sie konvertieren &zu &amp;.

Dieses HTML-Validator-Tool von W3C ist hilfreich für Fragen wie diese. Hier werden die Fehler und Warnungen für eine bestimmte Seite angezeigt.


1
Ich bin nicht sicher, ob der W3C-Validator dies ( &in einem href nicht entkommen ) als Fehler erkennt .
ChrisW

6
Derzeit akzeptiert der W3C-Validator unescaped & als gültig. Bedeutet dies, dass sich der Standard geändert hat und keine Codierung mehr erforderlich ist? (Die meisten Antworten hier veraltet machen)? Wenn ja, gilt dies nur für href oder ein Attribut?
Matto
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.