en utilisant des caractères non latins dans une URL

Question

Je travaille sur un site que le client a eu traduit en croate et slovène. Conformément à nos modèles d'URL existants, nous avons généré des règles de réécriture d'URL qui imitent la mise en page de l'application qui a conduit à avoir beaucoup charachters non-ascii dans les URL.

Exemples š Zc

Quelques liens sont déclenchés à partir de Flash en utilisant getURL, certains sont des liens HTML standard. Certains sont Response.Redirects et certains par programmatiques en ajoutant 301 codes d'état et les en-têtes de l'emplacement à la réponse. Je teste dans IE6, IE7 et Firefox 3 et internitmtently, les navigateurs affichent les caractères non-latin URL encodée.

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

Je devine que c'est quelque chose à voir avec IIS et la façon dont il gère Response.Redirect et AddHeader ( "Location ...

Quelqu'un sait-il d'une façon de forcer IIS à encode pas ces URL ou est mon caractère meilleur pari pour les remplacer par des caractères non-diacritiques?

Merci

Answer 1

Demandez-vous si vous vraiment les veulent non url codée. Qu'est-ce qui se passe lorsqu'un utilisateur qui ne prend pas en charge pour les personnages installés vient autour? Je ne sais pas, mais je ne voudrais pas risquer de faire une grande partie de mon site indisponible pour une grande partie des ordinateurs du monde ...

Au lieu de cela, se concentrer sur pourquoi vous avez besoin de cette fonction. Est-ce pour rendre les urls belle apparence? Si oui, en utilisant un z régulier au lieu de ž fera très bien. Utilisez-vous les urls pour l'entrée utilisateur? Si oui, tout-encode url avant l'analyse syntaxique pour relier la sortie et l'URL-decode avant d'utiliser l'entrée. Mais ne pas utiliser d'autres lettres et ž locales urls ...

Comme une note de côté, en Suède, nous avons å, A et O, mais personne ne les utilise jamais dans urls - nous utilisons, a et o, car les navigateurs ne supporteront pas les urls autrement. Cela ne surprend pas les utilisateurs, et très peu sont incapables de comprendre ce que les mots que nous visons simplement parce que la bague en å manque dans l'url. Le texte affichera toujours correctement sur la page, à droite? ;)

Answer 2

  

Quelqu'un sait-il d'une façon de forcer IIS à ne pas encode URL

Vous devez encode. Le passage d'une crue « S » (\ XC5 \ XA1) dans un en-tête HTTP est invalide. Un navigateur peut corriger l'erreur à « % C5% A1 » pour vous, mais si ce résultat ne sera pas différent de si vous venez d'écrire « % C5% A1 » en premier lieu.

Y compris un «de cru dans un lien ne se trompe pas en tant que tel, le navigateur est censé coder en UTF-8 et URL-encode selon la spécification IRI. Mais pour que cela fonctionne réellement vous devez vous assurer que la page avec le lien est servi en UTF-8 codé. Encore une fois, URL-encodage est probablement plus sûr manuel.

J'ai eu aucun problème avec UTF-8 URL, vous pouvez créer un lien vers un exemple qui ne fonctionne pas?

  

Avez-vous un lien vers une référence où il détaille ce qui comprend un en-tête HTTP valide?

canoniquement, RFC 2616 . Cependant, dans la pratique, il est un peu inutile. Le passage critique est:

  

mots de texte de * peut contenir des caractères à partir de jeux de caractères autres que ISO-8859-1 uniquement lorsque codée selon les règles de la RFC 2047.

Le problème est que, selon les règles de la RFC 2047, seuls les atomes « » peuvent accueillir 2047 « mot codé ». TEXTE, dans la plupart des cas, il est inclus dans HTTP, ne peut pas être moyen d'être un atome. Quoi qu'il en soit RFC 2047 est explicitement conçu pour les formats RFC 822-famille, et bien que HTTP ressemble beaucoup un format 822, il est en réalité compatible; il a sa propre grammaire de base avec des différences subtiles mais importantes. La référence à la RFC 2047 dans la spécification HTTP ne donne aucune idée de la façon dont on pourrait être en mesure de l'interpréter d'une façon cohérente et est, pour autant que tous ceux que je connais peut travailler, une erreur.

Dans tous les cas, aucun navigateur réel tente de trouver un moyen d'interpréter la RFC 2047 encodage partout dans sa gestion HTTP. Et tandis que les octets non-ASCII sont définis par le RFC 2616 pour être dans la norme ISO-8859-1, dans les navigateurs de réalité peuvent utiliser un certain nombre d'autres encodages (par exemple UTF-8, ou quel que soit le codage par défaut du système est) en divers endroits lors de la manipulation HTTP les en-têtes. Il est donc sûr de ne pas compter même sur le jeu de caractères 8859-1! Non pas que cela aurait donné vous de toute façon ...

Answer 3

Ces caractères doivent être valides dans une URL. Je l'ai fait les choses SEO URL sur un grand site Voyage et c'est quand j'ai appris. Lorsque vous forcez diacritiques à ascii vous pouvez changer le sens des mots si vous ne faites pas attention. Il n'y a souvent pas de traduction comme diacritiques n'existent que dans leur contexte.