с использованием нелатинских символов в URL-адресе

Question

Я работаю над сайтом, который клиент перевел на хорватский и словенский языки. В соответствии с нашими существующими шаблонами URL мы создали правила перезаписи URL-адресов, которые имитируют макет приложения, что привело к тому, что в URL-адресах было много атрибутов, отличных от ascii.

Примеры š ž č

Некоторые ссылки вызываются из флэш-памяти с использованием GetURL, некоторые стандартные HTML ссылки. Некоторые из них являются программными Response.Redirects и некоторые, добавив к ответу 301 статусных кодов и заголовков местоположений. Я тестирую в IE6, IE7 и Firefox 3 и периодически, браузеры отображают не-латинские символы url, закодированные.

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

Я предполагаю, что это что-то делать с IIS и, как она обрабатывает Response.Redirect и AddHeader ("Location ...

Кто-нибудь знает способ понуждения IIS не URL закодировать эти символы или мой лучший выбор, чтобы заменить их без диакритических символов?

Благодаря

Answer 1

Спросите себя, если вы действительно хотите, чтобы они не были закодированы. Что происходит, когда пользователь, у которого нет поддержки для этих персонажей, появляется? Я понятия не имею, но я бы не хотел рисковать сделать большие части моего сайта недоступными для большой части компьютеров в мире ...

Вместо этого сосредоточьтесь на , почему вам нужна эта функция. Является ли это, чтобы URL-адреса выглядели хорошо? Если это так, использование обычного z вместо ž будет очень хорошим. Используете ли вы URL-адреса для ввода пользователем? Если это так, url-encode все, прежде чем разбирать его, чтобы связать вывод, и url-декодировать его перед использованием ввода. Но не используйте ž и другие локальные буквы в URL-адресах ...

В качестве примечания, в Швеции у нас есть å, ä и ö, но никто никогда их не использует в URL-адресах - мы используем a, a и o , потому что браузеры не будут поддерживать ссылки в противном случае. Это не удивляет пользователей, и очень немногие не могут понять, к каким словам мы стремимся, потому что в URL отсутствует символ в å. Текст будет отображаться правильно на странице, верно? ;)

Answer 2

эти символы должны быть действительны в URL. Я сделал URL SEO материал на большой туристический сайт и что, когда я узнал, что. Когда вы вынуждаете диакритику к ascii, вы можете chan ge смысл слов, если вы не будете осторожны. Часто нет перевода, поскольку диакритика существует только в их контексте.

Answer 3

Кто-нибудь знает способ понуждения IIS не URL кодирования

Вы должны URL-кодирование. Передача необработанного «š» (\ xC5 \ xA1) в HTTP-заголовке недействительна. Браузер может исправить ошибку до «% C5% A1» для вас, но если это так, результат не будет отличаться, если вы только что написали «% C5% A1».

В том числе необработанное «š» в ссылке не так, браузер должен кодировать его в UTF-8 и URL-кодирование в соответствии с спецификацией IRI. Но чтобы убедиться, что это действительно работает, вы должны убедиться, что страница со ссылкой включена в кодировку UTF-8. Опять же, ручное кодирование URL-адресов, вероятно, безопасно.

У меня не было проблем с URL-адресами UTF-8, можете ли вы ссылаться на пример, который не работает?

У вас есть ссылка на ссылку, где она содержит сведения о том, что содержит допустимый HTTP-заголовок?

Canonical, RFC 2616. Однако на практике это несколько бесполезно. Критический пассаж:

Слова * Текст может содержать символы из наборов символов, кроме ISO-8859-1 только тогда, когда кодируется в соответствии с правилами RFC 2047.

Проблема заключается в том, что в соответствии к правилам RFC 2047, только «атомы» могут вмещать 2047 «закодированное слово». ТЕКСТ, в большинстве случаев он включен в HTTP, не может быть изобретен как атом. В любом случае RFC 2047 явно разработан для форматов RFC 822, и хотя HTTP очень похож на формат 822, он на самом деле не совместим; он имеет свою основную грамматику с тонкими, но значительными различиями. Ссылка на RFC 2047 в спецификации HTTP не дает никакого представления о том, как можно было бы интерпретировать ее каким-либо образом, и, насколько я знаю, может возникнуть ошибка.

В любом случае фактический браузер не пытается найти способ интерпретации кодировки RFC 2047 в любом месте своей обработки HTTP. И хотя байты, отличные от ASCII, определены RFC 2616 в ISO-8859-1, в действительности браузеры могут использовать ряд других кодировок (таких как UTF-8, или независимо от системного кодирования по умолчанию) в разных местах при обработке HTTP заголовки. Поэтому небезопасно полагаться даже на набор символов 8859-1! Не то, чтобы это дало вам «š» во всяком случае ...