Wäre UTF-8 in der Lage, die Aufnahme einer riesigen Fremdsprache mit Millionen neuer Zeichen zu unterstützen?

86

Falls eine Alien-Invasion stattfand und wir gezwungen waren, ihre Sprachen in allen unseren vorhandenen Computersystemen zu unterstützen, wurde UTF-8 so entwickelt, dass die möglicherweise große Anzahl von Zeichen berücksichtigt werden kann?

(Natürlich wissen wir nicht, ob Ausländer tatsächlich Sprachen haben, ob oder wie sie kommunizieren, aber bitte stellen Sie sich vor, dass dies der Argumentation zuliebe der Fall ist.)

Wenn zum Beispiel ihre Sprache aus Millionen von neu gefundenen Glyphen, Symbolen und / oder kombinierten Zeichen besteht , könnte UTF-8 theoretisch auf eine nicht unterbrechende Weise erweitert werden, um diese neuen Glyphen einzuschließen und dennoch die gesamte vorhandene Software zu unterstützen?

Ich bin mehr daran interessiert, ob die Glyphen die aktuellen Größenbeschränkungen bei weitem übertroffen haben und mehr Bytes erforderlich sind, um eine einzelne Glyphe darzustellen. Falls UTF-8 nicht erweitert werden konnte, beweist dies, dass der einzige Vorteil gegenüber UTF-32 einfach die Größe kleinerer Zeichen ist?

Qix
quelle
16
"unterstütze ihre Sprachen " (mein Schwerpunkt) ... Wie viele? Sind wir sicher, dass die Sprachen in Zeichen zerlegt werden können? Vielleicht basiert die Sprache auf räumlichen Beziehungen. - siehe Ted Chiang "Geschichte Ihres Lebens", Geschichten Ihres Lebens und andere . Bestenfalls handelt es sich einfach um eine Max-Things-in-X-Bytes-Frage (Off-Topic). Im schlimmsten Fall ist es spekulativer Unsinn. (nicht klar, was Sie fragen)
Scant Roger
6
@ScantRoger Die akzeptierte Antwort macht einen guten Job bei der Beantwortung der Frage, wie es beabsichtigt war.
Qix
11
Die akzeptierte Antwort kann uns die Fakten von UTF-8, UTF-16 und UTF-32 sehr gut mitteilen. Sie können dies einfach auf Wikipedia nachschlagen. Was "Alien-Invasion" betrifft, sehe ich nicht, wie die Antwort überhaupt darauf reagiert.
Scant Roger
10
Verwandt (bei Stapelüberlauf): Ist UTF-8 für alle gängigen Sprachen ausreichend?
Yannis
9
Unicode unterstützt keine Sprachen, sondern Zeichen - Glyphen, mit denen die Bedeutung in schriftlicher Form dargestellt wird. Viele menschliche Sprachen haben kein Skript und können daher nicht von Unicode unterstützt werden. Nicht zu vergessen, dass viele Tiere kommunizieren, aber keine geschriebene Sprache haben. Die Kommunikation mit Illustrationen oder wortlosen Comics kann von Unicode nicht unterstützt werden, da die Menge der Glyphen nicht endlich ist. Per Definition wissen wir nicht, wie Aliens kommunizieren, daher ist Ihre Frage unmöglich zu beantworten. Wenn Sie nur wissen möchten, wie viele unterschiedliche Zeichen Unicode unterstützen kann, sollten Sie wahrscheinlich klarstellen :)
JacquesB

Antworten:

109

Der Unicode-Standard bietet viel Platz. Die Unicode-Codepunkte sind in "Ebenen" und "Blöcke" unterteilt. Von insgesamt 17 Flugzeugen sind derzeit 11 nicht zugeordnet . Jede Ebene enthält 65.536 Zeichen, so dass realistisch gesehen eine halbe Million Codepunkte für eine fremde Sprache übrig bleiben (es sei denn, wir füllen das alles vor dem ersten Kontakt mit mehr Emoji auf). Seit Unicode 8.0 wurden insgesamt nur 120.737 Codepunkte zugewiesen (ungefähr 10% der Gesamtkapazität), wobei ungefähr derselbe Betrag nicht zugewiesen, aber für die private, anwendungsspezifische Verwendung reserviert ist. Insgesamt sind 974.530 Codepunkte nicht zugewiesen.

