Umlaute in URL

[Gunther]

Hallo werte Selfgemeinde,

ich hätte gerne eure Ansichten/ Meinungen zu folgender Frage gehört:
Spricht etwas dagegen, in einer (sprechenden) URL Umlaute zu verwenden?

Konkret geht es um: example.com/über-mich

Google spuckt alles aus, u.a.

• ueber-mich
• Ueber-mich
• uber-mich
• uebermich
  uvm.

Mir ist durchaus bekannt, dass die "Regeln" eigentlich besagen:

• keine Umlaute
• keine Großbuchstaben
• keine Leer- und Sonderzeichen

Aber von Zeit zu Zeit sollte man Althergebrachtes ja auch mal hinterfragen. ;-)

Ein Argument ist ja bspw. das jeweilige Tastaturlayout, welches u.U. keine Umlaute beinhaltet.
Dazu kann ich sagen, dass
1. die potentielle Zielgruppe der Website rein auf Deutschland beschränkt ist
2. die Seite per Link von anderen Seiten aus erreichbar ist
3. auch die Eingabe von 'ueber-mich' oder 'uber-mich' auf die Seite 'über-mich' weiterleitet

Gibt es aktuell trotzdem (zwingende) Gründe/ Argumente, auf Umlaute zu verzichten?

Für eure freundliche Unterstützung wie immer meinen besten Dank im Voraus.

Gruß Gunther

[Tom]

Hello,

ich hätte gerne eure Ansichten/ Meinungen zu folgender Frage gehört:
Spricht etwas dagegen, in einer (sprechenden) URL Umlaute zu verwenden?

Konkret geht es um: example.com/über-mich

Das Problem kommt erst beim Speichern der Ressource, z.B. auf Windows-Systemen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunther]

Hello Tom!

Das Problem kommt erst beim Speichern der Ressource, z.B. auf Windows-Systemen.

Du meinst, wenn jemand im Browser auf 'Speichern unter ...' klickt?
Dann schlägt dir Windows ganz von alleine den Titel der Webseite als Namen vor.
Und dieser lautet in meinem Fall: Über mich
Aber auch das stellt kein Problem dar, abgesehen davon, dass man den Namen vor dem Speichern ja auch noch ändern kann.

Gruß Gunther

[Tom]

Hello Gunther,

Du meinst, wenn jemand im Browser auf 'Speichern unter ...' klickt?

Ich meine, wenn Du die auf deinem Windows-basierten Webserver anlegen willst

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunther]

Hello Tom,

Du meinst, wenn jemand im Browser auf 'Speichern unter ...' klickt?

Ich meine, wenn Du die auf deinem Windows-basierten Webserver anlegen willst

ah jetzt ...! ;-)

Aber auch das ist kein Problem, da die eigentliche Resource ohne Umlaute im Namen gespeichert wird (wobei diese dynamisch generiert wird und nicht statisch, bzw. nur zu Teilen statisch ist).

Es geht mir wirklich rein um die Anzeige in der Adresszeile des Browsers.

Gruß Gunther

[Tom]

Hello Gunther,

Ich meine, wenn Du die auf deinem Windows-basierten Webserver anlegen willst

ah jetzt ...! ;-)

Aber auch das ist kein Problem, da die eigentliche Resource ohne Umlaute im Namen gespeichert wird (wobei diese dynamisch generiert wird und nicht statisch, bzw. nur zu Teilen statisch ist).

Es geht mir wirklich rein um die Anzeige in der Adresszeile des Browsers.

File im Windows-Dateisystem:

ÜblerÄther.php

Anzeige in der Index-Page des Apachen (der kann es noch):

[TXT]  ÜblerÄther.php

Anzeige in der URL-Leiste des Browsers, wenn man drauf klickt (geht auch noch)

http://testserver.lan/codierung/%C3%9Cbler%C3%84ther.php

Anzeige der Seite (PHP ist zu doof dafür):

Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0

Fatal error: Unknown: Failed opening required 'M:/USER/TOM/WebProgTests/Xampp/codierung
    /ÃœblerÄther.php' (include_path='.;C:\Programme\xampp\php\PEAR') in Unknown on line 0

