Czy UTF-8 byłby w stanie wesprzeć włączenie ogromnego obcego języka z milionami nowych znaków?

86

W przypadku inwazji obcych i zmuszeni jesteśmy wspierać ich języki we wszystkich naszych istniejących systemach komputerowych, czy UTF-8 został zaprojektowany w taki sposób, aby uwzględnić ich możliwie dużą liczbę postaci?

(Oczywiście nie wiemy, czy kosmici rzeczywiście mają języki, czy i jak się komunikują, ale ze względu na kłótnię, wyobraź sobie, że tak.)

Na przykład, jeśli ich język składałby się z milionów nowo odkrytych glifów, symboli i / lub znaków łączących , czy teoretycznie UTF-8 mógłby zostać teoretycznie rozwinięty w sposób nieprzerwany, aby obejmował te nowe glify i nadal obsługiwał całe istniejące oprogramowanie?

Bardziej interesuje mnie to, czy glify znacznie przekroczyły obecne ograniczenia wielkości i wymagały więcej bajtów do reprezentowania pojedynczego glifu. W przypadku, gdyby UTF-8 nie mógł zostać rozszerzony, czy to dowodzi, że pojedynczą przewagą nad UTF-32 jest po prostu rozmiar niższych znaków?

Qix
źródło
16
„wesprzyj ich języki ” (moje podkreślenie) ... Ile? Czy jesteśmy pewni, że języki można podzielić na znaki? Być może język opiera się na relacjach przestrzennych. - patrz Ted Chiang „Story of Your Life”, Stories of Your Life i inni . W najlepszym razie jest to pytanie o maksymalnej liczbie bajtów X (nie na temat). W najgorszym przypadku jest to nonsens spekulacyjny. (nie jasne, o co pytasz)
Scant Roger
6
@ScantRoger Zaakceptowana odpowiedź ma dobrą robotę, odpowiadając na pytanie zgodnie z przeznaczeniem.
Qix
11
Zaakceptowana odpowiedź świetnie przekazuje nam fakty dotyczące UTF-8, UTF-16 i UTF-32. Możesz to po prostu sprawdzić na Wikipedii. Jeśli chodzi o „inwazję kosmitów”, nie rozumiem, w jaki sposób odpowiedź na to pytanie w ogóle się odnosi.
Scant Roger
10
Powiązane (w przypadku przepełnienia stosu): Czy UTF-8 wystarcza dla wszystkich popularnych języków?
yannis
9
Unicode nie obsługuje języków, obsługuje znaki - glify używane do reprezentowania znaczenia w formie pisemnej. Wiele języków ludzkich nie ma skryptu i dlatego nie może być obsługiwany przez Unicode. Nie wspominając o tym, że wiele zwierząt się komunikuje, ale nie ma języka pisanego. Komunikacja przez powiedzmy ilustracje lub komiksy bez słów nie może być obsługiwana przez Unicode, ponieważ zestaw glifów nie jest skończony. Z definicji nie wiemy, w jaki sposób komunikują się kosmici, więc na twoje pytanie nie można odpowiedzieć. Jeśli chcesz tylko wiedzieć, ile różnych znaków unicode może obsłużyć, prawdopodobnie powinieneś wyjaśnić :)
JacquesB

Odpowiedzi:

109

Standard Unicode ma dużo miejsca do stracenia. Punkty kodowe Unicode są zorganizowane w „płaszczyznach” i „blokach”. Z 17 wszystkich samolotów jest obecnie 11 nieprzypisanych . Każdy samolot ma 65 536 znaków, więc realistycznie jest pół miliona współrzędnych kodowych dla obcego języka (chyba że wypełnimy to wszystko emoji przed pierwszym kontaktem). Począwszy od Unicode 8.0, tylko 120 737 punktów kodowych zostało przypisanych łącznie (około 10% całkowitej pojemności), przy czym mniej więcej ta sama ilość jest nieprzydzielona, ​​ale zarezerwowana do prywatnego, specyficznego dla aplikacji zastosowania. W sumie 974 530 współrzędnych kodowych jest nieprzypisanych.

