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

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

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

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

Кто-нибудь знает способ заставить 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. TEXT, в большинстве случаев включенный в HTTP, не может быть атомом. В любом случае, RFC 2047 явно разработан для форматов семейства RFC 822, и хотя HTTP очень похож на формат 822, на самом деле он несовместим; он имеет свою собственную базовую грамматику с тонкими, но существенными отличиями. Ссылка на RFC 2047 в спецификации HTTP не дает никакого представления о том, как можно было бы интерпретировать его каким-либо непротиворечивым образом, и, насколько мне известно, является ошибкой.

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

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