Bei anderen Scriptsprachen kann ich es Dir nicht sagen...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Anzeige in der URL-Leiste des Browsers, wenn man drauf klickt (geht auch noch)

http://testserver.lan/codierung/%C3%9Cbler%C3%84ther.php

angezeigt wurde das hier aber als "ÜblerÄther.php"
Da müsste ich jetzt mal wieder den alt-PC mit dem Altbrowser nehem, ob der die URL-Codierung noch anzeigt.

Die Sicht hat sich erst nach dem Posten verändert...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunther]

Hello Tom!

Anzeige in der URL-Leiste des Browsers, wenn man drauf klickt (geht auch noch)

http://testserver.lan/codierung/%C3%9Cbler%C3%84ther.php

angezeigt wurde das hier aber als "ÜblerÄther.php"
Da müsste ich jetzt mal wieder den alt-PC mit dem Altbrowser nehem, ob der die URL-Codierung noch anzeigt.

Die Sicht hat sich erst nach dem Posten verändert...

Besten Dank für deine Mühe!

Und ja, das ist ja der Punkt, den Martin auch angesprochen hat.
Aber AFAIK ist diese "Problematik" mit den älteren IE Versionen "ausgestorben" (BTW: Auch der 8er interessiert mich nicht mehr).

Und du hast in deiner PHP Datei auch 'urldecode()' verwendet ...? :-P

Gruß Gunther

[Tom]

Hello,

Und du hast in deiner PHP Datei auch 'urldecode()' verwendet ...? :-P

Nö:

<?php

echo $_SERVER['SCRIPT_NAME'];

?>

Soweit ist es gar nicht erst gkommen, dass die Datei gelesen wurde. PHP hat schon einen falschen Ressource-Namen gesucht. Ich nehme an, dass da die url-codierte Form angekommen ist. Das hat der Browser automatisch gemacht. Und PHP (als Modul) oder der Apache haben dann "vergessen", die URL-Codierung rückgängig zu machen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Soweit ist es gar nicht erst gkommen, dass die Datei gelesen wurde. PHP hat schon einen falschen Ressource-Namen gesucht. Ich nehme an, dass da die url-codierte Form angekommen ist. Das hat der Browser automatisch gemacht. Und PHP (als Modul) oder der Apache haben dann "vergessen", die URL-Codierung rückgängig zu machen.

Also der Apache ist es nicht!

Als HTML-Datei (ÜblerÄther.html) funktioniert es nämlich.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Der Martin]

Hi,

Also der Apache ist es nicht!
Als HTML-Datei (ÜblerÄther.html) funktioniert es nämlich.

ja, wir hatten ja neulich schon herausgefunden, dass das Problem an der File-Schnittstelle von PHP nach Windows liegt.

Ciao,
 Martin

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

Anzeige in der URL-Leiste des Browsers, wenn man drauf klickt (geht auch noch)

http://testserver.lan/codierung/%C3%9Cbler%C3%84ther.php

angezeigt wurde das hier aber als "ÜblerÄther.php"
Da müsste ich jetzt mal wieder den alt-PC mit dem Altbrowser nehem, ob der die URL-Codierung noch anzeigt.

im Posting? - Nein.
in der Adresszeile? - Du kannst den (kompletten!) Inhalt der Adresszeile in einen Texteditor kopieren und schon wird aus

example.com/über mich
http://example.com/%C3%BCber%20mich

Die Sicht hat sich erst nach dem Posten verändert...

Dafür gibts die Vorschau ;-p

Matthias

[Der Martin]

Hallo,

Du kannst den (kompletten!) Inhalt der Adresszeile in einen Texteditor kopieren und schon wird aus

example.com/über mich
http://example.com/%C3%BCber%20mich