UTF-8 ist eine spezielle Unicode-Codierung und derzeit auf vier Bytes pro Codepunkt beschränkt, was den Einschränkungen von UTF-16 entspricht. Insbesondere unterstützt UTF-16 nur 17 Flugzeuge. Zuvor unterstützte UTF-8 6 Oktette pro Codepunkt und war für die Unterstützung von 32768-Flugzeugen ausgelegt. Im Prinzip könnte dieses 4-Byte-Limit aufgehoben werden, aber dies würde die aktuelle Organisationsstruktur von Unicode sprengen und eine schrittweise Abschaffung von UTF-16 erfordern - was angesichts der Verankerung in bestimmten Betriebssystemen und Programmen in naher Zukunft unwahrscheinlich ist Sprachen.

Der einzige Grund, warum UTF-16 immer noch häufig verwendet wird, ist die Erweiterung der fehlerhaften UCS-2-Codierung, die nur eine einzige Unicode-Ebene unterstützt. Andernfalls erbt es unerwünschte Eigenschaften von UTF-8 (nicht mit fester Breite) und UTF-32 (nicht ASCII-kompatibel, Platzverschwendung für gemeinsame Daten) und benötigt Byte-Ordnungszeichen, um die Endianität zu deklarieren. Angesichts der Tatsache, dass UTF-16 trotz dieser Probleme immer noch beliebt ist, bin ich nicht zu optimistisch, dass sich dies sehr bald von selbst ändern wird. Hoffentlich werden unsere neuen außerirdischen Overlords dieses Hindernis für ihre Herrschaft bemerken und UTF-16 in ihrer Weisheit vom Erdboden verbannen .

amon
quelle
7
Tatsächlich ist UTF-8 nur auf einen Teil der 4-Byte-Grenze beschränkt, um UTF-16 zu entsprechen. Insbesondere bis 17/32 davon etwas mehr als die Hälfte.
Deduplizierer
5
Außerhalb von Windows kenne ich kein anderes Betriebssystem, in dem entweder das Betriebssystem oder die meisten Programme auf dem Betriebssystem UTF16 verwenden. OSX-Programme sind in der Regel UTF8, Android-Programme sind in der Regel UTF8, Linux ist in der Regel UTF8. Alles, was wir brauchen, ist, dass Windows stirbt (im mobilen Bereich ist es bereits tot)
slebetman
23
Es sei denn, wir füllen das alles vor dem ersten Kontakt mit mehr Emoji auf ... Da haben Sie es. Die größte Bedrohung für die friedliche Interaktion mit Außerirdischen ist Emoji. Wir sind verdammt.
Rickster
13
@slebetman Nicht wirklich. Alles, was JVM-basiert ist, verwendet UTF-16 (auch Android, nicht sicher, warum Sie es nicht sagen), JavaScript verwendet UTF-16, und da Java und JavaScript die beliebtesten Sprachen sind, kann UTF-16 nicht überall und jederzeit eingesetzt werden bald.
Malcolm
5
@Kaiserludi "Der meiste Linux-Code verwendet UTF32 für Unicode", ja, nein. Ernsthaft, woher zum Teufel haben Sie diese Idee? Es gibt nicht einmal einen wfopen Syscall oder irgendetwas anderes, es ist UTF8 den ganzen Weg. Sogar Python und Java - beide, die aus historischen Gründen Strings als UTF-16 definieren - speichern Strings nur dann als UTF-16, wenn dies erforderlich ist. Speicher ist teuer, CPU ist billig). Gleiches gilt für Android - der JString des NDK ist UTF8, vor allem, weil Google-Ingenieure nicht verrückt sind.
Voo
30

