Erweiterter Unix -Code

Erweiterter Unix -Code (EUC) ist ein Multibyte Zeichenkodierung System, das hauptsächlich für verwendet wird japanisch, Koreanisch, und vereinfachtes Chinesisch.

Die am häufigsten verwendeten EUC -Codes sind Codierungen der variablen Breite mit einem Charakter, der einem gehört ISO/IEC 646 konforme codierte Zeichensatz (wie z. ASCII) Einen Byte und ein Zeichen zu einem 94x94 -codierten Zeichensatz (wie z. GB 2312) in zwei Bytes dargestellt. Das EUC-CN Form von GB 2312 und EUC-kr sind Beispiele für solche Zwei-Byte-EUC-Codes. EUC-JP Enthält Charaktere, die von bis zu drei Bytes dargestellt werden, einschließlich einer Initialen Schichtcodewährend ein einzelner Charakter in EUC-TW kann bis zu vier Bytes nehmen.

Moderne Anwendungen verwenden eher UTF-8, was alle Glyphen der EUC -Codes und mehr unterstützt und im Allgemeinen mehr tragbarer mit weniger Anbieterabweichungen und -fehlern ist. EUC ist insbesondere immer noch sehr beliebt EUC-kr für Südkorea.

Codierungsstruktur

Beziehung zwischen gepacktem EUC und anderen 8-Bit ISO 2022 Profile

Die Struktur von EUC basiert auf dem ISO/IEC 2022 Standard, das ein System grafischer Zeichensätze angibt, das mit einer Sequenz der 94 7-Bit-Bytes dargestellt werden kann 0x21–7e oder alternativ 0xa1 -fe, wenn ein achtes Bit verfügbar ist. Dies ermöglicht Sätze von 94 grafischen Zeichen oder 8836 (94)2) Zeichen oder 830584 (943) Figuren. Obwohl zunächst 0x20 und 0x7f immer die waren immer die Platz und Charakter löschen und 0xa0 und 0xff waren ungenutzt, spätere Ausgaben von ISO/IEC 2022 Ermöglichte die Verwendung der Bytes 0xa0 und 0xff (oder 0x20 und 0x7f) innerhalb bestimmter Umstände, sodass die Einbeziehung von 96-Charakter-Mengen ermöglicht. Die Bereiche 0x00–1f und 0x80–9f werden für verwendet C0- und C1 -Kontrollcodes.

EUC ist eine Familie von 8-Bit-Profilen von ISO/IEC 2022im Gegensatz zu 7-Bit-Profilen wie z. ISO-2022-JP. Als solcher nur ISO 2022 Konforme Zeichensätze können EUC -Formulare haben. Bis zu vier codierte Zeichensätze (als G0, G1, G2 und G3 oder als Codesätze 0, 1, 2 und 3) können mit dem EUC -Schema dargestellt werden. Das G0 -Set ist auf eine eingestellt ISO/IEC 646 konform codierter Zeichensatz wie z. US-Ascii, ISO 646: KR (KS x 1003) oder ISO 646: JP (die untere Hälfte von Jis x 0201) und über GL aufgerufen (d. H. 0x21–0x7e, mit dem bedeutendsten Bit geräumt).[1] Wenn US-ASCII verwendet wird, macht der Code ein erweiterte ASCII Codierung; Die häufigste Abweichung von US-ASCII ist das 0x5c (Backslash in US-Ascii) wird oft verwendet, um a zu repräsentieren Yen Zeichen in EUC-JP (siehe unten) und a gewonnenes Zeichen in EUC-kr.

Die anderen Code -Sets werden über GR aufgerufen (d. H. Mit dem bedeutendsten Bit -Set). Um die EUC-Form eines Zeichens zu erhalten, ist das wichtigste Bit jedes Codierungs-Byte festgelegt (entspricht dem Hinzufügen von 128 zu jedem 7-Bit-Codierungs-Byte oder dem Hinzufügen von 160 zu jeder Zahl in der Kuten Code); Dadurch kann Software leicht unterscheiden, ob ein bestimmtes Byte in a Zeichenkette gehört zum ISO 646 Code oder der erweiterte Code. Zeichen in den Codesätzen 2 und 3 werden mit den Steuercodes vorangestellt SS2 (0x8e) und SS3 (0x8f) jeweils und übergr. Neben dem anfänglichen Schaltcode ist ein Byte außerhalb des Bereichs 0xa0–0xff, der in einem Zeichen aus den Codesätzen 1 bis 3 auftritt, kein gültiger EUC -Code.[1]

Der EUC -Code selbst nutzt die Ankündigungs- und Bezeichnungssequenzen nicht ISO 2022.[1] Die Codespezifikation entspricht jedoch der folgenden Abfolge von vier ISO 2022 Ankündigungssequenzen, wobei die Bedeutungen wie folgt zusammenbrechen.[1]

