Re: Telefonnummern in HTML

[Andreas Kohlbach]

Es ging ursprünglich darum, ob das erste "+" in

<a href="tel:+491234567">+491234567</a>

kodiert werden müsste.

On Fri, 15 Sep 2023 22:31:25 +0200, Peter J. Holzer wrote:
>
> On 2023-09-15 19:01, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> Hallo Stefan, Du schriebst am 14 Sep 2023 07:27:09 GMT:
>>> >>> <a class="phone" href="tel:+491234567">+491234567</a>
>> ...
>>> Offenbar darf man hier gar nicht codieren:
> [...]
>> Ja, und dann wäre die Ausgabezeile oben gleich zweimal falsch:
>> Das erste "+" (hinter "tel") darf dann nicht codiert werden,
>> das zweite - weil ja nur der angezeigte Text - müßte aber.
>> Oder?

Ich sah schon:

"http://irknwas.tld/index.php?was1=was_anderes1&was2=was_anderes2&..."

Also "&" und nicht "&amp;"; kein Encoding.

Kann es zudem sein, dass Browser sich das vor dem Absenden passend
machen; es in der Praxis also egal sein sollte?

> Nein. Wie kommst Du darauf, dass man ein Zeichen in HTML-Text
> URL-encoden müsste (oder auch nur dürfte)?

Ein "Kann"?

Ich möchte mal <https://en.wikipedia.org/wiki/Query_string#URL_encoding>
einstreuen angenommen, es spricht die Wahrheit. Daraus:

| Some characters cannot be part of a URL (for example, the space) and
| some other characters have a special meaning in a URL.

Vielleicht "must not" statt "cannot"? Und reden wir vielleicht über
"Query String", der nur bedingt mit einer URL zu tun haben könnte?

F'up infosystems.
--
Andreas

[Peter J. Holzer]

On 2023-09-15 23:29, Andreas Kohlbach <a...@spamfence.net> wrote:
> Es ging ursprünglich darum, ob das erste "+" in
>
><a href="tel:+491234567">+491234567</a>
>
> kodiert werden müsste.
>
> On Fri, 15 Sep 2023 22:31:25 +0200, Peter J. Holzer wrote:
>>
>> On 2023-09-15 19:01, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>>> Hallo Stefan, Du schriebst am 14 Sep 2023 07:27:09 GMT:
>>>> >>> <a class="phone" href="tel:+491234567">+491234567</a>
>>> ...
>>>> Offenbar darf man hier gar nicht codieren:
>> [...]
>>> Ja, und dann wäre die Ausgabezeile oben gleich zweimal falsch:
>>> Das erste "+" (hinter "tel") darf dann nicht codiert werden,
>>> das zweite - weil ja nur der angezeigte Text - müßte aber.
>>> Oder?
>
> Ich sah schon:
>
> "http://irknwas.tld/index.php?was1=was_anderes1&was2=was_anderes2&..."
>
> Also "&" und nicht "&amp;"; kein Encoding.

Du bringst hier zwei Ebenen durcheinander: HTML und URIs. HTML-Entities
wie "&amp;" sind Teil von HTML (wie der Name schon sagt), URL-encoding
(auch Prozent-Encoding genannt) wird bei bestimmten Arten von URIs
angewendet.

Eine HTML-Entity wird vom Browser beim Parsen durch ein einzelnes
Zeichen ersetzt. Dazu muss er die Entity aber kennen. "&was2" kennt der
Browser nicht (abgesehen davon, dass hier der abschließende Strichpunkt
fehlt, was nur bei einigen Entities erlaubt ist), also hat er drei
Möglichkeiten:

* Er kann an der Stelle abbrechen und einen Syntax-Fehler melden.
Aus naheliegenden Gründen haben das nur ganz wenige Browser jemals
gemacht.
* Er kann die Entity durch einen Leerstring, ein Ersatzzeichen (z.B.
U+FFFD) oder ähnliches ersetzen. Das ist vermutlich noch etwas
unpraktischer als Möglichkeit 1.
* Er kann die einzelnen Zeichen der "Nicht-Entity" so übernehmen, wie
sie geschrieben wurden. "&was2" bleibt also die Folge von 5 Zeichen
'&', 'w', 'a', 's', '2', genauso, wie wenn hier "&amp;was2" gestanden
hätte.

Alle Mainstream-Browser machen letzteres und ich bin mir ziemlich
sicher, dass das in HTML5 auch das vorgeschriebene Verhalten ist.

Man kann also "&was2" schreiben und es ist genau das gleiche wie
"&amp;was2". Es ist aber ein bisschen gefährlich, denn theoretisch
könnte die WHATWG irgendwann in Zukunft eine Entity "&was2" definieren,
und dann würde das nicht mehr funktionieren.

> Kann es zudem sein, dass Browser sich das vor dem Absenden passend
> machen; es in der Praxis also egal sein sollte?

Das alles hat noch nichts mit dem Absenden zu tun, das betrifft nur das
Parsen des HTML-Dokuments. Das muss der Browser machen, bevor er die
Seite überhaupt anzeigt.

Vor dem Absenden muss der Browser eventuell URL-Encoding durchführen,
also z.B. ein "+" in "%2B" umwandeln. Z.B. bei Form-Feldern oder bei
Nicht-ASCII-Zeichen im URL. Aber natürlich darf er nicht blindlings den
ganzen URL URL-encoden, denn der ist ja (hoffentlich) schon großteils im
URL-Format.

(Und ein tel:-URI wird natürlich nicht an einen HTTP-Server geschickt,
sondern an eine Telephonie-App, also wäre URL-Encoding da sowieso
unsinnig)

>> Nein. Wie kommst Du darauf, dass man ein Zeichen in HTML-Text
>> URL-encoden müsste (oder auch nur dürfte)?
>
> Ein "Kann"?

% hat in HTML-*Text* keine Sonderbedeutung. Wenn Du dort %2B schreibst,
wird das auch als die drei Zeichen '%', '2', 'B' angezeigt. Wenn Du
(unnötigerweise, aber wenn's Spaß macht) ein '+' escapen willst, musst
Du eine HTML-Entity verwenden, nicht URL-Encoding. Also "&plus;" oder
"&#x2B;" oder "&#43;".

URL-Encoding ist - wie der Name schon sagt - für URLs, nicht für Text.

> Ich möchte mal <https://en.wikipedia.org/wiki/Query_string#URL_encoding>
> einstreuen angenommen, es spricht die Wahrheit. Daraus:
>
>| Some characters cannot be part of a URL (for example, the space) and
>| some other characters have a special meaning in a URL.
>
> Vielleicht "must not" statt "cannot"? Und reden wir vielleicht über
> "Query String", der nur bedingt mit einer URL zu tun haben könnte?

Ich habe keine Ahnung, was Du damit sagen willst.

hp