Чи зможе UTF-8 підтримати включення широкої чужої мови з мільйонами нових символів?

У випадку, якщо вторгнення прибульців відбулося, і ми змушені були підтримувати їхні мови у всіх наших існуючих комп'ютерних системах, чи UTF-8 розроблений таким чином, щоб забезпечити їх можливо велику кількість символів?

(Звичайно, ми не знаємо, чи справді інопланетяни володіють мовами, чи або як вони спілкуються, але заради аргументації, будь ласка, уявіть, що вони роблять.)

Наприклад, якби їх мова складалася з мільйонів новоспечених гліфів, символів та / або поєднання символів , чи можна теоретично розширити UTF-8 безперебійним чином, щоб включити ці нові гліфи і все-таки підтримувати все існуюче програмне забезпечення?

Мене більше цікавить, чи глифи значно перевищують поточні обмеження розміру і потрібно більше байтів, щоб представити один гліф. У випадку, якщо UTF-8 не вдасться розширити, чи це доводить, що єдиною перевагою перед UTF-32 є просто розмір нижчих символів?

Стандарт Unicode має багато місця для запасу. Кодові точки Unicode організовані в "площини" та "блоки". З 17 загальних літаків 11 наразі не призначені . Кожен літак містить 65 536 символів, тому реально є півмільйона кодових точок, щоб запастися на чужу мову (якщо тільки ми не заповнимо все це більше емоджи перед першим контактом). Станом на Unicode 8.0, всього було присвоєно 120 737 кодових пунктів (приблизно 10% від загальної ємності), приблизно приблизно така ж сума не призначена, але зарезервована для приватного використання. Загалом 974,530 точок коду не призначено.

UTF-8 є специфічним кодуванням Unicode і в даний час обмежений чотирма октетами (байтами) на кодову точку, що відповідає обмеженням UTF-16. Зокрема, UTF-16 підтримує лише 17 літаків. Раніше UTF-8 підтримував 6 октетів на кодову точку і був розроблений для підтримки 32768 літаків. В принципі, цей 4-байтний ліміт може бути скасований, але це порушить поточну організаційну структуру Unicode і вимагатиме поступового припинення UTF-16 - навряд чи це станеться найближчим часом, враховуючи, наскільки закріплений він у певних операційних системах та програмуванні мови.

Єдина причина, що UTF-16 все ще використовується в тому, що це розширення до хибного кодування UCS-2, яке підтримує лише одну площину Unicode. В іншому випадку він успадковує небажані властивості як від UTF-8 (не з фіксованою шириною), так і від UTF-32 (не сумісний з ASCII, втрата місця для загальних даних), і вимагає байтових знаків порядку, щоб оголосити про небезпеку. Зважаючи на те, що незважаючи на ці проблеми, UTF-16 все ще популярний, я не надто оптимістичний, що це зміниться саме по собі. Сподіваємось, наші нові Чужоземні володарі побачать цю перешкоду для свого правління, і в їхній мудрості виганяють UTF-16 з лиця землі .

Якщо насправді UTF-8 буде розширено, ми повинні подивитися на абсолютний максимум, який він може представляти. UTF-8 структурований так:

Char. number range  |        UTF-8 octet sequence
   (hexadecimal)    |              (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

(Безсоромно скопійована з RFC ) . Ми бачимо , що перший байт завжди контролює , скільки наступних байтів складають поточний символ.

Якщо розширити його до 8 байт, ми отримаємо додаткові уявлення Unicode

111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Обчислення максимально можливих уявлень, які ця методика дозволяє нам дійти

  10000000₂
+ 00100000₂ * 01000000₂
+ 00010000₂ * 01000000₂^2
+ 00001000₂ * 01000000₂^3
+ 00000100₂ * 01000000₂^4
+ 00000010₂ * 01000000₂^5
+ 00000001₂ * 01000000₂^6
+ 00000001₂ * 01000000₂^7

або в базі 10:

  128
+  32 * 64
+  16 * 64^2
+   8 * 64^3
+   4 * 64^4
+   2 * 64^5
+   1 * 64^6
+   1 * 64^7

що дає нам максимальну кількість представлень як 4,468,982,745,216.

Отже, якщо цих 4 мільярдів ( або трильйона, як вам завгодно ) символів вистачить для представлення чужих мов, я цілком впевнений, що ми можемо з мінімальними зусиллями розширити поточний UTF-8, щоб догодити нашим новим чужим сюзеренам ;-)

RFC3629 обмежує UTF-8 максимум чотирма байтами на символ, максимальним значенням 0x10FFFF, дозволяючи максимум 1,112,064 кодових очок. Очевидно, це обмеження можна було б зняти, а стандарт продовжити, але це призведе до суттєвої зміни існуючого коду, який працює до цієї межі.

З точки зору файлу даних, це не буде переломною зміною, оскільки стандарт працює на основі того, що якщо встановлено найзначніший біт (MSB) кожного байта, то наступний байт є частиною кодування. Ще до RFC3629 стандарт був обмежений на 31 біт, що залишило MSB четвертого байту невідомим.

Розширення стандарту понад 0x10FFFF призведе до порушення часткової сумісності даних UTF-8 з UTF-16.