Individuelle Sequenz Hexadezimal Merkmal von EUC bezeichnet
Esc sp c 1b 20 43 ISO-8 (8-Bit, G0 in GL, G1 in gr)
Esc sp z 1b 20 5a G2 Zugegriffen mit SS2
Esc sp [ 1b 20 5b G3 Zugegriffen mit SS3
Esc sp \ 1b 20 5c Single-Shifts rufen sich über GR an

Fixed-Width-Format

Layout des Fixed-Width-Formats für Japanisch

Die ISO-2022 basiert Codierung der variablen Breite oben beschrieben wird manchmal als die bezeichnet EUC -gepacktes Format, was das Codierungsformat ist, das normalerweise als EUC gekennzeichnet ist. Die interne Verarbeitung von EUC-Daten kann jedoch ein Format mit fester Breite verwenden, das als das genannt wird EUC vollständiges Zwei-Byte-Format. Dies ist:[2]

  • Code set 0 als zwei Bytes im Bereich 0x21–0x7e (mit der Ausnahme, dass der erste möglicherweise 0x00 ist).
  • Der Code setzt 1 als zwei Bytes im Bereich 0xa0–0xff (mit der Ausnahme, dass der erste möglicherweise 0x80 ist).
  • Code Set 2 als Byte im Bereich 0x21–0x7e (oder 0x00), gefolgt von einem Byte im Bereich 0xa0–0x.
  • Code Set 3 als Byte im Bereich 0xa0–0xff (oder 0x80), gefolgt von einem Byte im Bereich 0x21–0x7e.

Anfangs Bytes von 0x00 und 0x80 werden in Fällen verwendet, in denen der Code -Set nur ein Byte verwendet. Es gibt auch ein vier-Byte-Format mit fester Länge.[2] Diese Codierungsformate mit fester Länge sind für die interne Verarbeitung geeignet und werden normalerweise nicht im Austausch auftreten.

EUC-JP ist in beiden Formaten bei der IANA registriert, das verpackte Format als "EUC-JP" oder "CSEUCPKDFMTJAPANEES" und das Format fester Breite als "cseucfixwidjapanese".[3] Nur das verpackte Format ist in der enthalten Waswg Codierungsstandard verwendet von HTML5.[4]

EUC-CN

EUC-CN
EUCCN encoding.svg
Mime / Iana GB2312
Alias ​​(e) CSGB2312
Sprachen) Vereinfachtes Chinesisch, Englisch, Russisch
Standard GB 2312 (1980)
Einstufung Erweiterte ASCII, Codierung der variablen Breite, CJK -Codierung, EUC
Erweitert US-Ascii
Erweiterungen 748, GBK, GB 18030, x-mac-chinesimp
Transformationen / codiert GB 2312
gefolgt von GBK, GB 18030

EUC-CN[5] ist die übliche codierte Form der GB 2312 Standard für vereinfachte chinesische Charaktere. Im Gegensatz zu Japanisch Jis x 0208 und ISO-2022-JP, GB 2312 wird normalerweise nicht in einem 7-Bit verwendet ISO 2022 Codeversion,[a] Obwohl eine variante Form genannt wird Hz (was begrenzt GB 2312 Text mit ASCII -Sequenzen) wurde manchmal verwendet Usenet.

Ein ASCII -Charakter wird in seiner üblichen Codierung dargestellt. Ein Charakter von GB 2312 wird durch zwei Bytes dargestellt, beide aus dem Bereich 0xa1–0xfe.

Verwandte chinesische Kodierungssysteme für chinesische Festlande

748 Code

Eine Codierung im Zusammenhang mit EUC-CN ist der "748" -Codescodes, der im Wits-Typen-System verwendet wird, das von der Gründertechnologie von Peking (jetzt von seinem neueren Anpassungssystem veraltet) entwickelt wurde. Der 748 -Code enthält alle von GB 2312, aber nicht ISO 2022–Compliant und daher kein wahrer EUC -Code. (Es verwendet ein 8-Bit Die großen 5 und andere Nicht -ISO 2022 -Compliant DBCs Codierungssysteme.) Der nicht gb2312-Teil des 748-Codes enthält traditionelle und Hongkong-Zeichen und andere Glyphen, die bei Zeitungsarten verwendet werden.

IBM -Code Seiten 1380, 1381, 1382 und 1383

IBM Code Seite 1381 (Ccsid 1381) umfasst die Single-Byte Code Seite 1115 (CPGID 1115 als CCSID 1115) und der Doppel-Byte-Code-Seite 1380 (CPGID 1380 als CCSID 1380),[6] Das codiert GB 2312 auf die gleiche Weise wie EUC-CN, abweicht jedoch von der EUC-Struktur, indem der Lead-Byte-Bereich wieder auf 0x8c erweitert wird, 31 IBM-ausgewählte Zeichen in 0x8ce0 bis 0x8cfe und zusätzlich 1880 Hinzufügen von 1880 Hinzufügen Benutzerdefinierte Zeichen mit Lead -Bytes 0x8d bis 0xa0.[7]

IBM Code Seite 1383 (CCSID 1383) umfasst die Single-Byte Code Seite 367 und die Doppel-Byte-Code Seite 1382 (CPGID 1382 als CCSID 1382),[8] Dies unterscheidet sich durch die Übereinstimmung mit der EUC-Struktur, das Hinzufügen der 31 IBM-ausgewählten Zeichen in 0xfee0 bis 0xFEFE stattdessen und nur 1360 benutzerdefinierte Zeichen, die in die von GB 2312 nicht verwendeten Positionen untersagt sind.[9] Das alternative CCSID 5479[10] wird für die Seite Pure EUC-CN-Code verwendet: Es verwendet CCSID 9574 als Doppel-Byte-Set, das CPGID 1382 verwendet, jedoch die von IBM ausgewählten und benutzerdefinierten Zeichen ausgeschlossen.[11]

GBK und GB 18030

Hauptartikel: GBK (Charaktercodierung) und GB 18030

