Ускоряющая клавиша n предназначена для пропусков при навигации по страницам. Пропуск для перехода на начало контента.
Данный документ является переводом. В случае каких-либо несоответствий и ошибок последняя версия документа на английском языке должна рассматриваться в качестве официальной. Первоначальное авторское право принадлежит W3C, как то указано ниже.
Переводчик: World translation - онлайн переводчик (Александр Шлапак)
Предполагаемая аудитория: авторы контента, менеджеры Веб проектов, и обычные пользователи, которые хотят получить краткий обзор, не вдаваясь в технические детали, того, что происходит за кулисами, когда они используют отличные от ASCII символы в веб адресах. В данной статье рассматриваются как IDN (Интернационализированные Доменные Имена) так и IRIs (интернационализированные идентификаторы ресурсов), и то, как они работают вместе.
Веб адрес используется для указания на такой ресурс в Интернете, как Веб страницу. Последние разработки позволяют добавлять в Веб адреса не-ASCII символы. Эта статья предоставляет обширное представление того, как это работает. Она направлена на авторов контента и обычных пользователей, которые хотят понять основы, без многих технических деталей. Для простоты мы будем использовать примеры, основанные на HTML и HTTP. Также мы будем рассматривать, как это работает для доменного имени и для остальной части пути в Сети.
В настоящее время веб-адреса, как правило, выражаются с помощью Универсальных идентификаторов ресурсов или URIs. Синтаксис URI определен в RFC 3986 STD 66 (Универсальный идентификатор ресурса (URI): Общий Синтаксис) существенно ограничивает веб-адрес небольшим количеством символов: в основном, только Английские буквы верхнего и нижнего регистра , Европейские цифры и небольшое количество символов.
Первопричиной для этого было, обеспечить удобство использования как в компьютерных системах так и в некомпьютерных коммуникациях, для того, чтобы избежать появления символов, которые обычно используются в качестве разделителей возле URI, и для облегчения ввода, используя те возможности ввода, которые доступны для большинства пользователей Интернета.
С тех пор надежды пользователя и использование Интернета сдвинулись с места и в настоящее время растет потребность разрешить использование в веб-адресах символов с любого языка. Веб-адрес на вашем родном языке и алфавите легче создать, запомнить, записать, интерпретировать, угадать, и пересказать. Это также важно для узнаваемости бренда. Это, в свою очередь, лучше для бизнеса, лучше для нахождения, и лучше для общения. Короче говоря, лучше для сети Интернет.
Например, представьте себе, что все веб-адреса должны быть написаны на Японской Катакане, как показано в следующем примере. Если вы не японец, то подумайте легко было бы для вас распознать контент или владельца сайта, ввести адрес в браузере, написать URI в записной книжке и т.д.?
Были внедрены несколько разработок, которые в последнее время начинают делать это возможным.
Мы будем ссылаться на веб-адреса, которые позволяют использовать символы различных скриптов, такие как Интернационализированные Идентификаторы Ресурсов или IRIs. Есть четыре основных требования, чтобы IRIs работали:
Различные форматы документов и спецификации уже поддерживают IRIs. Примеры включают в себя HTML 4.0, XML 1.0 идентификаторы системы, XLink атрибут href, XMLSchema тип данных anyURI, и т.д. Позже мы также увидим, что основные браузеры уже поддерживают использование IRIs.
К сожалению, не так много протоколов позволяют IRIs проходить без изменений. Как правило, они требуют, чтобы адрес был указан с помощью ASCII-символов, определенных для URIs. Однако, также есть способы для обхода этой проблемы, и в этой статье мы будем их кратко описывать.
Для четвертого требования необходимо чтобы строка символов сопоставлялася с целью: и определить эти символы что представлены той же кодировкой, то есть байтами, или какими-то другими. Это решается с помощью UTF-8 в качестве посредника.
В большинстве примеров на этой странице мы будем использовать следующий фиктивный веб-адрес:
Это просто IRI, который состоит из трех частей.
http:// содержит информацию о схеме, которая будет использоваться. Обратите внимание, что не-ASCII
символы в настоящее время здесь не используются.JP納豆.例.jp, это доменное имя.Когда дело доходит до требований: от двух и более четырех, то есть одно решение для доменного имени и другое решение для пути. Мы исследуем каждое из них по очереди.
Доменные имена, которые бронируются и управляются организациями доменного имени распространились по всему миру.
Стандартный подход к работе с многоязычными доменными именами был согласован IETF в марте 2003. Он определен в RFCs, 3490, 3491, 3492 и 3454, и базируется на основе Unicode 3.2. Некоторые обращаются к этому используя термин Интернационализированное Доменное Имя или IDN.
Регистратор домена устанавливает список символов, которые люди могут использовать в их стране или в доменах верхнего уровня. Однако, когда человек делает запрос на регистрацию доменного имени используя эти символы, то в действительности она бронирует эквивалент доменного имени используя отображение, которое называется punycode.
Punycode это способ отображения кодов Unicode используя только ASCII символы.
В следующем разделе мы приведем более детальный рабочий пример, но подытожим: желаемый веб-адрес хранится в документе, что ссылается или вводится в адресной строке клиента, используя соответствующие родные символы, но, когда пользователь нажимает на ссылку или иным образом инициирует запрос, то клиентскому приложению (т.е. браузер или другой клиент, что запрашивает ресурс) необходимо преобразовать любые родные символы скрипта в Веб-адресе в punycode отображения.
(Конечно, если клиентское приложение не в состоянии это сделать, то всегда есть возможность отобразить расположение непосредственно в punycode, хотя это не очень удобно.)
Давайте рассмотрим шаги урегулирования Международного Доменного Имени от пользователя к идентификации ресурса. (Помните, что это рассматривается только с точки того, как обрабатывается доменное имя. Информация о пути трактуется по-разному и будет описана ниже).
Пользователь нажимает на ссылку или вводит IRI в адресную строку клиентского приложения. На данный момент IRI содержит не-ASCII символы, которые могут быть в любой кодировке. Вот доменное имя, которое появляется в вышеприведенном примере.
JP納豆.例.jp
Если строка, представляющая доменное имя закодированная не в Unicode, то клиентское приложение преобразует строку в Unicode. Затем клиентское приложение применяет к строке некоторые функции нормализации, чтобы устранить определенные двусмысленности, которые могут быть в закодированном в Unicode тексте.
Нормализация включает в себя такие вещи, как преобразование символов верхнего регистра в нижний регистр, сокращение альтернативных отображений (например, преобразование Кана с полуширины в полный размер), исключение запрещенных символов (например, пробелы), и т.д.
Затем клиентское приложение превращает каждую из меток (т.е. фрагменты текста между точками) в Unicode строку в punycode отображения.
Специальный маркер ('xn--') добавляется в начале каждой отметки, содержащей не-ASCII символы, чтобы показать, что отметка с самого начала не была
ASCII. Конечный результат не очень удобный, но точно представляет начальную строку символов, используя только
символы, которые ранее были разрешены для доменных имен. Наш пример теперь выглядит следующим образом:
xn--jp-cd2fp15c.xn--fsq.jp
Обратите внимание, как большие ASCII-символы 'JP' в начале доменного имени записаны в нижнем регистре, но по-прежнему их можно узнать. Все существующие ASCII символы в отметке появляются первыми, а за ними следуюет один дефис и основаное на ASCII отображение любых не-ASCII символов.
Далее с помощью сервера доменного имени урегульовуеться punycode в числовой IP адрес (урегульовуеться как и любое другое доменное имя).
Наконец, клиентское приложение отправляет запрос на страницу. Поскольку punycode не содержит символов, которые обычно разрешены для таких протоколов, как HTTP, то нет проблем с передачей адреса. Это должно просто совпадать с зарегистрированным доменным именем.
Заметим, что большинство кодов стран верхнего уровня, например, .jp в конце JP納豆.例.jp, как и раньше должны быть написаны латинскими буквами. Однако, с 2010 года IANA постепенного внедрили интернационализированный код страны для таких доменов верхнего уровня, как مصر. для Египта, и .рф для России.
На практике, есть смысл зарегистрировать два имени для вашего домена. Одно на своем родном скрипте, и одно, используя только обычные ASCII символы. Последний будет более запоминающимся и простым в написании для людей, не умеющих читать и писать на вашем языке. Например, вы могли бы дополнительно зарегистрировать транскрипцию Японского на Латинском скрипте, например, как описано далее:
http://JPnatto.rei.jp/В то время как администрация по регистрации домена может согласиться принять доменные имена в исключительной форме и кодировке (punycode на основе ASCII), мульти-скрипт имена пути определяет ресурсы, расположенные на многих видах платформ, чьи файловые системы используют и будут продолжать использовать различные кодировки. Это гораздо более затрудняет обработку пути, чем доменного имени.
Разобравшись с доменным именем, которое использует punycode, теперь нам придется иметь дело с частью IRI, содержащей путь. Предложенный стандарт IETF RFC 3987 (Международные Идентификаторы Ресурсов (IRIs)) определяет, как с этим справиться.
В спецификации URI уже есть механизм для представления не-ASCII символов в URIs. Что вы делаете - представляете байты, которые лежат в основе используя то, что называют 'percent-escaping' (тем не менее в спецификации используется похожее определение 'percent-encoding' ). Таким образом, имя файла страницы, которую вы сейчас читаете, что закодирована в UTF-8 мы могли бы представить как 引き割り.html из нашего предыдущего примера, показано сразу после этого пункта. Что вы видите - это двузначные шестнадцатеричные числа, которым предшествует %. Они представляют байты, которые используются для кодирования в UTF-8 Японских символов в строке. Каждый Японский символ представлен 3-мя байтами, которые превращаются в три percent-escapes.
%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html
Кроме того, это не очень удобно, здесь есть большая проблема. Другой человек может захочет пройти по той же ссылке со страницы, которая использует кодировку Shift-JIS, а не UTF-8. В этом случае, если бы мы использовали percent-escaping для преобразования (тех самых) символов в адресе так, чтобы они соответствовали требованиям URI, мы будем размещать экранированные символы на байтах, которые представляют 引き割り.html в кодировке Shift-JIS. В кодировке Shift-JIS есть только два байта для каждого Японского символа, и они отличаются от байтов, используемых в UTF-8. Таким образом, это дало бы совсем другую последовательность экранированных байт, что и показано ниже.
%88%F8%82%AB%8A%84%82%E8.html
Итак, мы здесь видим, что, хотя и экранированный механизм URI позволяет указывать Японский адрес но фактический результат будет изменяться в соответствии с начальной страницей. Как же тогда можно узнать, как это отразить на последовательности символов, которая будет совпадать с именем ресурса и предоставляется системой, в которой она находится?
Главная сложность здесь заключается в том, что нет никаких meta данных, относящихся к кодировке связанных с URI строками, и как результат - не возможно определить, какие символы они представляют. Даже если бы эта информация была доступна, то общее количество отображений, которые потребуются серверу для того, чтобы превратить любую входящую строку в соответствующее кодирование будет чрезвычайно высокой.
Не только это, но и файловая система, на которой находится сам ресурс фактически может раскрывать имя файла с помощью совершенно другого кодирования, такого как EUC-JP. Если это так, то основная последовательность байтов, представляющая имя файла в качестве системного знает, что это имя опять же будет отличаться. Так как же мы будем знать, что эти последовательности байтов все ссылаются на один и тот же ресурс?
Спецификация IRI использует Unicode в качестве посредника. Она указывает, что до превращения в экранированные символы, IRI должны быть преобразованы в UTF-8. Что же касается IDNs, то если преобразование требуется протоколом, то это есть клиентское приложение, которое отвечает за выполнение этого изменения, когда делается запрос ресурса.
Сервер должен также распознавать символы Unicode во входном веб-адресе, и отобразить их в кодировке, которая используется для текущих ресурсов.
(Помните, что мы уже имели дело с той частью доменного имени IRI, использующей IDN. Правила в спецификации IRI обычно применяются только к той части многоязычной Веб адреса, что содержит путь.)
Давайте рассмотрим то, что делает клиент для того, чтобы отправить ту часть веб-адреса, которая содержит путь на сервер HTTP. Вот часть Адреса вышеприведенного примера:
/dir1/引き割り.htmlКогда пользователь нажимает на ссылку или входит IRI в адресную строку клиентского приложения, то адрес может быть в любой кодировке символов, но кодировка, как правило, известна.
Если строка вводится пользователем или хранится в не-Unicode кодировке, то она превратится в Unicode, нормализованный использует Unicode Normalization Form C (Unicode Форму нормализации) и закодирован использует UTF-8 кодировку.
Клиентское приложение затем превращает не-ASCII байты в percent-escapes. Наш пример теперь выглядит следующим образом:
/dir1/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.htmlТеперь строка находится в URI форме, и она будет приемлемой для таких протоколов, как HTTP. Обратите внимание, как ASCII символы 'dir1' и '.html' остаются без изменений, поскольку эти символы кодируются так же, как ASCII и UTF-8.
Клиентское приложение запрашивает страницу.
При этом, когда запрос попадает на сервер то, должно произойти одно из двух:
Это включает в себя основы. Есть некоторые дополнительные части спецификации, которые занимаются тонкостями, например, как обращаться с двунаправленным текста в IRIs, и т.д..
Вот первая часть HTTP заголовка для запроса страницы, что созданный нашим примером. Это показывает, имя хоста, как IDN, и в случае необходимости путь использует percent-escaping:
GET /dir1/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html HTTP/1.1 Host: xn--jp-cd2fp15c.xn--fsq.jp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 …
Многочисленные администраторы доменного имени уже предлагают регистрацию интернационализированных доменных имен. К ним относятся домены таких стран, как: .cn, .jp, .kr, и т.д., и такие глобальные домены верхнего уровня, как: .info, .org и .museum.
Клиентская поддержка IDN появится в последних версиях основных браузеров, включая Internet Explorer 7, Firefox, Mozilla, Netscape, Opera, и Safari. Сейчас она работает только в Internet Explorer 6, если вы загружаете плагин (Страницы поддержки Microsoft предоставляют некоторые предложения). Это означает, что вы можете использовать IDNs в значениях атрибута href или в адресной строке, и браузер преобразует IDN в punycode и будет искать host (ресурс).
Вы можете запустить основную проверку того или IDNs работают в системе с помощью этого простого теста.
До сих пор то, что Internet Explorer с его огромной долей рынка изначально не поддерживал IDN было проблемой. Хотя плагины и доступны, но не все люди будут знать, не все захотят, не все смогут их установить. Тем не менее, IE7 и его преемники, которые поддерживают IDN, со временем заменят большинство установок IE6.
Отметим, что в качестве простого резервного решения пока IDN широко поддерживается, авторы контента, которые хотят указать на ресурс используя IDN могут написать текст ссылки родными символами, и поместить punycode отображения к атрибуту href. Это гарантирует, что пользователи смогут перейти на ресурс, независимо от платформы, что они использовали.
Если по какой-то причине вы хотите отключить поддержку IDN в IE7, Firefox и Mozilla, то это возможно.
Одна из проблем, связанных с IDN поддержкой в браузерах - то что она может способствовать фишингу через так называемые 'homograph attacks' (омографические атаки). Итак, большинство браузеров, поддерживающих IDN также ввели некоторые меры безопасности для защиты пользователей от такого мошенничества.
То, как браузеры обычно предупреждают пользователя о возможной омографической атаке - это отображение URI в адресной строке, а статусная строка использует punycode, а не оригинале символы Unicode. Поэтому пользователи должны всегда проверять адресную строку после загрузки страницы, или статусную строку, прежде чем нажать на ссылку. Однако заметим:
Различные браузеры используют различные стратегии для того, чтобы определить как следует показывать URI: в Unicode или в punycode.
Если адрес появляется как punycode, то это не обязательно означает, что это фиктивный сайт - просто 'пользователь берегись'. Это зависит от пользователя - попробовать зайти на сайт и выяснить, следует ли его избегать или нет.
Выявление потенциальных омографических атак, как правило, является только одной частью общего механизма, что использует браузер для определения, является ли сайт фишинговым или нет.
Internet Explorer 7 показывает адрес как punycode, если выполняется одно из следующих условий:
Доменное имя содержит символы из скрипта, который не используется для языков, которые включены к языкам, которые пользователь предпочитает. Языки, которые используют Латинский скрипт делятся на Английский (только ASCII) и другие (для которых доступен любой не-ASCII Латинский символ). Например, bäcker.com не будет работать, если ваши языковые предпочтения включают только Английский язык, но будет работать, если у вас есть Немецкий язык в ваших языковых предпочтениях (или даже, скажем, Французский язык, так акцентированные символы не относятся к конкретному языку).
Любые отметки в доменном имени (т.е. изменение символов между точками) содержат символы из смеси скриптов, которые не появляются вместе в рамках одного языка. Например, доменное имя ελληνικάрyccĸий.org будет отображаться в виде punycode, потому что греческие символы нельзя смешивать с Кириллицей в одной метке. С другой стороны с ελληνικά.рyccĸий.org все будет в порядке. Отметим также, что комбинация Японских кандзи и кана также приемлемая, например 全国温泉ガイド.jp.
IE7 позволяет отображать IDN как Unicode если он смешивает ASCII символы с одним из скриптов с данного списка. Обратите внимание, что Кириллица не является одним из этих скриптов, поэтому pаypаl.com (где 'a' являются символами из блока Кириллицы, а не Латинского скрипта) будет отображаться как punycode.
Привязывание поведения к списку языков в настройках вашего браузера также означает, что речь, которая не входит в стандартный список предоставленный IE будет показываться в punycode. Например, Амхарский язык в Эфиопском тексте будет отображаться в виде punycode даже если вы добавите am до языковых предпочтений браузера. (К счастью, похоже, что в настоящее время не будет каких-то реестров которые будут предоставлять амхарский IDN).
Некоторые мошеннические доменные имена все еще могут проскочить эту сеть. В этом случае должна вмешаться нормальная защита от фишинга, чтобы сравнить домен сайтами о, которых сообщили. Однако, IE7 также может 'применять дополнительные эвристики, чтобы определить, является ли доменное имя визуально неоднозначным'. Это полезно, когда в том же скрипте есть визуально похожие буквы.
В дополнение для отображения подозрительных IDNs в адресной строке в punycode, IE7 также использует свою информационную панель, чтобы сигнализировать пользователю о возможной опасности. Он также использует кликабельную иконку в конце адресной строки, чтобы уведомить вас о том, что URL содержит не-ASCII символы. Он также отражает адресную строку во всех окнах.
Firefox 2.x использует другой подход. Он отражает в Unicode только некоторые доменные имена верхнего уровня, находящиеся в белом списке. Firefox выбирает домены верхнего уровня (TLDs), которые в доменном имени имеют установленные политики безопасности, что они разрешаются для регистрации, а потом полагаются на процесс регистрации для создания безопасных IDNs. Вы можете найти список поддерживаемых TLDs на сайте Mozilla. Если IDN из TLD , которых нет в списке, то веб-адрес появится в форме punycode, как в статусной строке так и в строке адреса. В некоторых случаях политика TLD должна включать правила управления визуально похожими символами в наборе разрешенных символов.
Кроме того, IDNs которые содержат конкретные символы (например fraction-slash (слэш)), даже в пределах проверенных TLDs, рассматриваются с подозрением, и приводят к тому, что метки отображаться как punycode.
Opera 9.x использует аналогичный подход как Firefox, хотя он и несколько отличается в реализации. По официальной версии, браузер отображает в Unicode только доменные имена из белого списка TLDs, которые перечислены в файле opera6.ini, который обновляется автоматически.
Для TLDs которые не включены в список, Opera позволяет для доменных имен использовать Latin 1 символы, например Латинские символы с ударением, что поддерживается Западноевропейскими языками. Все другие доменные имена отображаются в виде punycode.
На самом деле, исследования показывают, что Opera в настоящее время отображает много символов, как Unicode, независимо от того, TLD входит в белый список или нет. Мы обнаружили единственное исключение - скрипт Деванагари, который отображается в виде punycode, если TLD не входит в список.
Тем не менее, Opera также отображает определенные смеси скриптов, как punycode. Тестирование показало, что это верно для сочетания греческих символов или символов Кириллицы с Латинскими символами.
Также список недопустимых символов Opera немного длиннее, чем официальный список IDNA. В то время, как некоторые IDNs отображаются, как punycode в других браузерах, в Opera они полностью запрещены.
Safari 9.x предоставляет пользователю список скриптов, с возможностью редактирования, что изначально разрешены для отображения в доменных именах. Если символ появляется в имени домена и не входит в скрипт из этого списка, то URI отображается как punycode.
На момент написания статьи, начальный белый список содержал следующие скрипты: Арабский, Армянский, Бопомофо, Канадских аборигенов, Деванагари, Дезеретський, Гуджарати, Гурмукх, Хангыль, Хан, Иврит, Хирагана, Катакана или Хирагана, Катакана, Латинский, Тамильский, Тайский, а также Йи. Такие скрипты, как Кириллица, Чероки и Греческий специально исключены, поскольку они содержат символы, которые легко спутать с латинскими символами.
Если белый список пуст, то любой не-ASCII символ приводит к тому, что адрес будет отображаться в виде punycode.
Mozilla 1.7x отражает все IDNs как punycode.
Примеры. Есть тестовая страница, которую вы можете использовать для того, чтобы увидеть как в статусной строке браузер отображает IDNs. Смотрите также страницу, которая собирает результаты для целого ряда браузеров.
Другие проблемы фишингу и решаются на уровне реестра. Некоторые потенциальные аспекты фишинг-контроля должны быть решены регистрирующими органами, и эти органы должны включить это в свою политику по регистрации IDN.
Некоторые регистрирующие органы должны тщательно обсудить вопрос, как управлять эквивалентными способами написания одного и того же слова. Например, слово 'hindi' может быть написано на Деванагари или как हिंदी (используя Анусвару) или как हिन्दी (с помощью специального глифа для NA).
Есть аналогичная проблема с использованием упрощенных и традиционных символов в Китайском скрипте Хан.
Еще одна проблема возникает, когда в одном скрипте есть очень похожие два символа или комбинации символов, например, Тамильская буква KA க и Тамильская цифра один ௧ не отличаются. В других случаях, при небольших размерах шрифта может быть трудно различить диакритические знаки, которые присоединяются к символам .
С другой стороны, единому реестру, возможно, придется иметь дело с подобным и с потенциально запутанными символами в разных скриптах. Например, Тамильский и Малаялам - это два разных индийских скрипта, которые оба могут быть обработаны тем самым реестром, и Тамильская буква KA க (U+0B95) очень похожа на Малаяламськую букву KA ക (U+0D15). Другим примером могут служить последствия регистрации метки ера (использующей только Кириллические символы) или epa (использующей только латинские символы) для такого TLD как .museum что имеет дело с несколькими скриптами. Это может привести к значительной путанице, если более чем один заявитель смог зарегистрировать их отдельно.
В некоторых случаях эти сценарии могут быть записаны в виде правил, которые могут применяться клиентскими приложениями для обнаружения фишинга, но такие проблемы зачастую лучше всего решаются в момент регистрации.
Один подход на уровне регистрации должен решить, какие символы (т.е. точки Unicode) в данном языке будут разрешены в течение регистрации. Эти списки называются языковыми таблицами и они разработаны реестрами в сотрудничестве с квалифицированными администраторами языка. Например, Индийские администраторы языка могут разрешить использование Тамильской буквы KA க (U+0B95) но не Тамильской цифры один ௧ (U+0BE7) в доменных именах .in, что позволит избежать конфликтов.
Другой подход на уровне регистрации - создать таблицы вариаций и вариационные возможности регистрации. Эти таблицы вариаций показывают, какие символы визуально считаются запутанными в выбранных языках или скриптах. Если доменное имя содержит такой символ, то версия доменного имени, содержащая альтернативный символ будет автоматически зарезервирована для регистрации. Например, если доменное имя ( “primary domain”) содержит Тамильскую букву KA க (U+0BE7), система регистрации может генерировать вариант доменного имени, подставляя Малаяламськую букву KA ക (U+0D15) на место Тамильской буквы KA. Все обнаруженные варианты могут быть автоматически запрещены (для регистрации или создания), как часть пакета, который связан с первично зарегистрированным именем.
Консорциум Unicode также разрабатывает технический отчет Рассуждения Безопасности Unicode который описывает вопросы, связанные с подменами IDN и дает рекомендации по их решению.
Процесс превращения тех частей IRI, которые связаны с путем уже с самого начала поддерживается в последних версиях IE7, Firefox, Opera, Safari и Google Chrome.
Он работает в Internet Explorer 6 если включена опция Tools>Internet Options>Advanced>Always send URLs as UTF-8 (Инструменты>Настройка Интернета>Расширенные>Всегда отправлять URLs как UTF-8). Это означает, что ссылка в HTML или адреса, введенные в адресной строке браузера будут преобразованы правильно в тех клиентских приложениях. Это не работает в Firefox 2 (хотя вы можете получить результаты, если IRI и название ресурса закодированы в том же кодировке), но технически осведомленные пользователи могут включить опцию для поддержки этого (установить network.standard-url.encode-utf8, как true в about:config).
Однако, находится ли ресурс на сервере или нет, это уже другой вопрос. Если файловая система находится в UTF-8, то проблемы не должно быть. Если нет, и к тому же еще и нет механизма для преобразовывать адреса с UTF-8 в соответствующее кодировку, то запрос потерпит неудачу.
Такие серверы, как IIS и Apache 2 на Windows и Mac OS X, как правило, показывают файлы как UTF-8. Пользователи Unix и Linux могут хранить имена файлов в UTF-8, или использовать модуль mod_fileiri, который упоминался ранее. 1-я версия Apache сервера еще не показывает имена файлов в UTF-8.
Вы можете запустить основную проверку для того, чтобы узнать работает ли это для вашего клиента или ресурса используя этот простой тест.
Отметим, что в то время как основы могут работать, есть и другие немного более сложные аспекты поддержки IRI, такие как обработка двунаправленного текста в Арабской языке или Иврите, что, возможно, потребует дополнительного времени для полного осуществления.
Есть некоторые улучшения, необходимые для спецификации IDN и IRIs, и они в настоящее время обсуждаются. Например, есть необходимость расширить диапазон Unicode символов, которые можно использовать в доменных именах, чтобы покрыть более поздние версии Unicode, а также разрешить сочетание символов в конце меток в скриптах, которые выравниваются справа налево.
Выскажите своё мнение (по-английски).
Перевод с английского: 2008-05-09. Последнее внесение изменений в перевод: 2012-07-09 19:00 GMT
Для просмотра истории внесения изменений нажмите article-idn-and-iri в блоге i18n.
Copyright © 2005-2012 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
@webi18n
Новости главной страницы