Страница 32: ДСТУ 4249:2003. Інформаційні технології. Настанова щодо POSІX-сумісних середовищ відкритих систем (POSІX-OSE) (61118)

Інтернаціоналізація як перехресна категорія служб POSIX-OSE охоплює всі служби POSIX-OSE. Хоча варіанти Еталонних моделей в опублікованих технічних статтях використовували для ві­дображення проблем інтернаціоналізації, служби інтернаціоналізації, описані в цьому розділі, від­повідають Еталонної моделі OSE.

POSIX-OSE повинна забезпечувати служби різних рівнів: загальні служби, що задовольняють потреби будь-якої програми; служби АРІ, що будуть задоволені в АРІ для спеціальних програм; та набір інструментарію для локалізації систем та застосування. У цьому підрозділі докладно обгово­рені ці служби. Під час дослідження служб корисно провести розбіжності між службами, необхід­ними для мобільності прикладної платформи в межах культурних границь, та службами, необхід­ними для мобільності прикладних програм у відношенні одного чи більше наборів культурних угод, можливо, підтримуваних на одиночній прикладній платформі.

• наборів символів та подання даних;

• культурних угод;

• підтримування природної мови.

5.1.4.1.1 Набори символів та подання даних. Набір символів англійської мови задають ISO 646:1991 та використовують семибітне кодування для унікального ідентифікування кожного з 95 доступних символів. Крім англійської мови, для мов Європи та Америки число локальних символів на­багато більше. Для тисяч піктограм далекосхідних мов потрібно додавати зовсім Іншу розмірність у правила та методи кодування.

Різні стандарти спрямовані на методи кодування для унікальної ідентифікації локальних репер­туарів символів. У той час як заміна рідко вживаних символів у 7-ми бітному кодуванні, крім англій­ської мови, дозволяє підтримувати ще одну додаткову мову, 8-ми бітні схеми кодування використо­вують для одночасного підтримування багатьох мов, призначаючи (додаючи) до доступного репертуа­ру додаткові 96 графічних символів. ISO/IEC 8859-1:1998 — приклад підтримування мов Західної Європи, Америки, Австралії й інших англомовних країн. Для Східної Європи, Греції, Росії, Аравії та багатьох інших країн визначені інші 8-ми бітні коди. Японія, Китай, Корея і Тайвань у національному репертуарі мають так багато символів, що необхідні 16 чи навіть більше бітів для їхнього точного ідентифікування.

Через розбіжності схем кодування для прикладної платформи важлива потенційна можли­вість забезпечення кожної зі схем. Для прикладної платформи важлива можливість правильного по­дання даних (відображення, друку).

Для прикладної програми також важлива здатність визначати кодування елементів даних для набору символів, збережених на диску чи іншому накопичувані. Інакше прикладна програма не здатна пра­вильно Інтерпретувати дані. Нині користувач повинен контролювати несуперечливість викорис­тання тих самих кодових наборів символів усередині прикладної програми, але у майбутньому прик­ладна платформа буде здатна надавати методи ідентифікування кодових наборів символів, що їх вживають для сховищ даних, оброблення, комунікації та подання. Зрештою прикладна програма 113одержить вигідну здатність заборони модифікації користувачами даних, збережених у одному кодо­вому наборі символів, на дані в іншому кодуванні, що негайно зруйнувало б бази даних чи каталоги та файли. Отже, у майбутньому необхідно забезпечити метод оголошення кодового набору симво­лів, здатного зберігати, обробляти, передавати та подавати дані, включаючи одно-, двох- чи чотирьох- восьми бітні кодові набори символів.

Загальні служби для підтримування наборів символів та подання даних у міжнаціональному се­редовищі орієнтовані на таке.

Незалежність кодових наборів символів. Прикладна платформа повинна бути здатна уводити, збе­рігати, керувати, відновлювати (відшукувати), передавати та подавати дані незалежно від використаної схеми кодування, включаючи 7-ми, 8-ми, 16-ти бітні, а також мультиоктетні кодові набори символів.

Репозитарій наборів символів. Прикладна платформа повинна бути здатна підтримувати та звер­татися до центрального сховища (репозитарію) наборів символів. Репозитарій містить усі кодові на­бори символів, вживані платформою, та визначає за ними відповідну Інформацію:

• формат коду. Прикладна платформа повинна бути здатна містити формати символьного коду: 7 біт, 8 біт, 16 біт чи будь-який інший формат;

• визначення класів даних. Прикладна програма повинна бути здатна запитувати різні властивості символів, що змінюються від однієї локалізації до іншої. Приклади властивостей — рядки символів, разом з абетковими чи числовими;