GBK ist eine Erweiterung an GB 2312. Es definiert eine erweiterte Form der EUC-CN-Codierung, die eine größere Array von darstellen kann CJK -Charaktere Begründet weitgehend von Unicode 1.1, einschließlich traditionelles Chinesisch Charaktere und Zeichen nur in verwendet in japanisch. Es ist jedoch kein wahrer EUC -Code, da ASCII -Bytes als Trail -Bytes erscheinen können (und C1 -Bytes, nicht auf die einzelnen Schichten beschränkt, können als Blei- oder Trail -Bytes erscheinen), da ein größerer Codierungsraum erforderlich ist.

Varianten von GBK werden durch implementiert Windows -Code Seite 936 (das Microsoft Windows Codepage für vereinfachtes Chinesisch) und nach IBM -Code Seite 1386.

Die unicode-basierten GB 18030 Charaktercodierung definiert eine Erweiterung von GBK, die die gesamte Gesamtheit codieren kann Unicode. Unicode kodierte jedoch als GB 18030 ist ein Codierung der variablen Breite Dies kann bis zu vier Bytes pro Charakter verwenden, da ein noch größerer Codierungsraum erforderlich ist. Da es sich um eine Erweiterung von GBK handelt, handelt es sich um ein Superet von EUC-CN, aber selbst kein eutiger EUC-Code. Als Unicode -Codierung ist sein Repertoire mit dem anderer identisch Unicode -Transformationsformate wie zum Beispiel UTF-8.

Mac OS Chinese vereinfacht

Andere EUC-CN-Varianten, die vom EUC-Mechanismus abweichen, umfassen die Mac OS Chinesisch vereinfachtes Skript (bekannt als Code Seite 10008 oder x-mac-chinesimp).[12] Es verwendet die Bytes 0x80, 0x81, 0x82, 0xa0, 0xfd, 0xfe und 0xff für die U mit Umlaut (ü), zwei spezielle Schriftarten mit Schriftarten, die, die Nicht bahnbrechender Raum, das Urheberrechtszeichen (©), die Markenzeichen (™) bzw. die Ellipse (…).[5] Dies unterscheidet sich in einem als Single-Byte-Charakter angesehen gegenüber dem ersten Byte eines Zwei-Byte-Charakters von EUC (wobei von diesen, 0xfd und 0xFe als Lead-Byte definiert werden) und GBK (wo, 0x81, 0x82, 0xfd und 0xfe sind als Hauptbytes definiert).

Diese Verwendung von 0xa0, 0xfd, 0xfe und 0xff übereinstimmt Apples Shift_jis Variante.

Neben diesen Änderungen am Blei-Byte-Bereich ist das andere charakteristische Merkmal des Doppel-Byte-Teils von Mac OS Chinese vereinfacht die Einbeziehung von zwei Erweiterungen in den in den Zeilen 6 und 8 festgelegten Basis-GB 2312-80.[5] Diese gelten als "Standardverlängerungen zu GB 2312", von denen keiner für Apple in Eignung ist: Die Erweiterung der Reihe 8 wurde von entnommen GB 6345.1,[5] Beide Erweiterungen sind von GB/T 12345 (der traditionellen chinesischen Variante von GB 2312) enthalten.[13] und beide Erweiterungen sind von enthalten von GB 18030 (Der Nachfolger von GB 2312).[14]

EUC-JP

EUC-JP
EUC-JP.svg
Mime / Iana EUC-JP
Alias ​​(e) Unmixisierte JIS (UJIS), CSEUCPKDFMTJAPANEESE
Sprachen) japanisch, Englisch, Russisch
Einstufung Erweitert ISO 646, Codierung der variablen Breite, CJK -Codierung, EUC
Erweitert US-Ascii oder ISO 646: JP
Transformationen / codiert Jis x 0208, Jis x 0212, Jis x 0201
gefolgt von EUC-JISX0213
EUC-JIS-2004
EUC-JISx0213.svg
Alias ​​(e) EUC-JISX0213
Sprachen) japanisch, Ainu, Englisch, Russisch
Standard Jis x 0213
Einstufung Erweiterte ASCII, Codierung der variablen Breite, CJK -Codierung, EUC
Erweitert US-Ascii
Transformationen / codiert Jis x 0213, Jis x 0201 (Kana)
Vorausgegangen von EUC-JP

EUC-JP ist ein Codierung der variablen Breite Wird verwendet, um die Elemente von drei darzustellen Japanische Charakter -Set -Standards, nämlich Jis x 0208, Jis x 0212, und Jis x 0201. Andere Namen für diese Codierung umfassen Unmixed jis (oder Ujis) und AT & T jis.[2] 0,1% aller Webseiten verwenden EUC-JP seit August 2018,[15] während 2,5% der Websites in Japanisch diese Codierung verwenden[16] (weniger verwendet als als Schicht jis, oder UTF-8). Es wird genannt Code Seite 954 von IBM.[17][18] Microsoft verfügt über zwei Code -Seitenzahlen für diese Codierung (51932 und 20932).

Dieses Codierungsschema ermöglicht das einfache Mischen von 7-Bit-ASCII und 8-Bit-Japanisch, ohne dass die Fluchtzeichen erforderlich sind ISO-2022-JP, was auf den gleichen Zeichenstandsstandards basiert und ohne ASCII -Bytes als Trail -Bytes (im Gegensatz zu Schicht jis).

Eine verwandte und teilweise kompatible Codierung, genannt EUC-JISX0213 oder EUC-JIS-2004, codiert Jis x 0201 und Jis x 0213[19] (ähnlich zu Revers_jisx0213, sein Shift_JIS-basiertes Gegenstück).