im aktuellen Firefox ja, im Opera Classic (12.16) nicht.
Viel lieber wäre mir aber eine Einstellung, die auch in der Adresszeile http://example.com/%C3%BCber%20mich anzeigt. Die _Ein_gabe von Umlauten ist ja okay; danach möchte ich die URL-Zeile aber so sehen, wie sie auch ins Internet gesendet wird.
Noch lieber wäre mir, wenn man auch die optische Hervorhebung des Domainnamens abstellen könnte. Im Firefox geht's, im Opera anscheinend nicht. Ärgerlich.

Ciao,
 Martin

[molily]

Hallo,

Die _Ein_gabe von Umlauten ist ja okay; danach möchte ich die URL-Zeile aber so sehen, wie sie auch ins Internet gesendet wird.

Wie hätten Sie es denn gerne, als Nullen und Einsen oder ist ein Hexdump ausreichend?

Dass sich der Browser so verhält, ist nur konsequent. Du siehst ja auch kein Punycode, wenn du eine »Umlautdomain« aufrufst. Kodierungen finden nicht auf der Anwendungsschicht, sondern der Darstellungsschicht statt. Für den User muss das transparent sein. Das ist der Sinn von IRIs. Das ist erst sinnvolle Internationalisierung.

Noch lieber wäre mir, wenn man auch die optische Hervorhebung des Domainnamens abstellen könnte. Im Firefox geht's, im Opera anscheinend nicht. Ärgerlich.

Das hat alles seine Gründe. Hauptsächlich soll damit Phishing vorgebeugt werden. Die TLD ist aus Sicherheitsgründen der wichtigste Teil der URL. Für Normaluser ist oftmals nur diese interessant, weil meist auch nur diese aussagekräftig. Das Web ist übersäht mit schlechten URLs wie, sagen wir einmal /cgi-bin/user/fo_post. ;)

Dich wird sicher die jüngste Diskussion über das experimentelle Verstecken der URL in Chrome erfreuen. Artikelübersicht: http://www.brucelawson.co.uk/2014/reading-list-75/

Mathias

[Der Martin]

Moin,

Die _Ein_gabe von Umlauten ist ja okay; danach möchte ich die URL-Zeile aber so sehen, wie sie auch ins Internet gesendet wird.
Wie hätten Sie es denn gerne, als Nullen und Einsen oder ist ein Hexdump ausreichend?

Hexdump wär schon okay. Zumindest für die Nicht-ASCII-Zeichen.

Dass sich der Browser so verhält, ist nur konsequent. Du siehst ja auch kein Punycode, wenn du eine »Umlautdomain« aufrufst.

Stimmt, und auch das stört mich. - Wobei das ja nicht immer so war. In der Übergangszeit, als IDN/Punycode noch nicht flächendeckend verbreitet war, haben einige Browser zwar Umlaute als Eingabe akzeptiert, dann aber trotzdem den Punycode-Domainnamen in der Adresszeile angezeigt. Gefiel mir besser.

Kodierungen finden nicht auf der Anwendungsschicht, sondern der Darstellungsschicht statt. Für den User muss das transparent sein.

Für mich heißt transparent, dass ich genau das sehe, was auch verarbeitet und/oder übertragen wird. Wenn Informationen für den technischen Laien "geschönt" oder verständlicher dargestellt werden, ist das völlig in Ordnung (auch wenn ich diesen Schritt in vielen Fällen gern abschaltbar hätte), aber nicht das, was ich unter "Transparenz" verstehe.
Ich gebe aber auch zu, dass ich mich häufig mehr mit der Maschine identifiziere, als mit Laien-Nutzern.

Noch lieber wäre mir, wenn man auch die optische Hervorhebung des Domainnamens abstellen könnte. Im Firefox geht's, im Opera anscheinend nicht. Ärgerlich.
Das hat alles seine Gründe. Hauptsächlich soll damit Phishing vorgebeugt werden.

Ich weiß.

Die TLD ist aus Sicherheitsgründen der wichtigste Teil der URL. Für Normaluser ist oftmals nur diese interessant, weil meist auch nur diese aussagekräftig.

