использование нелатинских символов в URL - PullRequest
1 голос
/ 10 февраля 2009

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

Примеры š ž č

Некоторые ссылки запускаются из Flash с использованием getURL, некоторые являются стандартными ссылками HTML. Некоторые из них являются программными Response.Redirects, а некоторые путем добавления 301 кодов состояния и заголовков местоположений в ответ. Я тестирую в IE6, IE7 и Firefox 3 и время от времени браузеры отображают кодировку URL нелатинских символов.

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

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

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

Спасибо

Ответы [ 3 ]

4 голосов
/ 10 февраля 2009

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

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

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

2 голосов
/ 10 февраля 2009

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

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

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

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

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

Канонически, RFC 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! Не то чтобы это все равно дало бы тебе ...

0 голосов
/ 10 февраля 2009

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

...