Im Vergleich zu EUC-CN oder EUC-KR wurde EUC-JP auf PC- und Macintosh-Systemen in Japan nicht so weit verbreitet, was verwendet wurde Schicht jis oder seine Verlängerungen (Windows -Code Seite 932 an Microsoft Windows, und Makjapaner an Klassischer Mac OS), obwohl es stark benutzt wurde von Unix oder Unix-ähnlich Betriebssysteme (ausser für HP-UX). Ob japanische Websites EUC-JP oder Shift_JIS verwenden, hängt daher häufig davon ab, welches Betriebssystem der Autor verwendet.

Zeichen werden wie folgt codiert:

  • Als EUC/ISO 2022 konforme Codierung, die C0 -Steuerzeichen, Space und DEL sind wie in ASCII dargestellt.
  • Ein grafischer Charakter von ASCII (Code Set 0) wird als übliche Ein-Byte-Darstellung im Bereich 0x21-0x7e dargestellt. Während einige Varianten von EUC-JP die codieren untere Hälfte von Jis x 0201 Hier codieren die meisten ASCII,[20] einschließlich des W3C/Whatwg -Codierungsstandards, der von verwendet wird HTML5,[21] Und EUC-JIS-2004 auch.[19] Dies bedeutet zwar, dass 0x5c typischerweise als U+005C Reverse Solidus (die ASCII Backslash) U+005c kann als a angezeigt werden Yen Zeichen von bestimmten Japaner-Lokal-Schriftarten, z. Auf Microsoft Windows für Kompatibilität mit der unteren Hälfte von Jis x 0201.[22][23]
  • Ein Zeichen von JIS x 0208 (Code -Set 1) wird durch zwei Bytes dargestellt, beide im Bereich 0xa1 - 0x. Dies unterscheidet sich von der ISO-2022-JP-Darstellung, indem das Hochbit festgelegt wird. Dieser Codesatz kann auch Anbieter-Erweiterungen in einigen EUC-JP-Varianten enthalten. In EUC-JIS-2004 die erste Ebene von Jis x 0213 ist hier codiert, was effektiv ein Superset von Standard ist Jis x 0208.[19]
  • Ein Charakter aus dem obere Hälfte von Jis x 0201 (Halbbreite Kana, Code Set 2) wird durch zwei Bytes dargestellt, wobei der erste 0x8e ist, der zweite ist das übliche Jis x 0201 Darstellung im Bereich 0xa1 - 0xDF. Dieser Satz kann enthalten IBM -Anbieter -Erweiterungen In einigen Varianten.
  • Ein Zeichen von JIS x 0212 (Code-Set 3) wird in EUC-JP durch drei Bytes dargestellt, wobei die erste 0x8f ist, wobei die folgenden zwei im Bereich 0xa1–0xfa, d. H. Mit dem hohen Bit-Set. Neben Standard Jis x 0212, Code-Set 3 einiger EUC-JP und einer durch die definiert OSF.[24][25] In EUC-JIS-2004 die zweite Ebene von Jis x 0213 ist hier codiert,[19] das kollidiert nicht mit den zugewiesenen Zeilen in Standard Jis x 0212.[26] Einige Implementierungen von EUC-JIS-2004, wie die von verwendeten von Python, erlauben Sie beides Jis x 0212 und Jis x 0213 Ebene 2 Zeichen in diesem Satz.[26]

Verwandte japanische Codierungsmethoden

Anbieter Erweiterungen an EUC-JP (zum Beispiel der von der Open Software Foundation, IBM oder NEC) wurden häufig innerhalb der einzelnen Codesätze zugewiesen,[24][25] im Gegensatz zur Verwendung ungültiger EUC-Sequenzen (wie in beliebten Erweiterungen von EUC-CN und EUC-KR).

Einige näherspezifische Kodierungen sind jedoch aufgrund der Codierung teilweise mit EUC-JP kompatibel Jis x 0208 über GR, aber nicht der gepackten EUC -Struktur folgen. Oft beinhalten diese nicht die Verwendung der einzelnen Verschiebungen von EUC-JP und sind daher keine geraden Erweiterungen von EUC-JP, mit Ausnahme von Super Dec. Kanji.

Dec Kanji

Digital Equipment Corporation Definiert zwei Varianten von EUC-JP, die nur teilweise mit dem EUC-gepackten Format entspricht, aber auch die Ähnlichkeit mit dem vollständigen Zwei-Byte-Format aufweist. Das Gesamtformat der "Dec Kanji" -Codierung entspricht hauptsächlich der EUC mit fester Breite (vollständiger Zwei-Byte); Der Codesatz 0 ist jedoch nicht erforderlich, um mit Null-Bytes (ähnlich wie beim verpackten Format) links aufgepeppt zu werden.[27] JIS X 0208 wird wie üblich für den Codesatz 1 verwendet. Code Set 2 (Half-Breiten-Katakana) fehlt; Der Codesatz 3 ist wie das Zwei-Byte-Format feste Breite (d. H. Ohne Schaltbyte und nur mit dem ersten Hochbit-Set) codiert, wird jedoch für zwei Byte-benutzerdefinierte Zeichen verwendet, anstatt für JIS X 0212 angegeben zu werden.[27] In der grundlegenden "Dec Kanji" -Codierung werden nur die ersten 31 Zeilen des Codesatzes 3 für benutzerdefinierte Zeichen verwendet: Zeilen 32 bis 94 sind reserviert, ähnlich wie die nicht verwendeten Zeilen in Code-Set 1.[28]