Das sehe ich nicht so; ich finde ggf. vorhandene Subdomains und den Local Path ebenso wichtig und entscheidend; das einzige, was ich einem Laien gegenüber vielleicht abwerten würde, sind URL-Parameter (obwohl sie technisch ebenso wichtig sind wie alles andere). Ich kritisiere auch nicht, dass man die große Gruppe der technisch nicht versierten Nutzer "schont", indem man sie nicht mit der vollen Information konfrontiert; ich kritisiere aber, wenn solche Maßnahmen nicht auf Wunsch wieder abstellbar sind.

Dich wird sicher die jüngste Diskussion über das experimentelle Verstecken der URL in Chrome erfreuen. Artikelübersicht: http://www.brucelawson.co.uk/2014/reading-list-75/

Hab jetzt nur mal flüchtig reingeschaut - aber schon allein die Idee dahinter finde ich unerhört.

Ciao,
 Martin

[molily]

Für mich heißt transparent, dass ich genau das sehe, was auch verarbeitet und/oder übertragen wird. Wenn Informationen für den technischen Laien "geschönt" oder verständlicher dargestellt werden, ist das völlig in Ordnung (auch wenn ich diesen Schritt in vielen Fällen gern abschaltbar hätte), aber nicht das, was ich unter "Transparenz" verstehe.

Transparenz ist hier ein technischer Terminus, der im Bereich der Kodierungen eine besondere Bedeutung hat.
http://de.wikipedia.org/wiki/Transparenz_(Computersystem)

Mathias

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Viel lieber wäre mir aber eine Einstellung, die auch in der Adresszeile http://example.com/%C3%BCber%20mich anzeigt.

Für den Host kannst du das im Firefox in about:config einstellen: network.IDN_show_punycode. Für den Pfad hab ich nichts dergleichen gefunden.

Die _Ein_gabe von Umlauten ist ja okay; danach möchte ich die URL-Zeile aber so sehen, wie sie auch ins Internet gesendet wird.

Warum? Was interessiert dich der URI, wenn der IRI lesbarer ist?

Qapla'

[Der Martin]

Hi,

Die _Ein_gabe von Umlauten ist ja okay; danach möchte ich die URL-Zeile aber so sehen, wie sie auch ins Internet gesendet wird.
Warum? Was interessiert dich der URI, wenn der IRI lesbarer ist?

wie gesagt: Ich möchte grundsätzlich (nicht nur in diesem Fall) gern das sehen, was "an der Basis" passiert. Wenn ich die in Prosa interpretierte Fassung zusätzlich bekomme, ist das in Ordnung, aber bitte nicht ausschließlich. So wie mich bei Strings ja auch die Byte-für-Byte-Darstellung interessiert, und erst in zweiter Linie die Zeichen, die durch diese Codes dargestellt werden.

Solltest du doch wissen, du hast dich ja schon öfter darüber gewundert. Ich erwarte ja nicht, dass du es auch so halten sollst.

Ciao,
 Martin

[molily]

Hallo,

So wie mich bei Strings ja auch die Byte-für-Byte-Darstellung interessiert, und erst in zweiter Linie die Zeichen, die durch diese Codes dargestellt werden.

Sorry, aber das glaube ich dir nicht.

Wann hast du dich das letzte Mal dafür interessiert, wie z.B. JavaScript-Engines deine Strings als Bytes speichern?

Wahrscheinlich noch nie. Selbst wenn, es würde dir nicht gelingen, es herauszufinden, denn es ist für Entwickler transparent.

In ES5 gibt es das bekannte Inkonsistenzen bei der Darstellung von Zeichen außerhalb des Basic Multilingual Plane, aber das hat mit der internen Repräsentation nichts notwendig zu tun.

In ES6 werden weitere Techniken spezifiziert, um String-Kodierung noch transparenter zu machen. Ein String ist dann eine Liste von Unicode-Zeichen. Ein solcher String hat keine inhärente Byte-Darstellung. Erst beim Speichern oder Übertragen sind Kodierungen interessant. Gut. Aber wann hast du dich das letzte Mal »in erster Linie« für die UTF-8-Sequenzen interessiert? Schreibst du Text und Code etwa im Hexeditor?

Mathias

