Diskussion:Punycode

Konverter

Ich habe den Konverter geaendert, da der urspruenglich verlinkte Probleme mit "undeutschen" Sonderzeichen hatte, d.h. aus mømø wurde nicht xn--mm-lkab, sondern nur xn--mm-! - Mømø 10:47, 28. Mai 2006 (CEST)

konvertieren

wie konvertiert man nun? wie genau wird aus einem ä ein irgendwas andres? das ist aus dem artikel nicht ersichtlich.

Unverständlichkeits-Baustein

Den habe ich gesetzt, da aus dem Artikel weder hervorgeht, wie genau nun Zeichen und Position kodiert werden (siehe Kommentar darüber), noch, was ein „adaptives Deltaverfahren“ ist. Und auch nicht, was genau mit der kodierten Zeichenkette dann gemacht wird. Traitor 15:44, 26. Dez. 2006 (CET)

Ich werde mich mal drüberstürzen (oder lieber drueberstuerzen?) -- Zaxx 18:11, 8. Feb. 2007 (CET)

Ist es so schon ausreichend? Ansonsten muss der ganze Algorithmus hier rein, der sich aber textuell nicht so einfach beschreiben lässt. -- Zaxx 11:22, 19. Feb. 2007 (CET)

Siehe englisches Wikipedia

Man könnte sonst das englische Wikipedia als Vorlage benutzen. Dort steht das ganze Verfahren beschrieben. --Seto 14:47, 14. Mär. 2007 (CET)

Punycode ist etwas Anderes als IDNA

Seit dem Edit 22:36, 10. Feb. 2007 stehen im Artikel fehlerhafte Angaben zur Bildung von Punycode.

1. Der ACE Präfix "xn--" gehört zu IDNA und nicht zu Punycode. Vergleiche die beiden RFCs 3490 (IDNA) und 3492 (Punycode für IDNA).
2. Der ACE Präfix enthält immer zwei Minuszeichen. Der Punycode-String wird also nicht bei nichtvorhandenen Basiszeichen mit einem Minus an "xn-" angehängt. Das legen aber die derzeitige falsche Beschreibung plus Beispiel sehr nahe.
3. An einen String aus nur Basiszeichen wird ein Trennzeichen "-" als Ende angehängt. Nicht bei IDNA, da erledigt diese Kennzeichnung der (in diesem Fall nichtvorhandene) Präfix.

Mir ist bewusst, dass meine Änderungen (vor allem 3.) erst einmal bei vielen Kopfkratzen oder gar Kopfschütteln hervorrufen werden, aber eine genaue Interpretation des RFC 3492, speziell Abschnitt 6.3, führt zu diesen Erkenntnissen. --83.236.181.13 20:42, 21. Mär. 2007 (CET)

Überschneidung mit Internationalizing Domain Names in Applications

Der Artikel überschneidet sich in weiten inhaltichen Teilen mit Internationalizing Domain Names in Applications (so z.B. die Browserumsetzung sowie das Verfahren an sich). Ich will zwar keinen Redundanztext-Bapperl setzen, aber nötig wärs. --Benji 21:35, 6. Mai 2007 (CEST)

Redundanz mit Internationalizing Domain Names in Applications

Dort ist ein Redundanztext eingeblendet, hier jedoch nicht mehr. Ich bin mir nicht sicher, ob der Redundanzhinweis noch gerechtfertigt ist oder nicht, die Liste unterstützender Browser ist jedoch beispielsweise in beiden Artikeln vorhanden. --Karl, 137.226.102.159 02:42, 18. Mai 2010 (CEST)

Liste hier entfernt, die Browser machen noch etwas mehr als nur Punycode. --Matthäus Wander 18:02, 2. Nov. 2012 (CET)

Unverständlich

Vlt. bin ich ja einfach zu dumm, aber was passiert denn wirklich beim Umsetzen per Punycode? "sondern nach dem Punycode-Verfahren kodiert." - Und was ist das Punycode-Verfahren?

"Die Nicht-Basiszeichen werden zuerst nach ihrem Zahlenwert sortiert." - Was für ein Zahlenwert? Fällt der vom Himmel? Unicode-Zahlenwert?

Und so weiter. Was passiert, damit aus "schön" der gezeigte codierte String wird, und was geschieht konkret bei der Rückwandlung? Der Verweis auf RFC löst das Problem nicht, dann brauchen wir keine Wikipedia. MichaelL2008 (Diskussion) 16:48, 11. Mai 2013 (CEST)

Ist mir ebenfalls nicht verständlich, trotz lesen des RFC. Vielleicht kann das Verfahren anhand des Beispiels "schön ➞ schn-7qa" durchexerziert werden? --Jkcg7 (Diskussion) 13:13, 11. Jul. 2013 (CEST)

Wie sieht das mit ASCII-Zeichen außerhalb von a-z,A-Z,0-9,- aus?

Also was passiert z.B. mit : ! ? ^ usw.? --RokerHRO (Diskussion) 13:17, 26. Jan. 2018 (CET)

warum nicht %xx

Warum wird das nicht einheitlich und einfach wie eine URL mit Sonderzeichen codiert: also www.Müller.de = www.M%C3%BCller.de (oder sollte das am %-Zeichen scheitern)? --2.247.255.140 17:08, 22. Jul. 2018 (CEST)

Das steht alles im Artikel im Abschnitt "Gründe der Einführung":

1. Weil % in Domainamen nicht erlaubt sind.
2. Weil die kodierten Namen damit deutlich länger werden würden. Es sind pro Namensbestandteil (also jeweils zwischen den Punkten) nur max. 63 Zeichen erlaubt. (Dieses Limit anzuheben hätte Updates in sämtlichen DNS-Servern und vor allem -Clients bedeutet. Das hätte Jahrzehnte gedauert, wenn es überhaupt machbar gewesen wäre.) Und mit deinem Vorschlag (selbst wenn das % erlaubt gewesen wäre) wären z.B. im Russischen nur noch max. 10 Zeichen pro Domain erlaubt gewesen. Eine Domain wie http://санкт-петербург.рф/ für St. Petersburg wäre so nicht möglich gewesen, denn der Name der Stadt wäre zu %D1%81%D0%B0%D0%BD%D0%BA%D1%82-%D0%BF%D0%B5%D1%82%D0%B5%D1%80%D0%B1%D1%83%D1%80%D0%B3 geworden, was mit 85 Zeichen deutlich zu lang ist. Mit Punycode ist es viel kompakter: http://xn----7sbeiia6axumbcqds.xn--p1ai/

--RokerHRO (Diskussion) 09:52, 26. Jul. 2018 (CEST)

Name

Woher kommt Puny in Punycode? Steht im Artikel nirgends, könnte aber problemlos in einem Nebensatz zu Beginn erwähnt werden. Ich persönlich weiß es nämlich nicht. — Spezialist • Disk 20:53, 14. Aug. 2019 (CEST)

Wiktionarys englischer Eintrag für Punycode enthält den Hinweise, die Etyologie sei eine Verschmelzung von engl. puny(winzig) und Unicode. dafür ist dort allerdings kein Beleg angegeben. Ich habe beim ursprgl. Autor angefragt. --Nomentz (Diskussion) 20:28, 10. Dez. 2019 (CET)