von KOMA » Fr 21. Okt 2022, 10:12
ich meine ja nur hat geschrieben: ↑Do 20. Okt 2022, 08:52
was eigentlich alle modernen Browser inzwischen verkraften
Uhhh, mit solchen Aussagen wäre ich vorsichtig. Bei mir hier kann eigentlich nur Firefox und Derivate davon Domains mit Umlauten selbst in Punycode umwandeln und öffnen. Alle anderen Browser, die ich getestet habe, wandeln allenfalls
ö in
oe und
ß in
ss.
Und da der Prozentcode letztlich nur eine alternative Übermittlungsform für Sonderzeichen über ASCII-Wege ist, setzen folgerichtig diverse Browser Prozentcode im Domain-Teil von URLs ebenfalls nicht in der gewünschten Form um. Das funktioniert zuverlässig in der Tat nur mit Punycode.
Stefan Kottwitz hat geschrieben: ↑Do 20. Okt 2022, 15:46
nicht alle RFCs werden Standards (manche sind experimentell)
Jaaaaa, aber. RFC 3987 für Internationalized Resource Identifiers (IRIs) in der Fassung von 2005 ist ein Proposed Standard . Das ist schon ziemlich weit im Standardisierungsprozess und in der Tat für den Pfad-Teil einer URL inzwischen Standard. Beim Domain-Teil kann man sich streiten, ob nicht Punycode zu bevorzugen ist – u. a. wegen Tricksereien mit Domains. Der RFC (war damals AFAIR eine 2000er-Nummer) für HTTP 1.1 war übrigens auch AFAIR fast zwei Jahrzehnte Proposed Standard, und trotzdem unverzichtbarer de-facto-Standard. Dann wurde er nochmal überarbeitet, um ein paar Klarstellungen einzuarbeiten, wobei er AFAIK auch in mehrere RFCs aufgeteilt wurde.
Aber, wie gesagt: Prozentcode ist AFAIK im Domain-Part noch extrem unüblich. Dagegen ist er im Pfad-Teil nicht ungewöhnlich. Wir kennen das alle beispielsweise von Argumenten für Suchanfragen: wie
https://golatex.de/search.php?keywords=m%C3%BCssen. Und da funktioniert es auf goLaTeX auch. Aufgrund der Problematik mit leichter Domainverfälschbarkeit bei Prozentcode bzw. direkter Umsetzung von UTF8, halte ich das Vorgehen von goLaTeX deshalb für keinen Fehler, sondern im Gegenteil für korrekt. Link-Spam gibt es ja leider immer wieder. Und ich will da nicht auf eine Domain geleitet werden, die womöglich wie eine mir bekannte aussieht, es aber wegen Unicode-Tricks im Namen gar nicht ist.
Und aus dem Grund kann ich übrigens Stefan auch insofern zustimmen, als die Links auf
www.rößner.de selbst sehr ungeschickt gemacht sind. Dort hätte man unbedingt Punycode verwenden sollen. So funktioniert das – wenn man aktuellen Browser-Statistiken glauben darf – bei den meisten Besuchern nicht.
Und ansonsten: Das Problem mit internationalen Domains ist komplex. Wie hoch die Priorität dafür hier sein muss, kann man vielleicht abschätzen, wenn man sieht, wie selten es auf goLaTeX deshalb ein Problem gibt. Andere Dinge sehe ich da wesentlich wichtiger (beispielsweise das ärgerliche Problem mit
b als optionalem Argument von
tabular,
\parbox,
minipage etc., das aber offenbar ebenfalls nicht einfach zu lösen ist). Und ein Administrator hat normalerweise schon genug zu tun, ohne dass er selbst an der Forensoftware Hand anlegt.
[quote="ich meine ja nur" post_id=120154 time=1666248721]
was eigentlich alle modernen Browser inzwischen verkraften
[/quote]
Uhhh, mit solchen Aussagen wäre ich vorsichtig. Bei mir hier kann eigentlich nur Firefox und Derivate davon Domains mit Umlauten selbst in Punycode umwandeln und öffnen. Alle anderen Browser, die ich getestet habe, wandeln allenfalls [tt]ö[/tt] in [tt]oe[/tt] und [tt]ß[/tt] in [tt]ss[/tt].
Und da der Prozentcode letztlich nur eine alternative Übermittlungsform für Sonderzeichen über ASCII-Wege ist, setzen folgerichtig diverse Browser Prozentcode im Domain-Teil von URLs ebenfalls nicht in der gewünschten Form um. Das funktioniert zuverlässig in der Tat nur mit Punycode.
[quote="Stefan Kottwitz" post_id=120156 time=1666273578 user_id=32]
nicht alle RFCs werden Standards (manche sind experimentell)
[/quote]
Jaaaaa, aber. RFC 3987 für Internationalized Resource Identifiers (IRIs) in der Fassung von 2005 ist ein Proposed Standard . Das ist schon ziemlich weit im Standardisierungsprozess und in der Tat für den Pfad-Teil einer URL inzwischen Standard. Beim Domain-Teil kann man sich streiten, ob nicht Punycode zu bevorzugen ist – u. a. wegen Tricksereien mit Domains. Der RFC (war damals AFAIR eine 2000er-Nummer) für HTTP 1.1 war übrigens auch AFAIR fast zwei Jahrzehnte Proposed Standard, und trotzdem unverzichtbarer de-facto-Standard. Dann wurde er nochmal überarbeitet, um ein paar Klarstellungen einzuarbeiten, wobei er AFAIK auch in mehrere RFCs aufgeteilt wurde.
Aber, wie gesagt: Prozentcode ist AFAIK im Domain-Part noch extrem unüblich. Dagegen ist er im Pfad-Teil nicht ungewöhnlich. Wir kennen das alle beispielsweise von Argumenten für Suchanfragen: wie [url=https://golatex.de/search.php?keywords=m%C3%BCssen]https://golatex.de/search.php?keywords=m%C3%BCssen[/url]. Und da funktioniert es auf goLaTeX auch. Aufgrund der Problematik mit leichter Domainverfälschbarkeit bei Prozentcode bzw. direkter Umsetzung von UTF8, halte ich das Vorgehen von goLaTeX deshalb für keinen Fehler, sondern im Gegenteil für korrekt. Link-Spam gibt es ja leider immer wieder. Und ich will da nicht auf eine Domain geleitet werden, die womöglich wie eine mir bekannte aussieht, es aber wegen Unicode-Tricks im Namen gar nicht ist.
Und aus dem Grund kann ich übrigens Stefan auch insofern zustimmen, als die Links auf [url=http://www.xn--rner-vna1l.de]www.rößner.de[/url] selbst sehr ungeschickt gemacht sind. Dort hätte man unbedingt Punycode verwenden sollen. So funktioniert das – wenn man aktuellen Browser-Statistiken glauben darf – bei den meisten Besuchern nicht.
Und ansonsten: Das Problem mit internationalen Domains ist komplex. Wie hoch die Priorität dafür hier sein muss, kann man vielleicht abschätzen, wenn man sieht, wie selten es auf goLaTeX deshalb ein Problem gibt. Andere Dinge sehe ich da wesentlich wichtiger (beispielsweise das ärgerliche Problem mit [tt]b[/tt] als optionalem Argument von [tt]tabular[/tt], [tt]\parbox[/tt], [tt]minipage[/tt] etc., das aber offenbar ebenfalls nicht einfach zu lösen ist). Und ein Administrator hat normalerweise schon genug zu tun, ohne dass er selbst an der Forensoftware Hand anlegt.