UTF-8 jest specyficznym kodowaniem Unicode i obecnie jest ograniczony do czterech oktetów (bajtów) na punkt kodowy, co odpowiada ograniczeniom UTF-16. W szczególności UTF-16 obsługuje tylko 17 samolotów. Wcześniej UTF-8 obsługiwał 6 oktetów na punkt kodowy i był zaprojektowany do obsługi 32768 samolotów. Zasadniczo ten 4-bajtowy limit mógłby zostać zniesiony, ale złamałoby to obecną strukturę organizacyjną Unicode i wymagałoby wycofania UTF-16 - jest mało prawdopodobne w bliskiej przyszłości, biorąc pod uwagę stopień zakorzenienia w niektórych systemach operacyjnych i programowaniu Języki.

Jedynym powodem, dla którego UTF-16 jest nadal w powszechnym użyciu, jest rozszerzenie wadliwego kodowania UCS-2, które obsługuje tylko jedną płaszczyznę Unicode. W przeciwnym razie dziedziczy niepożądane właściwości zarówno z UTF-8 (nie o stałej szerokości), jak i UTF-32 (nie kompatybilny z ASCII, marnowanie miejsca na wspólne dane) i wymaga znaków bajtów do deklarowania endianizmu. Biorąc pod uwagę, że pomimo tych problemów UTF-16 jest nadal popularny, nie jestem zbyt optymistyczny, że to się wkrótce zmieni. Mamy nadzieję, że nasi nowi Władcy Obcych zobaczą przeszkodę dla ich rządów, a ich mądrość usunie UTF-16 z powierzchni ziemi .

amon
źródło
7
W rzeczywistości UTF-8 jest ograniczony tylko do części nawet 4-bajtowego limitu, aby dopasować UTF-16. W szczególności, do 17/32 z tego, nieco więcej niż połowa.
Deduplicator
5
Poza systemem Windows nie znam żadnego innego systemu operacyjnego, w którym system operacyjny lub większość programów w systemie operacyjnym używa UTF16. Programy OSX to zazwyczaj UTF8, programy Android to zwykle UTF8, Linux to zwykle UTF8. Wszystko, czego potrzebujemy, to by Windows umarł (już jest trochę martwy w mobilnej przestrzeni)
Slebetman
23
Chyba że wypełnimy to wszystkim emoji przed pierwszym kontaktem ... Masz. Najbardziej znaczącym zagrożeniem dla pokojowych interakcji z kosmitami są emoji. Jesteśmy zgubieni.
rickster,
13
@slebetman Nie bardzo. Wszystko, co oparte na JVM korzysta z UTF-16 (również Android, nie wiem, dlaczego mówisz, że nie), JavaScript używa UTF-16, a biorąc pod uwagę, że Java i JavaScript są najpopularniejszymi językami, UTF-16 nigdzie się nie wybiera wkrótce.
Malcolm,
5
@Kaiserludi „Większość kodu linux używa UTF32 dla Unicode”, tak, nie. Poważnie, skąd do cholery wpadłeś na ten pomysł? Nie ma nawet wfopen wywołania systemowego ani nic innego, to UTF8 przez całą drogę. Do diabła nawet Python i Java - oba, które ze względów historycznych definiują ciągi jako UTF-16 - nie przechowują ciągów jako UTF-16, chyba że jest to konieczne. Duża pamięć i brak wydajności (i to pomimo dodatkowego kodu do obsługi konwersji - pamięć jest droga, procesor jest tani). To samo dotyczy Androida - JString NDK to UTF8, głównie dlatego, że inżynierowie Google nie są szaleni.
Voo,
30

Jeśli UTF-8 rzeczywiście ma zostać rozszerzony, powinniśmy spojrzeć na absolutne maksimum, jakie może reprezentować. UTF-8 ma następującą strukturę:

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

(bezwstydnie skopiowane z RFC .) Widzimy, że pierwszy bajt zawsze kontroluje, ile kolejnych bajtów składa się na bieżący znak.

Jeśli rozszerzymy go do 8 bajtów, otrzymamy dodatkowe reprezentacje inne niż 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

Obliczanie maksymalnych możliwych reprezentacji, do których pozwala ta technika

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

lub w bazie 10:

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

co daje nam maksymalną liczbę reprezentacji wynoszącą 4 468,982,745,216.

Jeśli więc te 4 miliardy ( lub tryliony, jak chcesz ) znaków wystarczą do przedstawienia obcych języków, jestem całkiem pewien, że przy minimalnym wysiłku możemy rozszerzyć obecny UTF-8, aby zadowolić naszych nowych obcych władców ;-)

