Binär geordnete Komprimierung für Unicode

Binär geordnete Komprimierung für Unicode (Bocu) ist ein MIME Kompatibler Unicode -Komprimierungsschema. Bocu-1 kombiniert die breite Anwendbarkeit von UTF-8 mit der Kompaktheit von Standardkomprimierungsschema für Unicode (SCSU). Dies Unicode Codierung ist so konzipiert, dass er für die Komprimierung kurzer Zeichenfolgen nützlich ist und die Codepunktreihenfolge verwaltet. BOCU-1 ist in einem technischen Noten von Unicode angegeben.[1]

Zum Vergleich wurde SCSU als Standard-Unicode-Komprimierungsschema mit einem Byte/Code-Punkt-Verhältnis übernommen, das dem Sprachspezifisch ähnlich ist Codeseiten. SCSU wurde nicht weit verbreitet, da es nicht für MIME -Texttypen geeignet ist. Beispielsweise kann SCSU nicht direkt in E -Mails und ähnlichen Protokollen verwendet werden. SCSU benötigt ein kompliziertes Encoderdesign für eine gute Leistung. Normalerweise die Postleitzahl, BZIP2und andere Branchenstandardalgorithmen kompakt größere Mengen an Unicode -Text effizienter.[2]

Beide scsu[3] und Bocu-1[4] sind Iana Registrierte Charsets.

Einzelheiten

Alle Zahlen in diesem Abschnitt sind hexadezimalund alle Bereiche sind inklusiv.

Codepunkte von U+0000 zu U+0020 werden in bocu-1 als entsprechender Bytewert codiert. Alle anderen Codepunkte (dh,, U+0021 durch U+d7ff und U+E000 durch U+10ffff) werden als Unterschied zwischen dem Codepunkt und einer normalisierten Version des zuletzt codierten Codepunkts kodiert, der kein ASCII -Raum war (U+0020). Der Anfangszustand ist U+0040. Die Normalisierungszuordnung lautet wie folgt:

Codebereich Normalisierter Codepunkt Anmerkungen
U+3040 zu U+309f U+3070 Hiragana
U+4e00 zu U+9FA5 U+7711 Unihan
U+AC00 zu U+D7A3 U+C1D1 Hangul
U+0020 Encoderstaat gehalten wie es ist Platz
U+HHHH00 zu U+hhhh7f
(ohne Bereiche oben)
U+HHHH40 Mitte
von 128
U+HHHH80 zu U+HHHHFF
(ohne Bereiche oben)
U+HHHHC0 Mitte
von 128

Der Unterschied zwischen dem aktuellen Codepunkt und dem normalisierten vorherigen Codepunkt wird wie folgt codiert:

Differenzbereich Byte -Sequenzbereich
(siehe unten)
-10ff9f zu -2dd0d 21 F0 58 D9 zu 21 Ff Ff Ff
-2dd0c zu -2912 22 01 01 zu 24 Ff Ff
-2911 zu -41 25 01 zu 4f Ff
-40 zu 3f 50 zu Vgl
40 zu 2910 D0 01 zu FA Ff
2911 zu 2dd0b FB 01 01 zu FD Ff Ff
2dd0c zu 10ffbf Fe 01 01 01 zu Fe 19 B4 54

Jeder Byte -Bereich ist lexikographisch geordnet mit den folgenden dreizehn Byte -Werten ausgeschlossen: 00 07 08 09 0a 0b 0c 0d 0e 0f 1a 1b 20. Zum Beispiel die Bytesequenz FC 06 ff, codieren für einen Unterschied von 1156b, folgt sofort die Byte -Sequenz FC 10 01, codieren für einen Unterschied von 1156c.

Jeder ASCII -Eingang U+0000 zu U+007f ohne Platz U+0020 setzt den Encoder auf U+0040. Weil die oben genannten Werte Zeilen-Endcodepunkte abdecken U+000D und U+000A wie es ist (0d 0a) Der Encoder befindet sich zu Beginn jeder Zeile in einem bekannten Zustand. Die Korruption eines einzelnen Byte beeinflusst daher höchstens eine Zeile. Zum Vergleich die Korruption eines einzelnen Byte in UTF-8 betrifft höchstens einen Codepunkt, denn Scsu Es kann das gesamte Dokument beeinflussen.