[Der Martin]

Hi,

So wie mich bei Strings ja auch die Byte-für-Byte-Darstellung interessiert, und erst in zweiter Linie die Zeichen, die durch diese Codes dargestellt werden.
Sorry, aber das glaube ich dir nicht.

das sei dir überlassen.

Wann hast du dich das letzte Mal dafür interessiert, wie z.B. JavaScript-Engines deine Strings als Bytes speichern?

Wie Javascript das genau tut, hat mich noch nie interessiert, weil Javascript für mich insgesamt nicht wirklich interessant ist (will heißen: Ich schreibe sehr selten in JS). In PHP oder auch in C interessiere ich mich aber sehr wohl für diese Ebene - dafür nur peripher um die Darstellung als Zeichen. Dafür ist das Frontend zuständig. Aber gerade wegen dieser maschinennahen Denkweise möchte _ich_ auch im Frontend die Möglichkeit haben, die Rohdaten zu sehen, mit denen die Software arbeitet.

Aber wann hast du dich das letzte Mal »in erster Linie« für die UTF-8-Sequenzen interessiert?

Halt, halt! Nicht für "die UTF-8-Sequenzen", sondern für die Bytefolge, die einen String ausmacht, ohne deren genaue Bedeutung zu kennen. Und das habe ich, naja, nicht gerade täglich, aber häufig. Jedesmal, wenn ich in C oder Assembler mit Strings zu tun habe.

Schreibst du Text und Code etwa im Hexeditor?

Vereinzelt sogar das, ja. Und wenn der Hex-Dump nur ASCII-Zeichen darstellt, kann ich ihn fließend lesen.

Ciao,
 Martin

[molily]

Hallo,

In PHP oder auch in C interessiere ich mich aber sehr wohl für diese Ebene - dafür nur peripher um die Darstellung als Zeichen. Dafür ist das Frontend zuständig. Aber gerade wegen dieser maschinennahen Denkweise möchte _ich_ auch im Frontend die Möglichkeit haben, die Rohdaten zu sehen, mit denen die Software arbeitet.

Technisch gesehen ist ein PHP-String bloß eine Bytekette, aber eine PHP-Webanwendung interessiert sich in 95% der Fälle nicht für Bytes, sondern für Zeichen. Weil in PHP-Strings in den meisten Fällen natürlichsprachige Buchstaben, Wörter, Texte gespeichert werden. Eine vernünftige Anwendung nutzt daher eine Abstraktion wie mbstring.

Das Kodierungsproblem löst man üblicherweise dadurch, dass man überall UTF-8 verwendet, sodass man nicht ständig an (De-)Kodierung denken muss.

Alle sind sich einig, dass High-Level-Programmiersprachen native Unicode-Unterstützung haben sollten, sodass "ö".length bzw. strlen("ö") unabhängig von der internen Darstellung 1 ergibt. Bei PHP tut man sich nur schwer damit, das konsequent durchzuziehen, weil es 20 Jahre lang versäumt worden ist.

Wenn eine C-Anwendung natürlichsprachige Texte speichert und diese verarbeitet (z.B. dieses Forum hier), dann in den meisten Fällen zeichenbasiert. Wenn man da die Abstraktion vergisst, dann knallt es.

Kodierung ist gerade so ein Reizthema, weil man 50 Jahre lang »maschinennah« und nicht »menschennah« entwickelt hat. Viele höhere Programmiersprachen, Editoren, Protokolle und andere Tools sind deshalb falsch designt, und bei den Low-Level-Sprachen bedarf es besonderer Bibliotheken, um simpelste Unicode-Zeichenketten zu verarbeiten.

Mathias

[MudGuard]

Hi,

in der Adresszeile? - Du kannst den (kompletten!) Inhalt der Adresszeile in einen Texteditor kopieren

Texteditor wird nicht benötigt.
Klick in die Adreßleiste, Ctrl-A (alles selektieren), Ctrl-C, Ctrl-V
Und schon steht's mit %C3... in der Adreßleiste.

cu,
Andreas

[Gunnar Bittersmann]

