Съдържание
- Въведение
- Как работят многоезичните имена на области
- Регистриране на многоезични имена
- Примери от света
- Препратки по темата
Въведение
До скоро имената на области в Интернет можеха да съдържат само подмножество от 7-битови ASCII символи. С широкото разпространение на международната компютърна мрежа, сред хора и държави използващи различни езици и писмености става все по-ясно, че задължаването им да използват подмножество на латинската азбука за имена на области и сървъри не е приемливо. Така се ражда инициативата за създаване на възможност за използване на буквите от всички азбуки в имената на Интернет области. Тази инициатива носи името Многоезични имена на Интернет области (МИИО) или на английски „Internationalized Domain Name (IDN)”.
Повечето от европейските езици използват за своя писменост основната латинска азбука с включени допълнителни ударени букви. Доскоро те не можеха да се използват за имена на области в Интернет. Същото важеше и за всички останали езици (сред тях и българския), чиито писмености въобще не се основават на латинската азбука. Хората говорещи тези езици, нямаха възможност да използват привичните им имена на техния естествен език за имена на области и сървъри.
През последните няколко години се наблюдава изключително раздвижване на дейностите в IETF за стандартизиране на правилата за поддръжката на не-ASCII букви и символи в имената на интернет области. През Март 2003 г. IETF одобри три важни документа. Това са RFC 3490, RFC 3491 и RFC3492. Тези нови стандарти правят възможно регистраторите на интeрнет области да записват не-ASCII имена, както и разработчиците на приложения да разработят уеднаквена поддръжка в своите програми.
Как работят многоезичните имена на области
Когато програма за работа с Интернет срещне име на мрежово място, като http://www.bgit.net, тя изпраща заявка (обикновенно до услуга на операционната система) за откриване на IP адреса съответстващ на даденото име. Заявката от своя страна се препраща към съответния мрежов сървър на имена за да се получи желания адрес. Така намерения IP адрес след това се използва от програмата за свързване към въпросното мрежово място.
Новите стандарти позволяват имената на области и сървъри да съдържат не-ASCII знаци, които да се въвеждат от потребителя в адресното поле на съответната програма или да се използват, като адреси на препратки в мрежовите страници. Знаците, които могат да се използват за многоезични имена на области са определени в RFC 3490. Това са всички знаци, съществуващи в единния стандарт за кодиране „Unicode” издание 3.2 (в този текст ще го наричам „единен код”). В RFC 3490 е определено и как приложенията да обработват не-ASCII знаци, така че да се спазят съществуващите ограничения за имена на области.
Новите стандарти не променаят нищо на нивото на мрежовия протокол. На това ниво, няма отпадане на ограниченито за използване на подмножество от латинската азбука. Ако потребителят въведете не-ASCII знаци, като част от името на мрежова област или ако препратка съдържа такива, приложението трябва да преобразува подобен адрес в специален кодиран формат, който използва само ASCII знаци.
Това преобразуване става на няколко стъпки:
Подготовка на името
Когато дадено приложение получи нелатинско име, като вход от потребителя в адресната лента или от мрежова препратка, то първо трябва да го преобразува в единен код и да го нормализира, така че да отговаря на общите изисквания за URI.
При този процес се заместват главните букви с малки, уеднаквяват се знаците с възможни различни представяния (напр. преобразуване на японските кана-символи с половин ширина в такива с пълна ширина (нормализация)), изключват се забранените символи (напр. интервали), изключва се двусмислеността при двупосочни писмености (напр. Арабски и Иврид), и се проверява дали не са използвани знаци от неприсвоените части на единния код.
Тези действия за предварително подготвяне на името на английски се обозначават с термина „Nameprep”. Правилата за тяхното извършване са описани в RFC 3491 и RFC 3454.
ASCII-съвместимо прекодиране (АСП)
Следващата стъпка е да се пробразуват знаците от единен в 7-битов код, който използва само ограничения ASCII набор. По време на обсъжданията на новите протоколи възникват няколко конкуриращи се схеми за ASCII-съвместимо кодиране. Постигната е договореност за стандартизиране на схема наречена „Punycode”. Тя е описана в RFC 3492.
Добавяне на представка
Крайната стъпка на обработката е добавянето на пуникод представката към получения след АСП изходен низ. Тъй като пуникода съдържа само ASCII символи, е възможно, макар и не много вроятно, получения низ да съвпада със съществуващо име на област. За да се избегне това, е разработен RFC 3490. В него е определена нарочна представка „xn--” за изходния пуникод Другите типове прекодиране, използват различни представки. Например „bq--” за RACE, но всички с изключение на тази за пуникод вече са забранени за употреба при многоезични имена.
Всички многоезични имена на области ще започват с представката „xn--”. Тъй като немногоезични имена, които започват с тази представка могат да объркат потребителите, тя няма да бъде позволена за тях.
Пример
Изходният низ, който ще се изпрати до DNS сървър за българското име на област http://линукс.bg/
, в пуникод е
http://xn--h1aebjvk.bg
.
Регистриране на многоезични имена
След приемането на техническите стандарти от IETF, последната оставаща стъпка бе регистраторите на имена в Интернет да договорят правила при употребата на МИИО. Това е постигнато на среща, проведена в Рио Де Жанейро през Март 2003 година. През Юни правилата са публикувани на страницата на ICANN под името „Guidelines for the Implementation of Internationalized Domain Names”.
Правилата позволяват регистраторите на имена във всяка държава да ограничават употребяваните от тях букви и знаци в имената на области. Това е направено, тъй като единният код съдържа символи, които не се използват в живите езици, както и защото съществуват знаци в някои езици, които не са подходящи за имена. Така се дава право на регистраторите да наложат подходящите ограничения върху използването на съответните букви и знаци.
С отстраняването на това последно препятствие се очаква регистраторите на имена възможно най-бързо да придвижат реализацията на новите стандарти и да започнат регистрирането на многоезични имена на области
Японският регистратор JPRS (Japan Registry Service) вече обяви, че от 10 Юли 2003 г. прилага новите стандарти при записването на имена в областта за Япония „.jp”.
Примери от света
Вече съществуват истински многоезични имена, които можете да проверите. За целта ще ви трябва достатъчно съвременна програма, като Мозила 1.4 или Netscape 7.1. Чрез тях препратките от следващите страници могат да се ползват без никакви допълнителни настройки:
- Oбласти с допълнителните букви използвани в европейските езици
- Области на шведски
- Oбласти на японски (и страницата е на японски :-))
Очаква се данните за регистрираните многоезични имена да бъдат прехвърлени към пуникод до края на 2003 годима. Накои държави ще направят това по-бързо - като Япония. Но на други, включително и на основните домейни .com и .net ще им трява повече време.
Това е така, защото те в момента използват различно ASCII-съвместимо прекодиране. То се нарича RACE, но не бе прието от IETF. Ако намерите тестови не-ASCII области завършващи на .com или .net, и не успявате да ги посетите нормално, може да направите следното за да ги видите в Мозила 1.4 или Netscape 7.1:
- Напишете about:config в адресната лента. Това ще Ви покаже списък с всички настройки на текущия профил. Тези настройки могат да се променят или да се създават нови, без да е необходимо да напускате разглеждача.
- Добавете нов низ, като използвате контекстното меню New > String (Добавяне > Низ). Името трябва да бъде network.IDN_prefix, а стойността трябва да е „bq--”. Това ще промени подразбираното АСП от пуникод на RACE.
- Добавете двочина стойност, като използвате New > Boolean (Добавяне > Двоично). Нейното име трябва да е network.IDN_testbed, а стойностт трябва да е „true”.
- Сега посетете многоезичните области в .com и .net. Трябва да успеете да видите тестовите места.
- Не забравяйте да промените стойността на добавените настройки на „default”, след като приключите с пробите!