Boldewyn
źródło
8
Obecnie UTF-8 jest ograniczony tylko do punktów kodowych do 0x10FFFF - ale dotyczy to tylko zgodności z UTF-16. Jeśli trzeba było go rozszerzyć, nie ma dwuznaczności co do tego, jak rozszerzyć go o punkty kodowe do 0x7FFFFFFF (to 2³¹-1). Ale poza tym widziałem sprzeczne definicje. Jedna z definicji, którą widziałem, ma 111111xxjako pierwszy bajt, po którym następuje pięć bajtów rozszerzenia dla maksymalnie 2³² punktów kodowych. Jest to jednak zgodne tylko z definicją wymienioną dla pierwszych 2³ punktów kodowych.
kasperd
2
Tak, Wikipedia mówi coś o UTF-16, kiedy tak naprawdę mają na myśli Unicode lub ISO 10646 (w zależności od kontekstu). W rzeczywistości, ponieważ RFC 3629, UTF-8 jest niezdefiniowany poza U + 10FFFF (lub F4 8F BF BFw bajtach UTF-8). Więc wszystko, o czym tu wspominam, to czysta spekulacja. Oczywiście, ktoś może pomyśleć o innych rozszerzeniach, w których pierwszy wysoki bajt oznacza inną strukturę następującą (i miejmy nadzieję, że nie zniszczy samo-synchronizacji w tym procesie). Próbowałem jednak ukończyć schemat bajtów, aby być jak najbliżej prawdziwego UTF-8.
Boldewyn
4
To 4 tryliony, nie kwadryliony.
Ypnypn
1
Nie jest absolutnie konieczne, aby liczba następnych bajtów była zawsze o jeden mniejsza od liczby wiodących w pierwszym bajcie. Perl faktycznie obsługuje (od 2000 r.) Wewnętrzny wariant UTF-8, w którym formy 5, 6 i 7 bajtów są takie same jak ta odpowiedź, ale FFwprowadza 13-bajtową jednostkę kodową zdolną do przechowywania 72 bitów. Wszystko powyżej 2 ^ 36 jest jednolicie bardzo drogie, ale pozwala na kodowanie 64-bitowego inta, a potem jeszcze trochę.
hobbs
7

RFC3629 ogranicza UTF-8 do maksymalnie czterech bajtów na znak, przy maksymalnej wartości 0x10FFFF, umożliwiając maksymalnie 1112 064 punktów kodowych. Oczywiście to ograniczenie można usunąć i rozszerzyć standard, ale byłoby to przełomową zmianą dla istniejącego kodu, który działa do tego limitu.

Z punktu widzenia pliku danych nie byłaby to przełomowa zmiana, ponieważ standard działa na podstawie tego, że jeśli ustawiony jest najbardziej znaczący bit (MSB) każdego bajtu, to następny bajt jest częścią kodowania. Nawet przed RFC3629 standard był ograniczony do 31 bitów, pozostawiając MSB czwartego bajtu nieustawionym.

Jednak rozszerzenie standardu poza 0x10FFFF złamałoby częściową kompatybilność danych UTF-8 z UTF-16.

David Arno
źródło
5
Więc teoretycznie dane byłyby kompatybilne wstecz, ale kod z natury nie byłby zgodny z modyfikacją standardu?
Qix
2
@Qix, To ważny punkt. Każdy istniejący plik UTF-8 byłby oczywiście zgodny z np. Maksymalnie 6 bajtami, aby pomieścić miliony dodatkowych punktów kodu, ale wiele istniejących bibliotek zaprojektowanych do obsługi UTF-8 prawdopodobnie nie obsługiwałoby tego rozszerzenia.
David Arno,
4
UTF-16 pękłby śmiertelnie. Z natury może obsługiwać tylko punkty kodu do 0x10FFFF.
gnasher729,
1
@ gnasher729: Nie tak duży problem, jak mogłoby się wydawać. Pre-Unicode rozwiązał to za pomocą wartości przesunięcia (Shift JIS dla japońskiego). Oznaczą po prostu zarezerwowany / nieużywany znak (0xFFFD?) Jako „znak przesunięcia”, który zmieni kodowanie w bardziej rozszerzoną formę. Prawdopodobnie UTF32.
Kaczka Mooing
4

Naprawdę, tylko 2 kody punktowe Unicode oznaczają nieskończenie wiele glifów, jeśli łączą one znaki.