@@MudGuard:

nuqneH

Klick in die Adreßleiste, Ctrl-A (alles selektieren), Ctrl-C, Ctrl-V
Und schon steht's mit %C3... in der Adreßleiste.

Interessant daran, dass Firefox das zwar bei Nicht-ASCII-Zeichen im Pfad so handhabt, nicht aber bei Nicht-ASCII-Zeichen im Host. Da wird im Firefox nicht Punycode draus, auch nicht beim Kopieren in ein Textdokument. Bei Chrome schon.

Qapla'

[Bobby]

Moin

Das Problem kommt erst beim Speichern der Ressource, z.B. auf Windows-Systemen.

Naja.. solange das dynamisch erzeugt ist, ist doch kein Problem. oder?

Und SEO-relevant ist es doch auch. Oder täusch ich mich da?

Gruß Bobby

[Der Martin]

Hallo,

Spricht etwas dagegen, in einer (sprechenden) URL Umlaute zu verwenden?

ja. Betrachte dabei bitte den Domain- oder Hostnamen und den lokalen Pfad getrennt.
Domains mit Nicht-ASCII-Zeichen, im Volksmund "Umlaut-Domains" genannt, etwas korrekter "IDN-Domains", sind seit einiger Zeit eingeführt. Dabei gilt die Darstellung mit Umlaut aber nur an der Schnittstelle zum Nutzer, während intern nach wie vor die Nur-ASCII-Darstellung verwendet wird. Die dabei verwendete Codierung nennt sich Punycode und ist festgelegt.

Umlaute im Domainnamen sind also grundsätzlich okay; ich würde aber aus Gründen der Abwärtskompatibilität immer einen entsprechenden umlaut-freien Domainnamen mit registrieren, wenn möglich.

Konkret geht es um: example.com/über-mich

Also den Local Part.

Gibt es aktuell trotzdem (zwingende) Gründe/ Argumente, auf Umlaute zu verzichten?

Ja: Es gibt keine feste Regelung, welche Zeichencodierung für die Nicht-ASCII-Zeichen verwendet werden soll. Du bist also von einer Reihe günstiger Voraussetzungen abhängig, damit das System funktioniert. Darüber hinaus gilt natürlich auf der technischen Ebene immer noch, dass Zeichen außerhalb des ASCII-Bereichs, sogar einige ASCII-Zeichen (z.B. Blank, das Prozentzeichen, das Pluszeichen), und natürlich Steuerzeichen URL-codiert werden müssen.

So long,
 Martin

[Gunther]

Hallo Martin!

Spricht etwas dagegen, in einer (sprechenden) URL Umlaute zu verwenden?

ja. Betrachte dabei bitte den Domain- oder Hostnamen und den lokalen Pfad getrennt.

Mach' ich Chef! ;-)

Domains mit Nicht-ASCII-Zeichen, im Volksmund "Umlaut-Domains" genannt, etwas korrekter "IDN-Domains", sind seit einiger Zeit eingeführt. Dabei gilt die Darstellung mit Umlaut aber nur an der Schnittstelle zum Nutzer, während intern nach wie vor die Nur-ASCII-Darstellung verwendet wird. Die dabei verwendete Codierung nennt sich Punycode und ist festgelegt.

Umlaute im Domainnamen sind also grundsätzlich okay; ich würde aber aus Gründen der Abwärtskompatibilität immer einen entsprechenden umlaut-freien Domainnamen mit registrieren, wenn möglich.

Schon klar ..., aber ich will keine Umlaut-Domain registrieren oder verwenden ....!
Eines der größten "Probleme" bei Umlaut-Domains tritt übrigens auf, wenn du sie auch als Mail-Adresse verwenden willst. ;-)

Konkret geht es um: example.com/über-mich

Also den Local Part.

Ja genau.

Gibt es aktuell trotzdem (zwingende) Gründe/ Argumente, auf Umlaute zu verzichten?

