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

Question

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

Примеры š ž č

Некоторые ссылки запускаются из Flash с помощью 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.Что происходит, когда появляется пользователь, у которого не установлена ​​поддержка этих персонажей?Понятия не имею, но я бы не хотел рисковать и делать большую часть моего сайта недоступной для большей части компьютеров по всему миру...

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

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

Answer 2

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

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

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

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

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

Канонически, РФК 2616.Однако на практике это несколько бесполезно.Критический отрывок:

Слова *TEXT МОГУТ содержать символы из наборов символов, отличных от 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 небезопасно!Не то чтобы это дало бы вам «ш» в любом случае...

Answer 3

Эти символы должны быть допустимыми в URL-адресе.Я занимался SEO-оптимизацией URL-адресов на большом туристическом сайте и именно тогда узнал об этом.Когда вы переводите диакритические знаки в ASCII, вы можете изменить значение слов, если не будете осторожны.Перевода часто нет, поскольку диакритические знаки существуют только в их контексте.