hossa42: Umlaut im Link wird richtig angezeigt aber falsch ausgegeben

Hallo Forumsmitglieder.

Mein Problem stellt sich wie folgt da:
Ich habe eine vorgefertigte Seite ein wenig angepasst und möchte noch eine Kontaktseite dazu bauen:

http://www.lohnbuchhaltung-köln.de/kontakt/index.php

Wenn man dann unten auf "Senden" drückt, kommt entweder eine Fehlerseite oder eben eine Danke Seite. Solange ich keine Umlaute benutze ist das auch alles kein Problem.
Die Daten werden an ein vorgefertigtes PHP-Scipt übergeben und das wertet die Daten dann aus.

Aus dem im Quelltext angegebenen :

http://www.lohnbuchhaltung-köln.de/kontakt/fehler.php
macht er dann ja ein
http://www.lohnbuchhaltung-k%F6ln.de/kontakt/fehler.php

Jetzt habe ich hier ein wenig in den Archiven gesucht und begriffen das ich den Link Codiert schreiben muss.

Mein Link sieht jetzt wie folgt aus:
http://www.lohnbuchhaltung-k%C3%B6ln.de/kontakt/fehler.php
Und siehe da : Er wir richtig angezeigt ... zumindest in der Adresszeile.

Der Haken an der Sache ist aber, das er den Link dann nicht aufmacht und folgende Meldung ausgibt :
"Der Server unter www.lohnbuchhaltung-k%c3%b6ln.de konnte nicht gefunden werden."

Wenn ich dann aber den Link in der Addresszeile bestätige, geht er auf?!?

Wenn Ihr mit Firefox auf den oben angegebenen Link klickt, könnt Ihr es selbst sehen. Der IE zeigt es gar nicht an ...

Kann mir jemand einen Tip geben, warum er die Bestätigunsseiten richtig anzeigt aber nicht aufmacht?

