Frage

Ich arbeite an einer Stelle, die der Kunde in der kroatischen und slowenischen übersetzt hatte. Im Einklang mit unserem bestehenden URL-Muster haben wir URL Umschreiben Regeln erzeugt, die das Layout der Anwendung zu imitieren, die viele nicht-ascii charachters zu haben, in dem URLs führen hat.

Beispiele š zc

Einige Links aus dem Flash ausgelöst GetURL, sind einige Standard-HTML-Links. Einige sind programatic Response.Redirects und einige durch Hinzufügen von 301 Statuscodes und Standort-Header der Antwort. Ich teste in IE6, IE7 und Firefox 3 und internitmtently zeigt der Browser der nicht-lateinischen Zeichen URL-kodiert.

š = %c5%a1
ž = %c5%be
č = %c4%8d

Ich vermute, dies ist etwas, mit IIS und wie sie behandelt Response.Redirect und AddHeader ( "Location ...

zu tun

Kennt jemand eine Möglichkeit, von IIS nicht URL kodieren diese Zeichen zu zwingen oder ist meine beste Wette diese mit nicht-diakritischen Zeichen ersetzen?

Danke

War es hilfreich?

Lösung

Fragen Sie sich, wenn Sie wirklich wollen, dass sie nicht-URL codiert. Was passiert, wenn ein Benutzer, der nicht die Unterstützung für diese Zeichen nicht haben rund installiert kommt? Ich habe keine Ahnung, aber ich würde nicht machen große Teile von meiner Seite nicht zur Verfügung zu einem großen Teil der weltweit Computer riskieren will ...

Stattdessen konzentrieren sich auf Warum Sie diese Funktion benötigen. Ist es zu machen, die Urls schön aussehen? Wenn ja, wird mit einem normalen z statt ž ganz gut tun. Haben Sie die URLs für die Benutzereingabe verwenden? Wenn ja, URL-kodieren alles vor Parsen es Ausgang zu verbinden, und URL-dekodieren, bevor die Eingabe. Aber nicht ž und andere lokale Buchstaben in Urls verwenden ...

Als Randbemerkung, in Schweden wir å, ä und ö, aber niemand nutzt sie in Urls - wir verwenden ein, a und o, da Browser die URLs nicht anders unterstützen wird. Dies schließt nicht die Benutzer überraschen, und nur sehr wenige sind nicht in der Lage zu verstehen, welche Worte wir gerade sind mit dem Ziel, weil der Ring in einem in der URL fehlt. Der Text zeigt noch richtig auf der Seite, nicht wahr? ;)

Andere Tipps

  

Kennt jemand eine Möglichkeit, von IIS nicht URL kodieren zwingen

Sie müssen URL-Codierung. ein rohes 'S'(\ XC5 \ xA1) in einem HTTP-Header Pass ist ungültig. Ein Browser kann den Fehler beheben bis zu ‚% C5% A1‘ für Sie, aber wenn so wird das Ergebnis nicht anders sein, wenn Sie hatte gerade an erster Stelle ‚% C5% A1‘ geschrieben.

in einem Link ein rohes 'S'Einschließlich als solche nicht falsch ist, wird der Browser soll es auf UTF-8 kodieren und URL-kodieren gemäß der IRI spec. Aber um sicherzustellen, dass dies tatsächlich funktioniert, sollten Sie sicherstellen, dass die Seite mit dem Link in serviert als UTF-8 codiert. Auch manuelle URL-Codierung ist wahrscheinlich am sichersten.

Ich habe keine Probleme mit UTF-8 URLs habe, können Sie sich auf ein Beispiel verknüpfen, die nicht funktionieren?

  

Möchten Sie einen Link zu einer Referenz, wo es Details, was einen gültigen HTTP-Header umfasst?

kanonisch, RFC 2616 . In der Praxis jedoch ist es etwas wenig hilfreich. Die kritische Stelle ist:

  

Worte von * TEXT-Zeichen enthalten können von anderen Zeichen setzen als ISO-8859-1 nur dann, wenn nach den Regeln von RFC 2047 codiert wird.

Das Problem besteht darin, dass nach den Regeln der RFC 2047 nur ‚Atome‘ können ein 2047 ‚codiertes Wort‘ aufzunehmen. TEXT, in den meisten Fällen wird es in HTTP enthalten ist, kann nicht ersonnen werden, ein Atom zu sein. Wie dem auch sei RFC 2047 ist explizit die für RFC 822-Familie Formate, und obwohl HTTP viel wie ein 822-Format sieht, ist es in der Realität nicht kompatibel; es hat seine eigene Basisgrammatik mit subtilen, aber deutlichen Unterschieden. Der Verweis auf RFC 2047 in der HTTP-Spezifikation gibt keinen Anhaltspunkt dafür, wie man vielleicht in der Lage in irgendeiner konsistenten Weise zu interpretieren und ist, soweit man weiß ich kann trainieren, ein Fehler.

Auf jeden Fall keine tatsächliche Browser versucht, einen Weg zu finden, RFC 2047 Codierung überall in seiner HTTP Handhabung zu interpretieren. Und während Nicht-ASCII-Bytes wird durch RFC 2616 definiert in ISO-8859-1 zu sein, in Wirklichkeit Browser eine Reihe von anderen Kodierungen verwenden kann (wie UTF-8, oder was auch immer das System Standard-Kodierung ist) an verschiedenen Orten, wenn HTTP Handling Header. So ist es nicht sicher, auch auf dem 8859-1-Zeichensatz verlassen! Nicht, dass das würde Sie 'S'gegeben hat sowieso ...

Diese Zeichen sollten in einer URL gültig sein. Ich habe die URL SEO Sachen auf einer großen Reise-Website und das ist, wenn ich das gelernt. Wenn Sie diakritische Zeichen zu erzwingen ascii können Sie die Bedeutung der Wörter ändern, wenn du nicht aufpasst. Es ist oft keine Übersetzung als diakritische Zeichen nur in ihrem Kontext existieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top