Прискорююча кнопка 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 18: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
Новини головної сторінки