Porównaj na przykład dwa sposoby kodowania Unicode dla koreańskiego alfabetu Hangul : Hangul Syllables i Hangul Jamo . Znak 웃 Hangul Syllabelsjest pojedynczym kodem, C6C3podczas gdy w Hangul Jamonim są trzy kody 110B(ㅇ) 116E(ㅜ) 11B9(ㅅ). Oczywiście użycie łączenia znaków zajmuje znacznie mniej punktów kodowych, ale jest mniej wydajne w pisaniu, ponieważ potrzeba więcej bajtów do napisania każdego znaku.

Dzięki tej sztuczce nie trzeba przekraczać liczby punktów kodowych, które można obecnie zakodować w UTF-8 lub UTF-16.

Wydaje mi się, że sprowadza się to do urażenia kosmitów, gdyby ich język wymagał więcej bajtów na wiadomość niż języki ziemskie. Jeśli nie przeszkadza im to, powiedzmy, reprezentowanie każdego z ich milionów znaków przy użyciu mieszanki, powiedzmy, 100k łączących postaci, to nie ma problemu; z drugiej strony, jeśli zmuszenie ich do użycia większej liczby bajtów niż Ziemian sprawi, że poczują się jak obywatele drugiej kategorii, moglibyśmy popaść w jakiś konflikt (podobnie jak w przypadku UTF-8 ).

piekarnik
źródło
Dzieje się tak tylko wtedy, gdy znaki w obcym języku składają się z bardziej ograniczonego zestawu grafemów. Może tak nie być.
JacquesB
1
O ile mi wiadomo, nie ma wymogu, że łączenie postaci musi odnosić się do poszczególnych grafemów. Często zadawane pytania dotyczące Unicode milczą na ten temat, ale mam wrażenie, że silnik układu nie będzie trudniej obsługiwać sekwencji czesania, które nie są sekwencjami grafemów, ponieważ w obu przypadkach wymagany byłby wstępnie złożony glif.
Owen,
Jak długo żyją ci kosmici i ile postaci, które nie ulegają rozkładowi na grafemy, mogą nauczyć się w dzieciństwie? I czy wstępnie skomponowany Hangul zachowuje swoją przewagę bajtową nad rozłożonym Hangul nawet po gzipie?
Damian Yerrick
-2

Edycja: pytanie brzmi teraz „miliony nowych postaci”. Ułatwia to odpowiedź:

Nie . Utf-8 to kodowanie Unicode. Unicode ma przestrzeń kodową, która umożliwia 1114112 różnych punktów kodowych , a mniej niż milion jest obecnie nieprzypisany. Dlatego nie można obsługiwać milionów nowych znaków w standardzie Unicode. Z definicji żadne kodowanie Unicode nie może obsłużyć większej liczby znaków niż to, które jest zdefiniowane przez Unicode. (Oczywiście możesz oszukiwać, kodując dalej poziom - każdy rodzaj danych może być reprezentowany przez zaledwie dwa znaki).


Aby odpowiedzieć na oryginalne pytanie:

Unicode nie obsługuje języków jako takich, obsługuje znaki - symbole używane do reprezentowania języka w formie pisemnej.

Nie wszystkie języki ludzkie mają pisemną reprezentację, więc nie wszystkie języki ludzkie mogą być obsługiwane przez Unicode. Ponadto wiele zwierząt komunikuje się, ale nie ma języka pisanego. Na przykład wieloryby mają formę komunikacji, która jest wystarczająco złożona, aby wywoływać język, ale nie ma żadnej formy pisemnej (i nie może być uchwycona przez istniejącą notację fonetyczną). Dlatego nawet wszystkie języki na ziemi nie mogą być obsługiwane przez Unicode.

Jeszcze gorzej jest coś w rodzaju języka pszczół. Nie tylko nie ma formy pisemnej, ale nie może być w sposób znaczący reprezentowany w formie pisemnej. Język jest rodzajem tańca, który zasadniczo wskazuje kierunek, ale zależy od aktualnej pozycji słońca. Dlatego taniec ma wartość informacyjną tylko w określonym miejscu i czasie, w którym jest wykonywany. Symboliczne lub tekstowe przedstawienie musiałoby zawierać informacje (położenie, położenie słońca), których język pszczół obecnie nie jest w stanie wyrazić.

Nawet pisemna lub symboliczna forma komunikacji może nie być możliwa do przedstawienia w Unicode. Na przykład ilustracje lub komiksy bez słów nie mogą być obsługiwane przez Unicode, ponieważ zestaw glifów nie jest skończony. Zauważysz wiele obrazowej komunikacji w warunkach międzynarodowych, takich jak lotnisko, więc nie jest wykluczone, że rasa kosmitów podróżujących w kosmosie ewoluowała, używając języka obrazkowego.