Ja: Es gibt keine feste Regelung, welche Zeichencodierung für die Nicht-ASCII-Zeichen verwendet werden soll. Du bist also von einer Reihe günstiger Voraussetzungen abhängig, damit das System funktioniert. Darüber hinaus gilt natürlich auf der technischen Ebene immer noch, dass Zeichen außerhalb des ASCII-Bereichs, sogar einige ASCII-Zeichen (z.B. Blank, das Prozentzeichen, das Pluszeichen), und natürlich Steuerzeichen URL-codiert werden müssen.

Ja, ist mir bekannt - siehe auch: http://de.wikipedia.org/wiki/URL-Encoding#Nicht-ASCII-Zeichen

Und du kennst einen aktuellen Browser, der nicht UTF-8 zur Zeichenkodierung annimmt/ benutzt?

Aber abgesehen davon verfügt mein Skript zusätzlich auch noch über eine Funktion, die die "richtige" Seite auch dann noch problemlos ermittelt, selbst wenn die Umlaute als "was weiß ich" kodiert ankommen.

Sonst noch irgendwelche Gründe? ;-)

Gruß Gunther

[Der Martin]

Hi,

Und du kennst einen aktuellen Browser, der nicht UTF-8 zur Zeichenkodierung annimmt/ benutzt?

zumindest der IE in der Defaulteinstellung:

[X] URLs immer in UTF-8 senden

muss man AFAIK erst explizit setzen (wobei ich nicht sicher bin, ob ich den Wortlaut richtig wiedergegeben habe). Firefox und Opera haben's als Default, soweit ich weiß, andere Browser nutze ich nicht regelmäßig.

Ciao,
 Martin

[molily]

zumindest der IE in der Defaulteinstellung:

[X] URLs immer in UTF-8 senden

muss man AFAIK erst explizit setzen

Nein, das ist standardmäßig aktiviert. Zumindest ab IE 8, ältere habe ich gerade nicht zur Hand.

Mathias

[Der Martin]

Hallo,

zumindest der IE in der Defaulteinstellung:

[X] URLs immer in UTF-8 senden

muss man AFAIK erst explizit setzen

Nein, das ist standardmäßig aktiviert. Zumindest ab IE 8, ältere habe ich gerade nicht zur Hand.

bei einem von der hausinternen IT frisch aufgesetzten PC mit Windows 7 und IE10, den ich bei einem Kunden nutzen darf, war das *nicht* gesetzt. Kann natürlich sein, dass das einer von den IT-Fuzzies, der den PC eingerichtet hat, bewusst abgewählt hat - allerdings fällt mir kein Grund ein, warum man das tun sollte. Ein firmeninternes Intranet, das evtl. besondere Einstellungen rechtfertigen könnte, gibt es dort nicht.

Und beim IE8, den ich letztes Jahr noch auf XP installiert habe, war das ebenfalls nicht aktiviert. Wobei letzteres natürlich rein technisch betrachtet ein Update von IE6 auf IE8 war. Möglich, dass dann die IE6-Standardeinstellung übernommen wird.

Ciao,
 Martin

[molily]

Ich habe hier die Virtual-Machines von http://modern.ie/, Version 8 bis 11. In allen ist die fragliche Einstellung aktiviert. Ich habe da nichts dran geändert. In IE 11 habe ich extra »Reset Internet Explorer settings« ausprobiert, was aber keine Änderung brachte (es ist immer noch angeschaltet).

Über andere Installationen kann ich gerade nichts sagen. Es würde mich aber wundern, wenn IE das global deaktiviert hat. Damit ist die vernünftige Internationalisierung von URLs unmöglich. IE verwendet dann Windows-1252 zur Kodierung, wie es mir scheint, was für das Gros der Weltbevölkerung nur Fehler produziert.

Mathias

[molily]

Es gibt keine feste Regelung, welche Zeichencodierung für die Nicht-ASCII-Zeichen verwendet werden soll.

Doch, UTF-8.
http://en.wikipedia.org/wiki/Internationalized_resource_identifier
http://tools.ietf.org/html/rfc3987

gilt natürlich … immer noch, dass Zeichen außerhalb des ASCII-Bereichs … codiert werden müssen.