BOCU-1 bietet eine ähnliche Robustheit auch für Eingabetexte ohne die oben genannten Werte mit dem speziellen Reset-Code 0xff. Wenn ein Decoder dieses Oktett findet, setzt er seinen Zustand zurück U+0040 Wie für ein Zeilenende. Die Verwendung von 0xff Reset Bytes wird in der Bocu-1-Spezifikation nicht empfohlen, da es mit anderen BOCU-1-Designzielen in Konflikt steht, insbesondere die Binärordnung.

Die optionale Verwendung einer Signatur U+feff Zu Beginn von bocu-1 codierten Texten, d. H. Die Bocu-1-Byte-Sequenz FB EE 28, ändert den Anfangszustand U+0040 zu U+FEC0. Mit anderen Worten, die Signatur kann nicht einfach wie in den meisten anderen Unicode -Codierungsschemata entzogen werden. Hinzufügen eines Reset -Byte nach der Signatur (Fb ee 28 ff) könnte diesen Effekt vermeiden, aber die BOCU-1-Spezifikation empfiehlt diese Praxis nicht.

In der Theorie UTF-1 und UTF-8 könnte das Original codieren UCS-4 Setzen Sie mit 31 Bits bis zu 7fffffff. Bocu-1 und UTF-16 kann die moderne codieren Unicode Set von U+0000 zu U+10ffff. Ohne dreizehn geschützt Codepunkte, die als einzelne Oktetten-Bocu-1 codiert sind, können verwenden Oktetten in Multi-Byte-Codierungen. Bocu-1 benötigt höchstens vier Bytes, die aus einer Lead-Byte und einem bis drei Trail-Bytes bestehen. Die Trail -Bytes codieren eine verbleibende "Modulo 243 "(Basis 243) Differenz, das Lead -Byte bestimmt die Anzahl der Trail -Bytes und eine anfängliche Differenz. Beachten Sie, dass das Reset -Byte zurückgesetzt wird 0xff ist nicht geschützt und kann als Trail -Byte auftreten.

Patent

Der allgemeine Bocu -Algorithmus ist von bedeckt von US -Patent #6,737,994, in dem auch die spezifische BOCU-1-Implementierung erwähnt wird.[5] IBM, der beide Erfinder von Bocu-1 zum Zeitpunkt des Erstellens einsetzte, in dem technischen Hinweis von Unicode, dass Implementierer einer "vollständig konformen Version von bocu-1" sich wenden müssen, um IBM zu beantragen, um eine Lizenzgebühr lizenzfrei zu beantragen.[6] BOCU-1 ist das einzige auf der Unicode-Website beschriebene Unicode-Komprimierungsschema, mit dem bekannt ist, mit dem bekannt ist geistiges Eigentum Beschränkungen.

Im Gegensatz dazu beantragte IBM auch ein Patent auf UTF-EBCDIC, aber es hat in diesem Fall ausgewählt, um die Dokumentation zu machen und Codierungsschema "Frei für alle, die sich als Teil der UCS -Standards befassen, um das Transformationsformat zu erstellen", anstatt die Implementierer zu verlangen, dass sie eine Lizenz anfordern.[7]

Verweise

  1. ^ Markus Scherer, Mark Davis (2006-02-04). "UTN #6: bocu-1". Abgerufen 2008-05-18.
  2. ^ Ewell, Doug (2004-01-30). "UTN #14: Eine Umfrage zur Unicode -Komprimierung" (PDF). Abgerufen 2008-06-13.
  3. ^ IANA -Registrierungsprotokoll für SCSU
  4. ^ IANA-Registrierungsprotokoll für BOCU-1
  5. ^ Davis; et al. (2004-05-18). "US-Patent Nr. 6,737.994", binär geordnete Komprimierung für Unicode "". Abgerufen 2008-11-16.
  6. ^ Markus Scherer, Mark Davis (2006-02-04). "UTN #6: bocu-1". Abgerufen 2014-02-05.
  7. ^ V.S. Umamaheswaran (2002-04-16). "UTR #16: UTF-EBCDIC". Abgerufen 2008-11-16.

Siehe auch