Wenn UTF-8 tatsächlich erweitert werden soll, sollten wir uns das absolute Maximum ansehen, das es darstellen könnte. UTF-8 ist folgendermaßen aufgebaut:

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

(Schamlos aus dem RFC kopiert .) Wir sehen, dass das erste Byte immer steuert, wie viele Folgebytes das aktuelle Zeichen bilden.

Wenn wir es auf bis zu 8 Byte erweitern, erhalten wir die zusätzlichen Nicht-Unicode-Darstellungen

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

Berechnung der maximal möglichen Darstellungen, zu denen wir mit dieser Technik kommen können

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

oder in Basis 10:

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

Dies gibt uns die maximale Anzahl von Darstellungen als 4.468.982.745.216.

Also, wenn diese 4 Milliarden ( oder Billionen, wie Sie möchten ) Zeichen ausreichen, um die fremden Sprachen zu repräsentieren, bin ich ziemlich sicher, dass wir mit minimalem Aufwand die aktuelle UTF-8 erweitern können, um unseren neuen fremden Overlords zu gefallen ;-)

Boldewyn
quelle
8
Derzeit ist UTF-8 auf Codepunkte bis 0x10FFFF beschränkt - dies dient jedoch nur der Kompatibilität mit UTF-16. Wenn es notwendig war, es zu erweitern, gibt es keine Unklarheit darüber, wie es mit Codepunkten bis 0x7FFFFFFF (das ist 2³¹-1) erweitert werden soll. Aber darüber hinaus habe ich widersprüchliche Definitionen gesehen. Eine Definition, die ich gesehen habe 111111xx, enthält ein mögliches erstes Byte, gefolgt von fünf Erweiterungsbytes für maximal 2³² Codepunkte. Dies ist jedoch nur mit der Definition kompatibel, die Sie für die ersten 2³¹-Codepunkte angegeben haben.
Kasperd
2
Ja, Wikipedia sagt etwas über UTF-16 aus, wenn es wirklich Unicode oder ISO 10646 bedeutet (je nach Kontext). Tatsächlich, da RFC 3629, UTF-8 ist über U + 10FFFF (oder undefiniert F4 8F BF BFin UTF-8 Bytes). Alles, was ich hier darüber hinaus erwähne, ist reine Spekulation. Natürlich könnte sich jemand andere Erweiterungen vorstellen, bei denen ein hohes erstes Byte eine andere folgende Struktur anzeigt (und hoffentlich die Selbstsynchronisation dabei nicht zerstört). Ich habe versucht, das Byte-Schema so zu vervollständigen, dass es dem echten UTF-8-Format so nahe wie möglich kommt.
Boldewyn
4
Das sind 4 Billionen, keine Billionen.
Ypnypn
1
Es ist nicht unbedingt erforderlich, dass die Anzahl der folgenden Bytes immer um eins niedriger ist als die Anzahl der führenden Bytes im ersten Byte. Perl unterstützt (seit 2000) eine interne Variante von UTF-8, bei der die 5, 6 und 7-Byte-Formulare mit dieser Antwort identisch sind, führt jedoch FFeine 13-Byte-Codeeinheit ein, die 72 Bit speichern kann. Alles über 2 ^ 36 ist einheitlich sehr teuer, aber es ermöglicht das Codieren eines 64-Bit-Int und noch mehr.
Hobbs
7

RFC3629 beschränkt UTF-8 auf maximal vier Bytes pro Zeichen mit einem Maximalwert von 0x10FFFF, sodass maximal 1.112.064 Codepunkte zulässig sind. Offensichtlich könnte diese Einschränkung aufgehoben und der Standard erweitert werden, aber dies würde eine bahnbrechende Änderung für vorhandenen Code darstellen, der bis zu dieser Grenze funktioniert.