Gruss Marcus

  1. @@hossa42:

    nuqneH

    http://www.lohnbuchhaltung-k%C3%B6ln.de/kontakt/fehler.php

    Nicht-ASCII-Zeichen in Domainnamen werden nicht prozent-escapet, sondern per Punycode.

    Qapla'

    --
    Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
    (Mark Twain)
  2. Hallo,

    http://www.lohnbuchhaltung-köln.de/kontakt/index.php

    oh - eine Umlaut-Domain. Das ist nicht gut.

    Die Daten werden an ein vorgefertigtes PHP-Scipt übergeben und das wertet die Daten dann aus.

    Und dieses Script -also das eigentliche Formularziel- liegt auf einer anderen Domain ohne Umlaut?

    Aus dem im Quelltext angegebenen :
    http://www.lohnbuchhaltung-köln.de/kontakt/fehler.php
    macht er dann ja ein
    http://www.lohnbuchhaltung-k%F6ln.de/kontakt/fehler.php

    Wer ist "er"?
    Und nein, diese Umwandlung ist falsch. In Domainnamen kann kein Umlaut vorkommen. Umlaute in Domainnamen sind etwas, das uns unsere Browser nur vorgaukeln. In Wirklichkeit codieren sie solche Domainnamen nämlich sofort um, bevor sie sie nach außen geben: Punycode.

    Jetzt habe ich hier ein wenig in den Archiven gesucht und begriffen das ich den Link Codiert schreiben muss.

    Ja. Aber nicht URL-codiert, sondern Punycode-codiert.

    http://www.lohnbuchhaltung-k%C3%B6ln.de/kontakt/fehler.php
    "Der Server unter www.lohnbuchhaltung-k%c3%b6ln.de konnte nicht gefunden werden."

    Klar.

    Wenn ich dann aber den Link in der Addresszeile bestätige, geht er auf?!?

    Dann wird die Adresseingabe erneut interpretiert und korrekt in Punycode übersetzt.

    Wenn Ihr mit Firefox auf den oben angegebenen Link klickt, könnt Ihr es selbst sehen. Der IE zeigt es gar nicht an ...

    Welcher IE? IE6? Ab IE7 sind AFAIK auch bei Microsoft Umlautdomains angekommen. Für IE6 gab's mal einen Patch zum Nachrüsten.

    So long,
     Martin

    --
    Der Bäcker schlägt die Fliegen tot
    Und macht daraus Rosinenbrot.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. @@Der Martin:

      nuqneH

      http://www.lohnbuchhaltung-köln.de/kontakt/index.php

      oh - eine Umlaut-Domain. Das ist nicht gut.

      Natürlich ist das gut. Die Beschränkung des Zeichensatzes auf ASCII sollte dem letzten Jahrtausend vorbehalten bleiben. In IRIs dürfen sogar auch andere als lateinische Buchstaben vorkommen, auch im Domainnamen.

      Was nicht gut ist, ist Software, die damit nicht klarkommt.

      Qapla'

      --
      Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
      (Mark Twain)
      1. Was nicht gut ist, ist Software, die damit nicht klarkommt.

        Du meinst Software wie bereits zum 6. Mal versucht, das Internet zum Explodieren zu bringen?

      2. Hallo,

        http://www.lohnbuchhaltung-köln.de/kontakt/index.php
        oh - eine Umlaut-Domain. Das ist nicht gut.
        Natürlich ist das gut. [...]
        Was nicht gut ist, ist Software, die damit nicht klarkommt.

        bei den Browsern ist IDN inzwischen angekommen. Bei den Mailclients ist das AFAIK immer noch ein ganz wundes Thema. Wie es bei anderen Anwendungen aussieht, weiß ich nicht.

        So long,
         Martin

        --
        Warum können wir heute so sicher sagen, dass Gott keine Frau sein kann?
        Weil dann nach "Es werde Licht" der nächste Satz "Wie sieht denn das hier aus?!" gewesen wäre.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. @@Der Martin:

          nuqneH

          bei den Browsern ist IDN inzwischen angekommen.

          Nicht überall. Bei <input type="email"/> nicht.

          Allerdings steht da auch Unsinn in der HTML5-Spec. Warum wundert mich das nicht?

          Qapla'

          --
          Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
          (Mark Twain)
          1. Allerdings steht da auch Unsinn in der HTML5-Spec. Warum wundert mich das nicht?

            Du meinst, dass anstatt RFC 5322 3.4.1 auf Abschnitt 3.2.3 verwiesen wird?

            1. @@suit:

              nuqneH

              Du meinst, dass anstatt RFC 5322 3.4.1 auf Abschnitt 3.2.3 verwiesen wird?

              Nein, atext ist ja in §3.2.3 beschrieben. Das Problem ist, dass die HTML5-Spec überhaupt auf RFC 5322 bzw. RFC 1034 verweist.

              Welche Zeichen im Mailprotokoll erlaubt sind (und wie der Escaping-Mechanismus funktioniert), ist dem Nutzer einer Webseite sowas von egal. Den Nutzer interessiert das UI. Er will die gültige(!) E-Mail-Adresse джон.доу@россия.рф in ein Eingabefeld eingeben können.

              Browser müssen ihm dies erlauben. Und die HTML5-Spec muss es Browsern erlauben, ihm dies zu erlauben. Die HTML5-Spec beschreibt an der Stelle das Verhalten des UI. Klarer Fall von I18n-Fail.

              Qapla'

              --
              Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
              (Mark Twain)
              1. Browser müssen ihm dies erlauben. Und die HTML5-Spec muss es Browsern erlauben, ihm dies zu erlauben. Die HTML5-Spec beschreibt an der Stelle das Verhalten des UI. Klarer Fall von I18n-Fail.

                Jetzt verstehe ich was du meinst, das ist natürlich richtig.

                Generell ist aber problematisch dass HTML5 in manchen stellen als Markup-Sprache das UI-Verhalten bestimmen darf. Das neue autofocus-Attribut ist z.B. potentiell gefährlich, da die Markupsprache aktives Verhalten bestimmen kann obwohl z.B. Scriptsprachen abgeschaltet sind.

                Übrigens ist in diesem Abschnitt die Beschreibung des placeholder-Attributs nicht konform zu RFC 2606 - damn you Hixie :D

              2. Mahlzeit Gunnar Bittersmann,

                Er will die gültige(!) E-Mail-Adresse джон.доу@россия.рф in ein Eingabefeld eingeben können.

                Gültig?

                Nach RFC2822 kommen als "local part" lediglich folgende Alternativen in Frage:

                • "dot-atom" [ entspricht den Zeichen: a-zA-Z0-9.!#$%&'*+-/=?^_`{|}~ ]

                • "quoted-string" [ entspricht den Zeichen mit den ASCII-Codes 33, 35-91 und 93-126, eingeschlossen von doppelten Anführungszeichen (") ]

                • "obs-local-part" [ entspricht einem oder mehrere durch einen "." verbundene "word" (= "atom" {d.h. eines der bei "dot-atom" erlaubten Zeichen} oder "quoted-string") ]

                (Bei Wikipedia ist das verständlicher formuliert beschrieben.)

                Auf keinen Fall jedoch sind Zeichen mit einem ASCII-Code > 127 erlaubt. Leider.

                Oder gibt es mittlerweile neuere RFCs, die 2822 ablösen?

                MfG,
                EKKi

                --
                sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
    2. Vielen lieben Dank für den Punycode-Hinweis, damit funktioniert es.

      Habe einen Konverter dafür gefunden :
      http://www.dcomnet.com/idn_domain_umlautdomain_konvertieren_umwandeln_convert_punycode.html

      Er hat aus
      http://www.lohnbuchhaltung-köln.de/kontakt/danke.php
      http://xn--lohnbuchhaltung-kln-66b.de/kontakt/danke.php
      gemacht.

      Grüsse