Ja, z.B. http://example.com/%C3%BCber-mich

Mathias

[Gunther]

Hallo Mathias!

Es gibt keine feste Regelung, welche Zeichencodierung für die Nicht-ASCII-Zeichen verwendet werden soll.

Doch, UTF-8.
http://en.wikipedia.org/wiki/Internationalized_resource_identifier
http://tools.ietf.org/html/rfc3987

Sehe ich das jetzt richtig, dass wenn ich also anstatt eines URIs einen IRIs verwende, alles in Butter ist? ;-)

Gruß Gunther

[T-Rex]

Das erinnert mich an die Geschichte, dass die NASA für 1 Millionen Dollar einen Kugelschreiber entwickelt hat, der im Weltall nicht ausläuft. Die Russen haben einen Bleistift genommen.

Was ich sagen will ist die generelle Frage Wieso überhaupt?
Ich denke für jedes Wort im Deutschen mit Umlaut gibt es wunderbare Synonyme. Dein "über mich" ist sowieso eher Homepage Slang. Ein "dass bin ich" sagt zum einen mehr aus und zum anderen wäre es sogar noch ein korrekter deutscher Satz!?!
Wir leben im Land der Dichter und Denker.

Gruss
Sonderzeichen gehoren verboten
TRex

[Gunnar Bittersmann]

@@T-Rex:

nuqneH

Was ich sagen will ist die generelle Frage Wieso überhaupt?

Darum.

Ich denke für jedes Wort im Deutschen mit Umlaut gibt es wunderbare Synonyme. […]
Wir leben im Land der Dichter und Denker.

Denk mal über den beschränkten deutschen Horizont hinaus. Andere leben in Ländern, die gar keine lateinischen Zeichen verwenden.

“To many, ‘Hotmail.com’ might as well be Cyrillic.” (The Secret Messages Inside Chinese URLs)

Sonderzeichen gehoren verboten

Umlaute und andere Nicht-ASCII-Zeichen als „Sonderzeichen“ zu bezeichnen gehört verboten.

Qapla'

[T-Rex]

Denk mal über den beschränkten deutschen Horizont hinaus. Andere leben in Ländern, die gar keine lateinischen Zeichen verwenden.

Wer einen deutschen Text lesen möchte, der kann auch "deutsche" Zeichen benutzen.
Ich beschwer mich ja auch nicht, dass es anscheinend Webadressen mit chinesischen Schriftzeichen gibt, die ich nur mit Problemen erreiche.

Gruß
Sonderzeichen gehoren immer noch verboten
TRex

[MudGuard]

Hi,

Ein "dass bin ich" sagt zum einen mehr aus und zum anderen wäre es sogar noch ein korrekter deutscher Satz!?!

Wohl eher ??? als !?!

Ein korrekter deutscher Satz beginnt mit einem Großbuchstaben, endet mit einem Satzzeichen.
Und daß das dass da das sein muß, ist eh klar. *)

*) die Anführungszeizchen um das 4. und 6. Wort habe ich absichtlich weggelassen, die hätten nur das schöne Bild zerstört.

cu,
Andreas

[Linuchs]

Spricht etwas dagegen, in einer (sprechenden) URL Umlaute zu verwenden?

Ich vermeide das wie die Pest. Sogar in Bemerkungen im PHP-Quellcode. Je nachdem, in welchem Zeichensatz der Editor arbeitet, gibt's Probleme. Etwa die Meldung beim Laden sinngemäß: "Die Datei enthält undefinierte Zeichen. Trotzdem bearbeiten?"

Da denkt man erstmal an eine abgebrochene Datei oder ein eingebundenes Bild oder sonstige binäre Daten.

Neulich hatte ich eine URL "So schön wie der Norden.mp3" - Der mp3-Flash-Player weigerte sich, den Umlaut anzuerkennen. Nicht abspielbar mit diesem Player.

Und in meinem Mailprogramm sylpheed bricht ein Link nach einem "Sonderzeichen" ab, Seiten-URL mit Umlauten sind nicht erreichbar.

Linuchs