Die "Super Dec Kanji" -Codierung akzeptiert Codes sowohl aus der "Dec Kanji" -Codierung als auch aus EUC mit gepacktem Format für insgesamt fünf Code-Sets.[27] Außerdem ermöglicht es dem gesamten benutzerdefinierten Codesatz und den nicht verwendeten Zeilen am Ende des JIS X 0208- und JIS X 0212-Codesätze (Zeilen 85–94 bzw. 78–94), die für benutzerdefinierte Zeichen verwendet werden.[28]

HP-16

Hewlett Packard definiert eine Codierung, die als "HP-16" bezeichnet wird. Dies begleitet ihre "HP-15" -Codierung, eine Variante von Schicht jis. HP-16 codiert Jis x 0208 Verwenden Sie dieselben Bytes wie in EUC-JP, verwenden jedoch nicht die einzelnen Schaltcodes (somit CODE Setzt 2 und 3) und fügt drei benutzerdefinierte Regionen hinzu, die der gepackten Format-EUC-Struktur nicht folgen:[27]

  • Blei Byte 0xa1 - C2, Trail Bytes 0x21–7e
  • Lead -Bytes 0xc3 - E3, Trail Bytes 0x21–3f
  • Lead -Bytes 0xc3 - E1, Trail Bytes 0x40–64

Ikis

Die IKIS (Interactive Kanji Information System) Codierung von verwendet von Daten allgemein ähnelt EUC-JP ohne einzelne Verschiebungen, d. H. Mit nur Codesätzen 0 und 1. halbbreitth katakana sind stattdessen in Zeile 8 von JIS X 0208 aufgenommen (kollidiert mit den Box-Dreisch-Zeichen, die 1983 zum Standard hinzugefügt wurden). JIS X 0208 Zeilen 9 bis 12 werden für benutzerdefinierte Zeichen verwendet.[27][28]

Anpassungen von EUC-JP für EBCDIC

Hauptartikel: Japanische Sprache in Ebcdic

Keis (Kanji-Processing Extended Information System) ist ein Ebcdic Codierung verwendet von Hitachi,[28] mit Doppel-Byte-Zeichen (eine DBCS-Host-Codierung), die mit verschiebenden Sequenzen eingeschlossen ist, wodurch es a Staatsbürgerlich Codierung. Speziell die Sequenz 0x0A 0x41 Schaltet in den Single-Byte-Modus und die Sequenz um 0x0A 0x42 Schaltet in den Doppel-Byte-Modus.[b] JIS X 0208-Zeichen werden jedoch unter Verwendung der gleichen Byte-Sequenzen codiert, die zur Codierung in EUC-JP verwendet werden. Dies führt zu doppelten Codierungen für die ideografischer Raum—0x4040 pro DBCS-Host-Codestruktur und 0xa1a1 wie in EUC-JP. Dies unterscheidet sich von der DBCS-Host-Codierung von IBM für Japaner, dessen Layout auf Versionen aufbaut, die vor JIS X 0208 insgesamt herstellen. Die Lead-Byte-Reichweite wird auf 0x59 erweitert, aus der die Lead-Bytes 0x81-A0 für benutzerdefinierte Zeichen ausgewiesen sind.[27] Und der Rest wird für korporative Charaktere verwendet, einschließlich Kanji und Nicht-Kanji.[28]

JEF (Japanische Verarbeitung erweiterter Feature)[28] ist eine Ebcdic -Codierung, die auf verwendet wird Fujitsu FACOM -Mainframes im Gegensatz zu FMR (eine Variante von Shift -JIs), die auf Fujitsu -PCs verwendet wird. JEF ist wie Keis eine staatliche Codierung, die unter Verwendung von Verschiebungssequenzen (wo wo 0x29 Schaltet in den Single-Byte-Modus und 0x28 Schaltet in den Doppel-Byte-Modus).[29] Ebenso wie Keis sind JIS X 0208-Codes wie in EUC-JP dargestellt.[27] Der Lead -Byte -Bereich wird auf 0x41 erweitert, wobei 0x80 - A0 für die Benutzerdefinition festgelegt ist. Lead -Bytes 0x41–7f werden Zeilennummern 101 bis 163 für zugewiesen Kuten Zwecke, obwohl Zeile 162 (Lead -Byte 0x7e) nicht genutzt wird.[27][28] Die Zeilen 101 bis 148 werden für erweiterte Kanji verwendet, während die Zeilen 149 bis 163 für erweiterte Nicht-Kanji verwendet werden.[28]

EUC-kr

"EUC-kr" leitet hier weiter. Für die in HTML -Standards so genannte Variante siehe Einheitlicher Hangul -Code.
EUC-kr
EUC-KR without extensions.svg
EUC-KR-Codestruktur
Mime / Iana EUC-kr
Alias ​​(e) Wansung, IBM-970
Sprachen) Koreanisch, Englisch, Russisch
Standard KS x 2901 (KS C 5861)
Einstufung Erweitert ISO 646, Codierung der variablen Breite, CJK -Codierung, EUC
Erweitert US-Ascii oder ISO 646: KR
Erweiterungen Mac OS Koreanisch, IBM-949, Unified Hangul Code (Windows-949)
Transformationen / codiert KS x 1001
gefolgt von Einheitlicher Hangul -Code (Webstandards)

EUC-kr ist ein Codierung der variablen Breite um den koreanischen Text mit zwei codierten Zeichensätzen darzustellen, KS x 1001 (ehemals KS C 5601)[30][31] und entweder ISO 646: Kr (KS x 1003früher KS C 5636) oder US-Ascii, abhängig von der Variante. KS x 2901 (früher KS C 5861) festlegt die Codierung und RFC 1557 Als EUC-KR bezeichnet.