Nawet jeśli obca rasa ma język z systemem pisania ze skończonym zestawem symboli, ten system może nie być obsługiwany w Unicode. Unicode oczekuje, że pisanie będzie liniową sekwencją symboli. Notacja muzyczna jest przykładem systemu pisania, który nie może być w pełni reprezentowany w Unicode, ponieważ znaczenie jest zakodowane zarówno w wyborze symboli, jak i w pionie i poziomie. (Unicode obsługuje pojedyncze symbole muzyczne, ale nie może zakodować partytury.) Obca rasa, która komunikowała się za pomocą muzyki polifonicznej (nierzadko) lub kanału komunikacji o podobnej złożoności, mogłaby równie dobrze mieć system zapisu przypominający partyturę orkiestrową, i Unicode nie obsługuje tego.

Ale dla argumentu załóżmy, że wszystkie języki, nawet języki obce, mogą być wyrażone jako liniowa sekwencja symboli wybranych ze zbioru skończonego. Czy Unicode jest wystarczająco duży, aby przeprowadzić inwazję kosmitów? Unicode ma obecnie mniej niż milion nieprzypisanych współrzędnych kodowych. Język chiński zawiera sto tysięcy znaków według najbardziej wyczerpującego chińskiego słownika (nie wszystkie z nich są obecnie obsługiwane przez Unicode jako odrębne znaki). Tak więc tylko dziesięć języków o złożonym języku chińskim zużyłoby cały Unicode. Na ziemi mamy setki różnych systemów pisma, ale na szczęście większość z nich ma charakter alfabetyczny niż ideograficzny i dlatego zawiera niewielką liczbę znaków. Gdyby wszystkie języki pisane używały ideogramów takich jak chiński, Unicode nie byłby nawet wystarczająco duży dla Ziemi. Używanie alfabetów wywodzi się z mowy, która używa tylko ograniczonej liczby fonemów, ale jest to szczególne w przypadku fizjologii człowieka. Tak więc nawet jedna obca planeta z zaledwie tuzinem ideograficznych systemów pisania może przekroczyć możliwości Unicode. Teraz zastanów się, czy ten obcy już zaatakował inne planety przed Ziemią i włączył swoje systemy pisania do zestawu znaków, które muszą być obsługiwane.

Rozszerzenie lub modyfikacja obecnych kodowań lub wprowadzenie nowych kodowań nie rozwiąże tego, ponieważ ograniczenie dotyczy liczby punktów kodowych obsługiwanych przez Unicode.

Więc odpowiedź brzmi najprawdopodobniej nie.

JacquesB
źródło
5
Brakuje ci wyobraźni. Choreografowie tańca mają mnóstwo języka i terminologii, których mogą używać do opisywania i nauczania tańców, które wykonają aktorzy sceniczni. Gdybyśmy mieli się dowiedzieć, co komunikują się pszczoły, zdecydowanie moglibyśmy opracować dla tego pisemną terminologię. W końcu większość naszych obecnie pisanych języków to kodowanie dźwięku. Kodowanie ruchu nie różni się niczym od kodowania dźwięku.
whatsisname
3
Części tej odpowiedzi są dobre, ale powiedzenie „Nie tylko nie ma formy pisemnej, ale nie może być reprezentowane w formie pisemnej” jest po prostu błędne. Wszystko, co przekazuje informacje, można sprowadzić do bitów, a wszystko, co sprowadza się do bitów, można przekształcić w dowolny strumień znaków, który lubisz.
Steven Burnap
2
@StevenBurnap Prawda, ale Unicode to coś więcej niż sekwencja bitów. Jest to sposób interpretacji tych bitów, który jest dość sztywny. Tak, zestaw znaków Unicode można rozszerzyć, aby reprezentował wszystko, od obrazów po instrukcje CNC, ale byłoby to zupełnie inne stworzenie.
Owen
4
Należy pamiętać, że to, co opisują symbole Unicode (w większości języków), są wzorcami zmienności ciśnienia powietrza, i że w większości języków faktycznie dość kiepska praca polega na dopasowaniu tych wzorców.
Steven Burnap
3
Masz na myśli zdanie „leć 45 sekund ze słońcem 15 stopni w lewo, a następnie lataj 10 sekund ze słońcem 10 stopni w prawo” jest niemożliwe? Z pewnością wymaga ono położenia słońca jako kontekstu.
Steven Burnap,