• правила зіставлення. Оскільки різні набори символів мають різне кодування символів, прик­ладна платформа повинна бути здатна порівнювати рядки закодованих символів, дотримуючись правил, визначених для конкретного набору символів. Додаткові, залежні від культурних угод правила зіставлення обговорено у 5.1.4.1.2.;

• відображення нижнього-еерхнього регістру. Необхідно забезпечити механізм виконання розширеного відображення символів для задоволення різних потреб локальних мов. Прикладна платформа повинна бути здатна обробляти правила відображення символів типу "нижній-верхній регістр" та "верхній-нижній регістр". Для деяких специфічних символів недоступний верхній чи ниж­ній регістр. Приклади — нижній регістр "umlauts", що не має верхнього регістра подання у Швейцарії; форми верхнього регістра А, О чи U відповідно, що супроводжують нижнім регістром "е". Потреба в подібних поняттях відсутня у деяких культурах. Деякі культури мають правила відображення симво­лів, відмінні від відображення верхнього чи нижнього регістру. Наприклад, японський "kana" має пра­вило, відмінне у Hiragana та Katakana;

• правила напрямку письма. У деяких мовах, подібно івриту та арабській, пишуть спра­ва наліво; числа усередині тексту пишуть зліва направо. Прикладна платформа повинна бути здатна зберігати правила напрямку відповідно до набору символів;

• правила подання. Прикладна платформа повинна бути здатна забезпечувати правила ней­тралізації несправностей (fallback) для відтворення закодованих символів, не асоційованих із графіч­ною формою.

Ідентифікатор набору символів. Прикладна платформа повинна бути здатна унікально ідентифі­кувати кожен кодовий набір символів, допускаючи перевіряння сумісності та трансляцію чи транс­літерацію за допомогою інших зареєстрованих наборів символів, чим гарантувати цілісність да­них у комунікаціях.

Вибирання набору символів. Прикладна платформа повинна давати змогу кінцевому користу­вачу чи прикладній програмі вибирати кодовий набір символів; інакше кажучи, прикладна програма по­винна автоматично, за попередньо встановленими параметрами вибирати заданий за промовчанням кодовий набір символів, включати інші кодові набори символів та за потреби викликати підпрограми трансляції.

Оголошення даних. Для прикладної платформа була б корисною здатність розпізнавати кодо­вий набір символів об’єктів даних (файлів, повідомлень тощо). Один Із шляхів полягає у збереженні ідентифікатора набору символів разом із даними; зусилля зі стандартизації спрямовані на форма­лізацію процесу, зосередженого на ступені деталізації подібної ідентифікації (наприклад, файл, слово чи символ). Оголошення дає змогу прикладній програмі забороняти перетворення даних, закодова­них іншими наборами символів, таким чином гарантуючи цілісність даних навіть у розподілених системах.

Подання даних. Прикладна платформа повинна бути здатна подавати дані для різних типів при­строїв для відображення та виводу за потенційно відповідними правилами репозитарію, визначення 114базової таблиці символів та вибору різних форм. Готування даних для подання може включати широку трансляцію та транслітерацію через потенційні апаратні обмеження принтерів та дис­плеїв, що їх застосовують у конкретної інсталяції.

Зв'язок даних. Прикладна платформа повинна бути здатна передавати й одержувати дані із систем комунікації та підтримувати цілісність інформації. У міжнаціональному середовищі подібна можливість могла б включати трансляцію даних прямо у різні кодові набори символів, використо­вуваних різними категоріями служб прикладної платформи.

Ввід даних. Здатність уводу даних не обов’язково керує прикладна платформа. У майбутньому може бути необхідно забезпечити механізм уводу багатьох локальних наборів символів у одному тексті, що згодом могло б бути корисно для вхідних даних, що несуть певну форму Ідентифікування набору символів.

• .1.4.1.2 Культурні угоди. Крім використання різних символів та різних мов, країни світу також мають зовсім різні культурні угоди. Навіть усередині однієї країни можна знайти значні розбіжності у культурних середовищах. Яскравий приклад — Швейцарія, де французька, німецька, італійська та ретророманська — офіційні мови. Мовні пріоритети об’єднані з угодами щодо форматів часу, дат, числових значень та систем мір і ваг. Позначення грошової одиниці, формати ділових паперів, розміщування переносів у словах та сортування залежать від культурних угод. Застосування, орієн­товані на кінцевого користувача, повинні бути спрямовані на уникнення подібних розбіжностей, забезпечуючи звичне подання, що допомагає оперативно запобігати помилкам.

Загальні служби для культурних угод такі.

Репозитарій культурних угод. Прикладна платформа повинна бути здатна зберігати та зверта­тися до правил і угод для культурних об’єктів. їх можна співвіднести із загальною мовою, географіч­ною територією чи регіоном із загальним культурним чи Історичним тлом. Репозитарій повинен міс­тити специфікації та правила подання для:

• форматів дат та часу. Указують формати, пов’язані з конкретним культурним об’єктом. Наприклад, у США дата виражена у форматі «місяць/день/рік», європеєць волів би формат "рік-мі- сяць-день” із метою оброблення даних і "день-місяць-рік" для персонального ужитку. Японія рахує роки згідно часу панування Імператора. До того ж, години від 00.00 до 24.00, розповсюджені в Європі, у США використовують тільки у військових колах, тоді як терміни "am" і "pm" під час позначення ранку та пополудні уживані широкою публікою. От тільки декілька прикладів культурних розбіжнос­тей. Прикладна платформа повинна бути здатна зберігати пріоритетні форми дат та часу для кон­кретного культурного об’єкта й зробити їх доступними після запиту формату;

• нумерація дня та тижня. У Європі тиждень починається в понеділок; у США — у неділю. Прикладна платформа повинна бути здатна забезпечити запит програмою необхідної інформації, потенційно з репозитарію за певними правилами;

• формати числових полів. Оброблення числових полів у малознайомих форматах — одна з головних причин помилок. Прикладна платформа повинна забезпечити служби формату­вання значень відповідно до специфікацій у репозитарії. Символи, що виражають роздільник де­сяткового дробу (кома, крапка тощо), треба визначати так само, як число десяткових знаків перед роз­дільником десяткового дробу та подання від’ємних величин;

• позначення грошової одиниці та довжина поля. Оброблення позначень грошової одиниці у різних культурах повинні забезпечувати загальні служби інтернаціоналізації. Позначення грошової одиниці може мати довжину більш одного символу та знаходитися до чи після поля грошової оди­ниці. Формат полів грошової одиниці може відрізнятися від таких самих числових полів; наприклад, у Португалії знак «$» використовували як десяткову точку. Інформацію щодо угод треба зберігати у репозитарії та використовувати прикладною платформою для локального форматування полів гро­шової одиниці. Не обов’язково уводити службу, але важливо зрозуміти старанність у регулюванні дов­жини поля різних валют. Крім того, деякі валюти не мають десяткових дробів (наприклад, колись італійська ліра);

• формат паперу. Всесвітньо уживані та мобільні застосування повинні мати здатність ви­воду на друк паперів різного формату. У той час як формат «quarto» переважає в США, ISO стандар­тизувала A-формати для вживання в Європі, Кореї, Гонконгу та Японії. Драйвери принтера повинні бути здатні коригувати свій вивід щодо локальних форматів, визначених у репозитарії культурних угод.

Вибір репозитарію культурних угод. Репозитарії повинні бути доступні всім застосуванням. Корис­тувачі та застосування повинні мати змогу вибирати репозитарій із прикладної платформи; за не вста­новленого вибору необхідно забезпечити встановлення значення за промовчанням. Додаткові служби допускають динамічне перемикання між репозитаріями за запитом програми чи користувача.

Правила впорядкування. Типові двійкові та залежні від набору символів правила впорядку­вання дозволяють прикладній платформі сортувати дані за локальними правилами, визначеними у репозитарії. Приклад культурно-залежних правил зіставлення — оброблення «umlauts» (умляут); в Австрії впорядкування ведуть із початку абетки за основними символами латиниці, а у Швеції — наприкінці абетки. Складність збільшується під час упорядкування, що змінюється всередині однієї країни за звичайного ділового використання у словниках та телефонних книгах. Інші особ­ливості — упорядкування одного символу з двох букв (кодування німецької букви "sharp's" як "sz" в Австрії та "ss" у Німеччині), або двох символів як одного чи символів із підкресленням у рядку тощо. Таблиці впорядкування, обумовлені користувачем у репозитарії культурних угод, враховують служби, що залежать від культурних угод чи від прикладної програми.

6.1.4.1.3 Підтримування природної мови. POSIX-OSE повинна забезпечувати користувачам вибір природної мови для діалогу із системою та застосуваннями. Нереально очікувати від при­кладних платформ підтримки всіх можливих природних мов, однак служби повідомлень про по­милки, Інтерактивної документації, допомоги, меню вибору, а також відповідної взаємодії користу­вача з цими службами, повинні бути готові до перекладу на обрану користувачем природну мову. Крім того, POSIX-OSE повинна підтримувати розбіжності між природною мовою, обраною користувачем для взаємодії з прикладною платформою й використання усередині конкретної прикладної програми. Для оброблення текстів служби включають розміщення переносів І перевіряють правильність написання з можливим тезаурусом на різних мовах. Проблема ускладнюється за наявності текстів на різних мовах в одному документі.