Aus der Sicht von Datendateien wäre dies keine bahnbrechende Änderung, da der Standard davon ausgeht, dass das nächste Byte Teil der Codierung ist, wenn das höchstwertige Bit (MSB) jedes Bytes gesetzt ist. Bereits vor RFC3629 war der Standard auf 31 Bit begrenzt, so dass das MSB des vierten Bytes nicht gesetzt war.

Eine Erweiterung des Standards über 0x10FFFF hinaus würde jedoch die teilweise Datenkompatibilität von UTF-8 mit UTF-16 beeinträchtigen.

David Arno
quelle
5
Theoretisch wären die Daten also abwärtskompatibel, aber der Code wäre von Natur aus nicht kompatibel mit der Änderung des Standards?
Qix
2
@ Qix, das ist ein gültiger Punkt. Jede existierende UTF-8-Datei wäre natürlich mit zB maximal 6 Bytes kompatibel, um Millionen weiterer Codepunkte aufzunehmen, aber viele existierende Bibliotheken, die für UTF-8 entwickelt wurden, würden diese Erweiterung wahrscheinlich nicht verarbeiten.
David Arno
4
UTF-16 würde tödlich brechen. Es kann von Natur aus nur Codepunkte bis zu 0x10FFFF unterstützen.
gnasher729
1
@ gnasher729: Kein so großes Problem wie du denkst. Pre-Unicode löste dies über Shift-Werte (Shift JIS für Japanisch). Sie würden einfach ein reserviertes / unbenutztes Zeichen (0xFFFD?) Als "Umschaltzeichen" markieren, das die Codierung in eine erweiterte Form verschiebt. Wahrscheinlich UTF32.
Mooing Duck 25.11.15
4

Tatsächlich stehen nur 2 Unicode-Code-Punkte für unendlich viele Glyphen, wenn sie Zeichen kombinieren.

Vergleichen Sie beispielsweise die beiden Möglichkeiten, die Unicode für das koreanische Hangul-Alphabet verwendet: Hangul-Silben und Hangul-Jamo . Das Zeichen 웃 in Hangul Syllabelsist der einzelne Codepunkt, C6C3während in Hangul Jamoihm die drei Codepunkte 110B(ㅇ) 116E(ㅜ) 11B9(ㅅ) stehen. Das Kombinieren von Zeichen benötigt offensichtlich erheblich weniger Codepunkte, ist jedoch für das Schreiben weniger effizient, da zum Schreiben jedes Zeichens mehr Bytes erforderlich sind.

Mit diesem Trick muss die Anzahl der Codepunkte, die derzeit in UTF-8 oder UTF-16 codiert werden können, nicht überschritten werden.

Ich denke, es kommt darauf an, wie beleidigt die Außerirdischen wären, wenn ihre Sprache viel mehr Bytes pro Nachricht benötigt als irdische Sprachen. Wenn es ihnen zum Beispiel nichts ausmacht, jede ihrer Millionen Zeichen mit einem Durcheinander von 100.000 Zeichen darzustellen, ist das kein Problem. Auf der anderen Seite, wenn sie gezwungen werden, mehr Bytes als Erdlinge zu verwenden, fühlen sie sich wie Bürger zweiter Klasse, könnten wir in einen Konflikt geraten ( nicht anders als das, was wir bereits mit UTF-8 beobachten ).

Owen
quelle
Dies ist nur der Fall, wenn die Zeichen in der Fremdsprache tatsächlich aus einer begrenzten Menge von Graphemen bestehen. Dies ist möglicherweise nicht der Fall.
JacquesB
1
Soweit mir bekannt ist, besteht keine Anforderung, dass sich das Kombinieren von Zeichen auf einzelne Grapheme beziehen muss. Die Unicode-FAQ schweigen darüber, aber ich habe den Eindruck, dass es für eine Layout-Engine nicht schwieriger sein würde, Kämmsequenzen zu unterstützen, die keine Graphemsequenzen sind, da in beiden Fällen eine vorkompositionierte Glyphe erforderlich wäre.
Owen
Wie lange leben diese Außerirdischen und wie viele Zeichen, die nicht in Grapheme zerlegt werden können, können sie in ihrer Kindheit lernen? Und behält vorkomponiertes Hangul auch nach gzip seinen Byte-Vorteil gegenüber zerlegtem Hangul?
Damian Yerrick
-2

