Должен ли я использовать символы с акцентом в URL-адресах?

Когда создается веб-контент на разных языках, чем английский, возникает проблема оптимизации поисковой системы и удобных для пользователя URL-адресов.

Мне интересно, лучше ли использовать буквы с акцентированными буквами в URL-адресах - рискуя, что некоторые слова имеют совершенно разные значения с определенными акцентами и без них, или лучше придерживаться использования не- английские символы, в случае необходимости жертвуя удобочитаемостью этих URL-адресов в менее сложных средах (например, MSIE, источник просмотра).

"Экзотические" буквы могут появляться в любом месте: в заголовках документов, в тегах, в именах пользователей и т.д., поэтому они не всегда находятся под полным контролем сопровождающего сайта.

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

Ответ 1

Когда вы столкнулись с аналогичной проблемой, я воспользовался переписыванием URL, чтобы позволить таким страницам быть доступными либо с акцентом, либо с безрезультатным символом. Фактический URL-адрес будет похож на

http://www.mysite.com/myresume.html

И функция переписывания + символа перевода позволяет эту ссылку

http://www.mysite.com/myresumé.html

для загрузки того же ресурса. Поэтому, чтобы ответить на ваш вопрос, как основной идентификатор ресурса, я ограничиваюсь 0-9, A-Z, a-z и случайным дефисом.

Ответ 2

Здесь нет двусмысленности: RFC3986 говорит нет, то есть URI не могут содержать символы Unicode, а только ASCII.

Совсем другое дело в том, как браузеры представляют кодированные символы при отображении URI, например, некоторые браузеры будут отображать пробел в URL вместо "%20". Так работает IDN: punycoded strings кодируются и декодируются браузерами "на лету", поэтому, если вы посетите café.com, вы действительно посещаете xn--caf-dma.com. То, что кажется символами юникода в URL-адресах, действительно является только "визуальным сахаром" со стороны браузера: если вы используете браузер, который не поддерживает IDN или юникод, закодированная версия не будет работать, потому что базовое определение URL-адресов просто не поддерживает его, поэтому, чтобы он работал последовательно, вам нужно закодировать%.

Ответ 3

Рассмотрение URL-адресов с акцентами часто имеет тенденцию выглядеть следующим образом:

http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant

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

Хотя, все должно стать лучше, поскольку акцентированные URL-адреса теперь принимаются веб-браузерами.

Firefox 3.5, который я использую в настоящее время, отображает URL-адрес с хорошим способом, а не с% stuff, btw; это кажется "новым", поскольку firefox 3.0 (см. Firefox 3: поддержка UTF-8 в панели местоположений); поэтому, вероятно, не поддерживается в IE 6, по крайней мере - и есть еще слишком много людей, которые используют этот: - (

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

Ответ 4

Вам следует избегать символов, отличных от ASCII, в URL-адресах, которые пользователи могут вводить вручную. Это нормально для встроенных ссылок, предварительно закодированных сервером.

Мы выяснили, что браузер может кодировать URL по-разному, и очень сложно понять, какую кодировку он использует. См. Мой вопрос по этой проблеме,

Обработка кодировки символов в URI на Tomcat

Ответ 5

В полном URL-адресе есть несколько областей, и каждый из них может иметь разные правила. Протокол является простым ASCII. Запись DNS регулируется правилами IDN (Международные доменные имена) и может содержать (большинство) символов Unicode. Путь (после первого /), имя пользователя и пароль снова могут быть всем. Они бегут (как% XX), но это просто байты. Какая кодировка этих байтов трудно понять (интерпретируется http-сервером). Часть параметров (после первого?) Передается "как есть" (после% XX unescapeing) для некоторых приложений на стороне сервера (php, asp, jsp, cgi) и как это интерпретирует байты - это другая история). Рекомендуется, чтобы аргументы path/user/password/были utf-8, но не обязательно, и не все это уважают.

Итак, вы должны определенно разрешить не-ASCII (мы не в 80-х годах), но именно то, что вы делаете с этим, может быть сложно. Попытайтесь использовать Unicode и избегайте устаревших кодовых страниц, поместите свой контент с соответствующей кодировкой/кодировкой, если сможете (используя мета в html, языковые директивы для asp/jsp и т.д.)