Ein aus KS x 1001 (G1, Code -Set 1) gezogener Zeichen ist als zwei Bytes in GR (0xa1–0xfe) und ein Zeichen von KS x 1003 oder US-ASCII (G0, Code Set 0) nimmt ein Byte in GL (0x21–0x7e).

Es wird normalerweise als Wansung bezeichnet (Koreanisch: 완성, romanisiert:Wanseong, zündete. 'Vorkomponiert[32]') in dem Republik Korea. IBM bezieht sich auf die Doppel-Byte-Komponente als Code Seite 971,[33] und zu euc-kR mit ASCII als Code Seite 970.[34][35][36] Es wird implementiert als Code Seite 20949 ("Koreanische Wansung")[37][38] und Code Seite 51949 ("EUC Koreanisch") von Microsoft.[37]

Ab Juni 2022, weniger als 0,1% aller Webseiten weltweit verwenden EUC-KR,[15] 5,9% der südkoreanischen Webseiten verwenden jedoch EUC-KR[39] Machen Sie es zum beliebtesten Nicht-NichtsUTF-8/Unicode -Codierung für eine Sprach-/Webdomäne.[40] Einschließlich Erweiterungen ist die am häufigsten verwendete Legacy -Charakter -Codierung in Korea auf allen drei Hauptplattformen (Mac OS, andere unixartige Osen und Fenster), aber seine Verwendung hat sich sehr langsam verschoben UTF-8 Da es immer beliebter wird, insbesondere unter Linux und MacOS.

Wie bei den meisten anderen Codierungen, UTF-8 wird jetzt für den neuen Gebrauch bevorzugt und Probleme mit Konsistenz zwischen Plattformen und Anbietern gelöst.

Verwandte koreanische Codierungssysteme

Einheitlicher Hangul -Code

Hauptartikel: Einheitlicher Hangul -Code

Eine gemeinsame Erweiterung von EUC-KR ist die Einheitlicher Hangul -Code (통합형 한글 코드, Tonghabhyeong Hangeul Kodeu,[41] oder 통합 완성형, Tonghab Wansunghyung), das standardmäßige koreanische Codepage auf Microsoft Windows. Es wird von Microsoft und 1261 die Code -Seite Nummer 949 und 1261 angegeben[42] oder 1363[43] von IBM. IBMs Code Seite 949 ist eine andere, nicht verwandte EUC-KR-Erweiterung.

Unified Hangul Code erweitert EUC-KR mithilfe von Codes, die nicht der EUC-Struktur entsprechen, um zusätzliche Silbenblöcke zu enthalten, wodurch die Abdeckung der in den verfügbaren komponierten Silbenblöcken in die in verfügbaren in den verfügbaren in den verfügbaren Silbenblöcken entspricht. Johab und Unicode. Das W3c/Waswg Codierungsstandard verwendet von HTML5 Integriert die einheitlichen Hangul-Code-Erweiterungen in seine Definition von EUC-KR.[44]

Mac OS Korean (Hangultalk)