Bearbeiten: Die Frage lautet jetzt "Millionen neuer Charaktere". Dies macht es einfach zu beantworten:

Nein . Utf-8 ist eine Unicode-Codierung. Unicode verfügt über einen Codespace, der 1.114.112 verschiedene Codepunkte zulässt , und weniger als eine Million ist derzeit nicht zugewiesen. Es ist daher nicht möglich, Millionen neuer Zeichen in Unicode zu unterstützen. Per Definition kann keine Unicode-Codierung mehr Zeichen unterstützen als von Unicode definiert. (Natürlich können Sie betrügen, indem Sie eine Ebene weiter kodieren - jede Art von Daten kann immerhin durch nur zwei Zeichen dargestellt werden.)


So beantworten Sie die ursprüngliche Frage:

Unicode unterstützt keine Sprachen als solche, sondern Zeichen - Symbole, mit denen die Sprache in schriftlicher Form dargestellt wird.

Da nicht alle menschlichen Sprachen eine schriftliche Darstellung haben, können nicht alle menschlichen Sprachen von Unicode unterstützt werden. Darüber hinaus kommunizieren viele Tiere, haben aber keine geschriebene Sprache. Wale haben beispielsweise eine Kommunikationsform, die komplex genug ist, um eine Sprache zu nennen, aber keine schriftliche Form hat (und auch nicht mit der vorhandenen phonetischen Notation erfasst werden kann). Somit können nicht einmal alle Sprachen der Welt von Unicode unterstützt werden.

Noch schlimmer ist so etwas wie die Sprache der Bienen. Es hat nicht nur keine schriftliche Form, es kann auch nicht sinnvoll in schriftlicher Form dargestellt werden. Die Sprache ist eine Art Tanz, der grundsätzlich in eine Richtung weist, sich aber auf den aktuellen Sonnenstand stützt. Daher hat der Tanz nur an dem bestimmten Ort und zu dem Zeitpunkt, an dem er aufgeführt wird, einen informativen Wert. Eine symbolische oder textuelle Darstellung müsste Informationen (Standort, Sonnenstand) enthalten, die die Sprache der Bienen derzeit nicht ausdrücken kann.

Sogar eine schriftliche oder symbolische Form der Kommunikation kann möglicherweise nicht in Unicode dargestellt werden. Beispielsweise können Illustrationen oder wortlose Comics von Unicode nicht unterstützt werden, da die Menge der Glyphen nicht endlich ist. Sie werden eine Menge Bildkommunikation in internationalen Umgebungen wie einem Flughafen bemerken, daher ist es nicht unvorstellbar, dass sich eine Rasse von Außerirdischen in der Raumfahrt entwickelt hat, um eine Bildsprache zu verwenden.

Selbst wenn eine fremde Rasse eine Sprache mit einem Schriftsystem mit einem endlichen Satz von Symbolen hätte, könnte dieses System in Unicode möglicherweise nicht unterstützt werden. Unicode erwartet, dass das Schreiben eine lineare Folge von Symbolen ist. Die Musiknotation ist ein Beispiel für ein Schriftsystem, das in Unicode nicht vollständig dargestellt werden kann, da die Bedeutung sowohl bei der Auswahl der Symbole als auch bei der vertikalen und horizontalen Platzierung codiert wird. (Unicode unterstützt einzelne Musiksymbole, kann jedoch keine Partitur codieren.) Eine fremde Rasse, die mit polyphoner Musik (nicht ungewöhnlich) oder einem Kommunikationskanal ähnlicher Komplexität kommuniziert, verfügt möglicherweise über ein Schriftsystem, das wie eine Orchestermusik aussieht Unicode kann dies nicht unterstützen.