Дійсно, лише 2 кодові пункти Unicode означають нескінченно багато гліфів, якби вони поєднували символи.

Порівняйте, наприклад, два способи, які Unicode кодує для корейського алфавіту Хангул : склади Hangul і Hangul Jamo . Символ 웃 в Hangul Syllabelsє єдиною кодовою точкою, C6C3тоді як в Hangul Jamoньому є три кодові точки 110B(ㅇ) 116E(ㅜ) 11B9(ㅅ). Очевидно, що використання комбінованих символів займає значно менше кодових точок, але є менш ефективним для запису, оскільки для написання кожного символу потрібно більше байтів.

За допомогою цього фокусу немає необхідності виходити за кількість точок коду, які в даний час можуть бути закодовані в UTF-8 або UTF-16.

Я думаю, це зводиться до того, наскільки ображаються прибульці, якби їхня мова вимагала набагато більше байтів за повідомлення, ніж земні мови. Якщо вони не проти, скажімо, представляти кожного зі своїх мільйонів символів, використовуючи комбінацію символів на 100 тис. Символів, тоді проблем немає; з іншого боку, якщо змушені використовувати більше байтів, ніж земляни, змушують їх відчувати себе громадянами другого класу, ми можемо опинитися у конфлікті ( не на відміну від того, що ми вже спостерігаємо з UTF-8 ).

Редагувати: Питання тепер говорить про "мільйони нових символів". Це дозволяє легко відповісти:

Ні . Utf-8 - це кодування Unicode. У Unicode є кодове простір, який дозволяє 1114,112 різних кодових точок , а менше мільйона наразі не призначено. Тому неможливо підтримати мільйони нових символів в Unicode. За визначенням, кодування Unicode не може підтримувати більше символів, ніж те, що визначено Unicode. (Звичайно, ви можете обдурити, кодуючи рівень далі - будь-який тип даних може бути представлений лише двома символами.)

Щоб відповісти на початкове запитання:

Unicode не підтримує мови як такі, він підтримує символи - символи, які використовуються для представлення мови в письмовій формі.

Не всі людські мови мають письмове представлення, тому не всі людські мови можуть підтримуватися Unicode. Крім того, багато тварин спілкуються, але не володіють письмовою мовою. Наприклад, кити мають форму спілкування, яка є досить складною для виклику мови, але не має жодної письмової форми (і не може бути захоплена існуючими фонетичними позначеннями). Тому Unicode не може підтримувати навіть усі мови на землі.

Ще гірше - це щось на зразок мови бджіл. Він не тільки не має письмової форми, але не може змістовно бути представлений у письмовій формі. Мова - це вид танцю, який в основному вказує в напрямку, але покладається на поточне положення сонця. Тому танець має лише інформаційну цінність у конкретному місці та часі, де він виконується. Символічне або текстове зображення повинно містити інформацію (місце розташування, положення сонця), яку мова бджіл наразі не може виразити.

Навіть письмова або символічна форма спілкування може бути неможливою для представлення в Unicode. Наприклад, ілюстрації або безслівні комікси не можуть підтримуватися Unicode, оскільки набір гліфів не є кінцевим. Ви помітите багато образотворчого спілкування в таких міжнародних умовах, як аеропорт, тому немислимо, що гонка космічних подорожніх еволюціонерів розвинеться з використанням живописної мови.

Навіть якщо інопланетна раса мала мову із системою письма з обмеженим набором символів, цю систему, можливо, неможливо підтримати в Unicode. Unicode очікує, що запис буде лінійною послідовністю символів. Нотація музики - це приклад системи запису, яка не може бути повністю представлена ​​в Unicode, оскільки значення кодується як у виборі символів, так і у вертикальному та горизонтальному розміщенні. (Unicode підтримує окремі музичні символи, але не може кодувати партитуру.) Чужа раса, яка спілкувалася за допомогою поліфонічної музики (не рідкість) або каналу спілкування подібної складності, може дуже мати систему письма, схожу на оркестрову партитуру, і Unicode не може це підтримати.

Але давайте заради аргументу припустимо, що всі мови, навіть чужі мови, можуть бути виражені у вигляді лінійної послідовності символів, вибраних з кінцевого набору. Чи Unicode достатньо великий для вторгнення прибульців? Наразі Unicode має менше мільйона непризначених кодових точок. Китайська мова містить сто тисяч символів відповідно до найвичерпнішого китайського словника (не всі вони в даний час підтримуються Unicode як окремі символи). Отже, лише десять мов зі складною мовою китайської використовували б усі Unicode. На землі у нас сотні різних систем письма, але, на щастя, більшість бувають алфавітними, а не ідеографічними, тому містять невелику кількість символів. Якби всі письмові мови використовували такі ідеограми, як китайська, Unicode навіть не був би достатньо великим для землі. Використання алфавітів походить від мови, яка використовує лише обмежену кількість фонем, але це особливо для фізіології людини. Тож навіть одна чужа планета, яка має лише десяток ідеографічних систем письма, може перевищити те, що може підтримувати Unicode. Тепер поміркуйте, чи цей інопланетянин вже вторгся до інших планет перед землею і включив їхні системи письма в набір символів, які потрібно підтримувати.

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

Тож відповідь, швидше за все, ні.