Andere Codierungen, die EUC-KR als Teilmenge einbeziehen X-Mac-Korean),[12] die von Hangultalk (macos-kh) verwendet wurde, die koreanische Lokalisierung der Klassischer Mac OS. Es wurde von Elex Computer (entwickelt (일렉스), die zu dem Zeitpunkt der autorisierte Händler von Apple Macintosh Computern in Südkorea waren.[45][28]

Hangultalk fügt Erweiterungszeichen mit Lead-Bytes zwischen 0xa1 und 0xad hinzu, sowohl im nicht verwendeten Raum innerhalb der EUC-KR GR-Ebene (Trail-Bytes 0xa1–0xFe) als auch mit Nicht-EUC-Codes außerhalb davon (Trail-Bytes 0x41–0xa0). Einige dieser Charaktere sind mit einem Schrift im Schriftstil-unabhängigen stilisierten Stil Dingbats.[28] Viele dieser Zeichen haben keine genauen Unicode -Mappings, und Apple Software ordnet diese Fälle unterschiedlich zu Kombinieren von Sequenzen, um die Zuordnungen mit einem angehängten Abbildungen zu nähern privater Gebrauch Charakter als Modifikator für Hin- und Rückflugzwecke oder für private Nutzungszeichen.[46]

Apple verwendet auch bestimmte Single-Byte-Codes außerhalb der EUC-KR-Ebene für zusätzliche Zeichen: 0x80 für a Erforderlicher Platz, 0x81 für a gewonnenes Zeichen (₩), 0x82 für eine en Dash ( -), 0x83 für a Urheberrechtszeichen (©), 0x84 für eine breite unterstreichen (＿) und 0xff für eine Ellipse (…).[46] Obwohl keiner dieser zusätzlichen Single-Byte-Codes innerhalb des Blei-Byte-Bereichs von einfachem EUC-KR liegt (im Gegensatz zu den Erweiterungen von Apple zu EUC-CN,, siehe oben), Einige befinden sich im Lead -Byte -Bereich des Unified Hangul -Code (insbesondere des 0x81, 0x82, 0x83 und 0x84).

EUC-KP

Hauptartikel: KPS 9566

Ähnlich wie Ks x 1001, der Nordkoreaner KPS 9566 Standard wird typischerweise in EUC -Form verwendet; In diesen Kontexten wird es manchmal als EUC-KP bezeichnet.[47] Neuere Ausgaben des Standards erweitern die EUC-Darstellung mit Zeichen mit Nicht-EUC-Zwei-Byte-Codes auf ähnliche Weise wie ein Unified Hangul-Code.[48]

EUC-TW

EUC-TW ist ein Codierung der variablen Breite das unterstützt US-ASCII und 16 Ebenen von ZNS 11643jedes davon ist 94x94. Es ist eine selten verwendete Codierung für Traditionelle chinesische Charaktere wie in Taiwan. Varianten von Die großen 5 sind viel häufiger als EUC-TW, obwohl Big5 nur die ersten beiden Ebenen von ZNS 11643 codiert Hanzi, während UTF-8 wird häufiger.

  • Als EUC/ISO 2022 Codierung, die C0 -Steuerzeichen, ASCII -Raum und Del sind wie in ASCII codiert.
  • Ein grafisches Zeichen von US-ASCII (G0, Code Set 0) wird in GL als übliche Einzel-Byte-Darstellung (0x21–0x7e) codiert.
  • Ein Zeichen aus ZNS 11643 -Ebene 1 (Code -Set 1) wird als zwei Bytes in GR (0xa1–0xfe) codiert.
  • Ein Zeichen in Ebene 1 bis 16 von ZNS 11643 (Code Set 2) wird als vier Bytes codiert:
    • Das erste Byte ist immer 0x8e (Single Shift 2).
    • Das zweite Byte (0xa1–0xb0) zeigt die Ebene an, deren Anzahl durch Subtrahieren von 0xa0 von diesem Byte erhalten wird.
    • Die dritte und vierte Bytes befinden sich in GR (0xa1–0xfe).

Beachten Sie, dass die Ebene 1 von ZNS 11643 zweimal als Code -Set 1 und Teil des Codesatzes 2 codiert wird.

Siehe auch

Anmerkungen

  1. ^ 7-Bit ISO 2022 Code-Versionen unterstützend GB 2312 enthalten ISO-2022-CN (mit Schaltcodes) und ISO-2022-JP-2 (ohne Schichtcodes), die beide auch andere Nicht-ASCII-Sätze unterstützen.
  2. ^ Diese Sequenzen stimmen mit den hexadezimalen Formen überein[29] und die Dezimalformen (10 65 und 10 66) aufgeführt von Lunde.[27] Lunde listet die hexadezimalen Formen für beide auf 0xA0 0x42, scheinbar fehlerhaft.

Verweise

  1. ^ a b c d IBM. "Charakterdatenrepräsentationsarchitektur (CDRA)". IBM. S. 157–162.
  2. ^ a b c Lunde, Ken (2008). CJKV -Informationsverarbeitung: Chinesisch, Japanisch, Koreanisch und Vietnamesisches Computer. O'Reilly. S. 242–244. ISBN 9780596800925.
  3. ^ "Charaktersätze". Iana.
  4. ^ "4.2. Namen und Etiketten". Codierungsstandard. Waswg.
  5. ^ a b c d "Karte (externe Version) von Mac OS Chinese vereinfachte Codierung zu Unicode 3.0 und später". Apple Inc.
  6. ^ "S-CH-PC-Daten gemischt (IBM GB), einschließlich 1880 UDC, 31 IBM ausgewählte Zeichen und 5 SAA-SB-Zeichen". IBM Globalisierung: Codierte Zeichensatzkennungen. IBM. Archiviert von das Original am 2016-03-26.
  7. ^ "IBM vereinfachte chinesische grafische Zeichenset" (PDF). IBM. 1993. C-H 3-3220-130 1993-11.
  8. ^ "CCSID 1383: S-CH EUC G0 SET, ASCII G1 SET, GB 2312-80 SET (1382)". IBM Globalisierung: Codierte Zeichensatzkennungen. IBM. Archiviert von das Original am 2016-03-28.
  9. ^ "IBM vereinfachte chinesische Grafikzeichen für den erweiterten Unix -Code (EUC)" (PDF). IBM. 1994. C-H 3-3220-132 1994-06.
  10. ^ "CCSID 5479: S-CH EUC G0 SET, ASCII G1 SET, GB 2312-80 SET (5478)". IBM Globalisierung: Codierte Zeichensatzkennungen. IBM. Archiviert von das Original am 2016-03-27.
  11. ^ "CCSID 9574: S-CH DBCS PC GB 2312-80 Set ohne 31 IBM ausgewählt und 1360 UDC. Auch in T-CH 2022-CN TCP verwendet". IBM Globalisierung: Codierte Zeichensatzkennungen. IBM. Archiviert von das Original am 2016-03-27.
  12. ^ a b "Coding.WindowsCodePage -Eigenschaft - .NET Framework (aktuelle Version)". Msdn. Microsoft.
  13. ^ Lunde, Ken (1998). Anhang F: GB/T 12345 (PDF). CJKV -Informationsverarbeitung. O'Reilly Media. ISBN 9781565922242.
  14. ^ Standardisierungsverwaltung Chinas (SAC) (2005-11-18). GB 18030-2005: Informationstechnologie-Chinesen codierter Charaktersatz.
  15. ^ a b "Historische Trends bei der Verwendung von Charaktercodierungen für Websites". W3techs.
  16. ^ "Verteilung von Charaktercodierungen auf Websites, die Japanisch verwenden". w3techs.com. Abgerufen 2022-03-31.
  17. ^ "CCSID 954 Informationsdokument". Archiviert von das Original am 2016-03-27.
  18. ^ Internationale Komponenten für Unicode (ICU), IBM-954_P101-2007.UCM, 2002-12-03
  19. ^ a b c d "JIS X 0213 Code -Mapping -Tabellen". x0213.org.
  20. ^ "Ambiguitäten bei der Bekehrung von japanischen EUC zu Unicode (nicht normativ)". XML Japanisches Profil. W3c.
  21. ^ "EUC-JP-Decoder". Codierungsstandard. Waswg. "Wenn Byte ein ASCII -Byte ist, geben Sie einen Codepunkt zurück, dessen Wert Byte ist."
  22. ^ "3.1.1 Details zu Problemen". Probleme und Lösungen für Unicode- und Benutzer-/Anbieter definierte Zeichen. Die offene Gruppe Japan. Archiviert von das Original Am 1999-02-03. Abgerufen 2019-08-14.
  23. ^ Kaplan, Michael S. (2005-09-17). "Wann ist ein Backslash kein Backslash?".
  24. ^ a b "4.2 Überprüfen Sie den Vorgang der Regeln für die Code-Set-Konvertierung zwischen EUCJP-Open und UCS". Probleme und Lösungen für Unicode- und Benutzer-/Anbieter definierte Zeichen. Die offene Gruppe Japan. Archiviert von das Original Am 1999-02-03. Abgerufen 2019-08-14.
  25. ^ a b Lunde, Ken (13. Januar 2009). "Anhang J: Japanische Zeichensätze" (PDF). CJKV -Informationsverarbeitung (2. Aufl.). ISBN 978-0-596-51447-1.
  26. ^ a b Chang, Hyeshik (8. Dezember 2021). "Readme für CJKCodecs". cpython. Python Software Foundation.
  27. ^ a b c d e f g h i Lunde, Ken (13. Januar 2009). "Anhang F: Anbieter -Codierungsmethoden" (PDF). CJKV -Informationsverarbeitung (2. Aufl.). ISBN 978-0-596-51447-1.
  28. ^ a b c d e f g h i j Lunde, Ken (2009). "Anhang E: Anbieter -Charakter -Set -Standards" (PDF). CJKV -Informationsverarbeitung: Chinesisch, Japanisch, Koreanisch und Vietnamesisches Computer (2. Aufl.). Sebastopol, ca.: O'Reilly. ISBN 978-0-596-51447-1.
  29. ^ a b "2: Codesets und Codeset Conversion". Digitale Unix -technische Referenz für die Verwendung japanischer Funktionen. Digital Equipment Corporation, Compaq.
  30. ^ "KS x 1001: 1992" (PDF).
  31. ^ "KS C 5601: 1987" (PDF). 1988-10-01.
  32. ^ Lunde, Ken (2009). "Kapitel 3: Zeichensatzstandards". CJKV -Informationsverarbeitung. p. 146. ISBN 978-0596514471.
  33. ^ "IBM Globalisierung - codierte Zeichensatzkennungen - CCSID 971". Archiviert von das Original Am 2014-11-30. Abgerufen 2021-09-03.
  34. ^ "CCSID 970". IBM Globalisierung. IBM. Archiviert von das Original Am 2014-12-01.
  35. ^ "IBM-970_P110_P110-2006_U2 (alias euc-kr)". Konverter Explorer - ICU -Demonstration. Internationale Komponenten für Unicode.
  36. ^ Internationale Komponenten für Unicode (ICU), IBM-970_P110_P110-2006_U2.ucm, 2002-12-03
  37. ^ a b "Code -Seiten -Identifikatoren". Windows Dev Center. Microsoft.
  38. ^ Julliard, Alexandre. "Dump_Krwansung_CodePage: Erstellen Sie die koreanische Wansung -Tabelle aus der KSX1001 -Datei". make_unicode: Codeseite .c -Dateien aus ftp.unicode.org Beschreibungen generieren. Weinprojekt.
  39. ^ "Verteilung von Charaktercodierungen zwischen Websites, die .KR verwenden". w3techs.com. Abgerufen 2022-06-18.
  40. ^ "Verteilung von Charaktercodierungen auf Websites, die Koreanisch verwenden". w3techs.com. Abgerufen 2022-06-18.
  41. ^ "한글 코드 에 대하여" (in Koreanisch). W3c. Archiviert von das Original Am 2013-05-24. Abgerufen 2019-01-07.
  42. ^ Im ucnv_lmb.cpp, eine Datei, die stammt von IBM und in der enthalten Internationale Komponenten für Unicode Quellbaum, der Lead-Byte 0x11 wird als "Koreanisch: IBM-1261" nach der Definition von kommentiert ULMBCS_GRP_KO, und wird dem zugeordnet "Windows-949" ICU Codec in der OptgroupByTetocpname Array später in der Datei.
  43. ^ "Codierte Zeichensatzkennungen - CCSID 1363", IBM Globalisierung, IBM, archiviert von das Original Am 2014-11-29
  44. ^ "5. Indizes (§ Index EUC-kr)", Codierungsstandard, Waswg
  45. ^ Gil, Hojin. "Hangultalk: de facto Standard Hangul -Umgebung für Mac". Leitfaden zur Verwendung von Hangul auf Macintosh.
  46. ^ a b Apfel (2005-04-05). "Karte (externe Version) von Mac OS Korean Coding zu Unicode 3.2 und später". Unicode -Konsortium.
  47. ^ Kim, Kyongsok (2002-11-30). "3-Wege-Cross-Reference-Tabellen-KS x 1001, KPS 9566 und UCS" (PDF). ISO/IEC JTC 1/SC 2/WG 2 N2564. [HINWEIS: Aktualisierte Links für Tabellen, die das Dokument begleiten: [1] [2]]
  48. ^ Chung, Jaemin (2018-01-05). "Informationen zur neuesten Version von KPS 9566 (KPS 9566-2011?)" (PDF). koordinierte Weltzeit L2/18-011.

Externe Links