Nehmen wir jedoch zum Zwecke der Argumentation an, dass alle Sprachen, auch fremde Sprachen, als lineare Folge von Symbolen ausgedrückt werden können, die aus einer endlichen Menge ausgewählt werden. Ist Unicode groß genug für eine Alien-Invasion? Unicode verfügt derzeit über weniger als eine Million nicht zugeordnete Codepunkte. Die chinesische Sprache enthält nach dem umfassendsten chinesischen Wörterbuch hunderttausende Zeichen (derzeit werden nicht alle von Unicode als unterschiedliche Zeichen unterstützt). Daher würden nur zehn Sprachen mit der Komplexität von Chinesisch den gesamten Unicode-Code verbrauchen. Auf der Erde gibt es Hunderte von unterschiedlichen Schriftsystemen, aber zum Glück sind die meisten eher alphabetisch als ideografisch und enthalten daher nur eine geringe Anzahl von Zeichen. Wenn alle geschriebenen Sprachen Ideogramme wie Chinesisch verwenden würden, wäre Unicode nicht einmal groß genug für die Erde. Die Verwendung von Alphabeten leitet sich aus der Sprache ab, in der nur eine begrenzte Anzahl von Phonemen verwendet wird, dies gilt jedoch insbesondere für die menschliche Physiologie. Selbst ein einziger fremder Planet mit nur einem Dutzend ideografischer Schriftsysteme könnte also über das hinausgehen, was Unicode unterstützen kann. Überlegen Sie nun, ob diese Außerirdischen bereits in andere Planeten vor der Erde eingedrungen sind und ihre Schriftsysteme in den Zeichensatz aufgenommen haben, der unterstützt werden muss.

Die Erweiterung oder Änderung aktueller Codierungen oder die Einführung neuer Codierungen wird dies nicht lösen, da die Beschränkung in der Anzahl der von Unicode unterstützten Codepunkte liegt.

Die Antwort lautet also höchstwahrscheinlich nein.

JacquesB
quelle
5
Ihnen fehlt die Vorstellungskraft. Tanzchoreografen haben eine Menge Sprache und Terminologie, mit denen sie die Tänze beschreiben und unterrichten können, die die Bühnenschauspieler aufführen sollen. Wenn wir erfahren würden, was Bienen miteinander kommunizieren, könnten wir definitiv eine schriftliche Terminologie dafür ausarbeiten. Schließlich sind die meisten unserer heutigen Schriftsprachen eine Kodierung von Ton. Das Kodieren von Bewegungen unterscheidet sich nicht wesentlich vom Kodieren von Ton.
Whatsisname
3
Teile dieser Antwort sind gut, aber zu sagen "Es gibt nicht nur keine schriftliche Form, es kann unmöglich in schriftlicher Form dargestellt werden" ist einfach falsch. Alles, was Informationen vermittelt, kann auf Bits reduziert werden, und alles, was auf Bits reduziert wird, kann in einen beliebigen Strom von Zeichen umgewandelt werden.
Steven Burnap
2
@StevenBurnap Stimmt, aber Unicode ist mehr als nur eine Folge von Bits. Es ist eine Art, diese Bits zu interpretieren, die ziemlich starr ist. Ja, der Unicode-Zeichensatz könnte erweitert werden, um von Bildern bis zu CNC-Anweisungen alles darzustellen, aber dies wäre eine ganz andere Kreatur.
Owen
4
Denken Sie daran, dass die Unicode-Symbole (in den meisten Sprachen) Muster für die Variation des Luftdrucks beschreiben, und dass sie in den meisten Sprachen ziemlich beschissen sind, um diese Muster tatsächlich abzugleichen.
Steven Burnap
3
Du meinst also, der Satz "Fliege 45 Sekunden mit der Sonne 15 Grad nach links, dann fliege 10 Sekunden mit der Sonne 10 Grad nach rechts" ist unmöglich? Es erfordert sicherlich den aktuellen Sonnenstand als Kontext.
Steven Burnap