Rozšířený unixový kód - Extended Unix Code

Extended Unix Code ( EUC ) je vícebajtový systém kódování znaků používaný především pro japonštinu , korejštinu a zjednodušenou čínštinu .

Nejčastěji používanými kódy EUC jsou kódování s proměnnou šířkou, přičemž znak patřící kódované znakové sadě kompatibilní s ISO/IEC 646 (například ASCII ) zabírá jeden bajt a znak patřící do kódované znakové sady 94x94 (například GB 2312 ) ve dvou bajtech. EUC-CN forma GB 2312 a EUC-KR jsou příklady takových EUC kódů dvoubajtových. EUC-JP obsahuje znaky reprezentované až třemi bajty, včetně kódu počátečního posunu , zatímco jeden znak v EUC-TW může trvat až čtyři bajty.

Moderní aplikace pravděpodobně používají UTF-8 , který podporuje všechny piktogramy kódů EUC a další, a je obecně přenosnější s menším počtem odchylek a chyb dodavatele. EUC je však stále velmi populární, zejména EUC-KR pro Jižní Koreu.

Struktura kódování

Vztah mezi zabalenými EUC a dalšími 8bitovými profily ISO 2022

Struktura EUC je založena na standardu ISO/IEC 2022 , který specifikuje systém grafických znakových sad, které lze reprezentovat sekvencí 94 7bitových bytů 0x 21–7E, nebo alternativně 0xA1 – FE, pokud je osmý bit je k dispozici. To umožňuje sady 94 grafických znaků nebo 8836 (94 2 ) znaků nebo 830584 (94 3 ) znaků. Ačkoli zpočátku 0x20 a 0x7F byly vždy znak mezery a mazání a 0xA0 a 0xFF nebyly používány, pozdější verze ISO/IEC 2022 umožňovaly použití bytů 0xA0 a 0xFF (nebo 0x20 a 0x7F) v sadách za určitých okolností, což umožnilo zahrnutí 96-znakových sad. Pro řídicí kódy C0 a C1 se používají rozsahy 0x00–1F a 0x80–9F .

EUC je rodina 8bitových profilů ISO/IEC 2022 , na rozdíl od 7bitových profilů, jako je ISO-2022-JP . Formáty EUC tedy mohou mít pouze znakové sady kompatibilní s ISO 2022 . V systému EUC lze reprezentovat až čtyři kódované znakové sady (označované jako G0, G1, G2 a G3 nebo jako kódové sady 0, 1, 2 a 3). Sada G0 je nastavena na kódovanou znakovou sadu kompatibilní s ISO/IEC 646, jako je US-ASCII , ISO 646: KR ( KS X 1003 ) nebo ISO 646: JP (spodní polovina JIS X 0201 ), a je vyvolána přes GL (tj. 0x21–0x7E, přičemž nejdůležitější bit je vymazán). Pokud je použit US-ASCII, kód je rozšířeným kódováním ASCII ; nejběžnější odchylkou od US-ASCII je, že 0x5C ( zpětné lomítko v US-ASCII) se často používá k reprezentaci znaku jenu v EUC-JP (viz níže) a znaménka vyhrál v EUC-KR.

Ostatní sady kódů jsou vyvolány přes GR (tj. S nejvýznamnější bitovou sadou). Aby se získala forma znaku EUC, nastaví se nejvýznamnější bit každého kódovacího bajtu (ekvivalent přidání 128 ke každému 7bitovému kódovacímu bajtu nebo přidání 160 ke každému číslu v kódu kuten ); to umožňuje softwaru snadno rozlišit, zda konkrétní bajt v řetězci znaků patří kódu ISO 646 nebo rozšířenému kódu. Znakům v sadách kódů 2 a 3 jsou předřazeny řídicí kódy SS2 (0x8E) respektive SS3 (0x8F) a jsou vyvolány přes GR. Kromě kódu počátečního posunu není žádný bajt mimo rozsah 0xA0–0xFF objevující se ve znaku z kódových sad 1 až 3 platným kódem EUC.

Samotný kód EUC nevyužívá sekvence oznámení a označení z ISO 2022 . Specifikace kódu je však ekvivalentní následující sekvenci čtyř sekvencí oznámení ISO 2022 , přičemž významy jsou rozděleny následovně.

Individuální sekvence Hexadecimální Funkce EUC označena
ESC SP C 1B 20 43 ISO-8 (8bitový, G0 v GL, G1 v GR)
ESC SP Z 1B 20 5A Přístup ke G2 pomocí SS2
ESC SP [ 1B 20 5B G3 přístup pomocí SS3
ESC SP \ 1B 20 5C Jednosměnové vyvolání přes GR

Formát s pevnou šířkou

Výše popsané kódování s proměnnou šířkou založené na ISO-2022 je někdy označováno jako formát zabalený v EUC , což je formát kódování obvykle označovaný jako EUC. Interní zpracování dat EUC však může využívat transformační formát s pevnou šířkou, který se nazývá úplný dvoubajtový formát EUC . To představuje:

  • Kód nastavený na 0 jako dva bajty v rozsahu 0x21–0x7E (kromě toho, že první může být 0x00).
  • Kódová sada 1 jako dva bajty v rozsahu 0xA0–0xFF (kromě toho, že první může být 0x80).
  • Kódová sada 2 jako bajt v rozsahu 0x20–0x7E (nebo 0x00) následovaný bajtem v rozsahu 0xA0–0xFF.
  • Kódová sada 3 jako bajt v rozsahu 0xA0–0xFF (nebo 0x80) následovaný bajtem v rozsahu 0x21–0x7E.

Počáteční bajty 0x00 a 0x80 se používají v případech, kdy sada kódů používá pouze jeden bajt. K dispozici je také čtyřbajtový formát pevné délky. Tyto formáty kódování s pevnou délkou jsou vhodné pro interní zpracování a při výměně se obvykle nevyskytují.

EUC-JP je registrován u IANA v obou formátech, zabalený formát jako „EUC-JP“ nebo „csEUCPkdFmtJapanese“ a formát s pevnou šířkou jako „csEUCFixWidJapanese“. Do standardu kódování WHATWG používaného HTML5 je zahrnut pouze zabalený formát .

EUC-CN

EUC-CN
Kódování EUCCN. Svg
MIME / IANA GB2312
Přezdívky csGB2312
Jazyk (y) Zjednodušená čínština , angličtina , ruština
Standard GB 2312 (1980)
Klasifikace Rozšířené ASCII , kódování s proměnnou šířkou , kódování CJK , EUC
Rozšiřuje US-ASCII
Rozšíření 748, GBK , GB 18030 , x-mac-chinesesimp
Transformuje / kóduje GB 2312
Uspěl GBK , GB 18030

EUC-CN je obvyklá kódovaná forma standardu GB 2312 pro zjednodušené čínské znaky . Na rozdíl od případu japonských JIS X 0208 a ISO-2022-JP se GB 2312 běžně nepoužívá v 7bitové verzi kódu ISO 2022 , i když někdy byla použita varianta s názvem HZ (která vymezuje text GB 2312 se sekvencemi ASCII) na USENET .

Znak ASCII je reprezentován v jeho obvyklém kódování. Znak z GB 2312 je reprezentován dvěma bajty, oba v rozsahu 0xA1–0xFE.

Související systémy kódování pevninské Číny

748 kód

Kódování související s EUC-CN je kód „748“ používaný v sázecím systému WITS vyvinutém pekingskou Founder Technology (nyní zastaralý novějším sázecím systémem FITS). Kód 748 obsahuje všechny GB 2312 , ale není v souladu s ISO 2022, a proto není skutečným kódem EUC. (Používá 8bitový vedoucí bajt, ale rozlišuje mezi druhým bajtem s jeho nejvýznamnější bitovou sadou a jedním s jeho nejvýznamnějším vymazaným bitem, a je tedy strukturou více podobný Big5 a dalším kódovacím systémům DBCS, které nejsou kompatibilní s ISO 2022 .) Část 748 kódu, která není GB2312, obsahuje tradiční a hongkongské znaky a další piktogramy používané při sazbě novin.

GBK a GB 18030

Hlavní články: GBK (kódování znaků) a GB 18030

GBK je rozšíření na GB 2312 . Definuje rozšířenou formu kódování EUC-CN schopnou reprezentovat větší řadu znaků CJK pocházejících převážně z Unicode 1.1 , včetně tradičních čínských znaků a znaků používaných pouze v japonštině . Nejedná se však o skutečný kód EUC, protože bajty ASCII se mohou jevit jako bajty stezek (a bajty C1 , bez omezení na jednotlivé směny, se mohou jevit jako bajty svodů nebo stop), protože je vyžadován větší kódovací prostor.

Varianty GBK jsou realizovány Windows kódové stránky 936 (dále jen Microsoft Windows kódové stránky zjednodušené čínštině), a kódové stránce IBM 1386.

Kódování znaků GB 18030 založené na Unicode definuje rozšíření GBK schopné kódování celého Unicode . Unicode kódovaný jako GB 18030 je však kódování s proměnnou šířkou, které může používat až čtyři bajty na znak, protože je vyžadován ještě větší prostor pro kódování. Je to rozšíření GBK, je to nadmnožina EUC-CN, ale sama o sobě není skutečným kódem EUC. Jako kódování Unicode je jeho repertoár identický s jinými formáty transformace Unicode, jako je UTF-8 .

Zjednodušená čínština pro Mac OS

Mezi další varianty EUC-CN odchylující se od mechanismu EUC patří zjednodušený čínský skript Mac OS (známý jako kódová stránka 10008 nebo x-mac-chinesesimp). Používá bajty 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE a 0xFF pro U s přehláskou (ü), dvě speciální metrické znaky písma, mezeru , znak autorských práv (©), znak ochranné známky (™ ) a elipsy (...). To se liší v tom, co je považováno za jednobajtový znak oproti prvnímu bajtu dvoubajtového znaku z EUC (kde 0xFD a 0xFE jsou definovány jako hlavní bajty) a GBK (kde z nich 0x81, 0x82, 0xFD a 0xFE jsou definovány jako úvodní bajty).

Toto použití 0xA0, 0xFD, 0xFE a 0xFF odpovídá variantě Shift_JIS společnosti Apple .

Kromě těchto změn v rozsahu hlavních bajtů je další charakteristickou vlastností dvoubajtové části systému Mac OS Chinese Simplified zahrnutí dvou rozšíření do základní GB 2312-80 sady v řádcích 6 a 8. Tyto jsou považovány za „standardní rozšíření“ na GB 2312 ", z nichž ani jedno není vlastní společnosti Apple: rozšíření řádku 8 bylo převzato z GB 6345.1 , obě rozšíření jsou zahrnuta v GB/T 12345 (tradiční čínská varianta GB 2312) a obě rozšíření jsou zahrnuta v GB 18030 (nástupce GB 2312).

EUC-JP

EUC-JP
EUC-JP.svg
MIME / IANA EUC-JP
Přezdívky Unixized JIS (UJIS), csEUCPkdFmtJapanese
Jazyk (y) Japonsky , anglicky , rusky
Klasifikace Rozšířená ISO 646 , kódování s proměnnou šířkou , kódování CJK , EUC
Rozšiřuje US-ASCII nebo ISO 646: JP
Transformuje / kóduje JIS X 0208 , JIS X 0212 , JIS X 0201
Uspěl EUC-JISx0213
EUC-JIS-2004
Přezdívky EUC-JISx0213
Jazyk (y) Japonština , Ainu , angličtina , ruština
Standard JIS X 0213
Klasifikace Rozšířené ASCII , kódování s proměnnou šířkou , kódování CJK , EUC
Rozšiřuje US-ASCII
Transformuje / kóduje JIS X 0213 , JIS X 0201 (Kana)
Předchází EUC-JP

EUC-JP je kódování s proměnnou šířkou, které se používá k reprezentaci prvků tří japonských standardů znakových sad , konkrétně JIS X 0208 , JIS X 0212 a JIS X 0201 . Mezi další názvy tohoto kódování patří Unixized JIS (nebo UJIS ) a AT&T JIS . 0,1% všech webových stránek používá EUC-JP od srpna 2018, zatímco 2,5% japonských webů používá toto kódování (méně používané než Shift JIS nebo UTF-8 ). Říká se tomu kódová stránka 954 od IBM. Společnost Microsoft má pro toto kódování dvě čísla kódových stránek (51932 a 20932).

Toto schéma kódování umožňuje snadné míchání 7bitových ASCII a 8bitových japonských bez nutnosti použití únikových znaků podle ISO-2022-JP , které je založeno na stejných standardech znakové sady, a aniž by ASCII bajty vypadaly jako stopové bajty (na rozdíl od Shift JIS ).

Související a částečně kompatibilní kódování, nazývané EUC-JISx0213 nebo EUC-JIS-2004 , kóduje JIS X 0201 a JIS X 0213 (podobně jako Shift_JISx0213 , jeho protějšek na bázi Shift_JIS).

Ve srovnání s EUC-CN nebo EUC-KR se EUC-JP nestal tak široce přijímaným v systémech PC a Macintosh v Japonsku, které používaly Shift JIS nebo jeho rozšíření ( kódová stránka Windows 932 v systému Microsoft Windows a MacJapanese v klasickém systému Mac OS ) , ačkoli to začalo být silně používané Unixem nebo Unix-jako operační systémy (kromě pro HP-UX ). To, zda japonské webové stránky používají EUC-JP nebo Shift_JIS, proto často závisí na tom, jaký OS autor používá.

Znaky jsou kódovány následovně:

  • Jako kódování kompatibilní s EUC/ ISO 2022 jsou řídicí znaky C0 , mezera a DEL reprezentovány jako v ASCII.
  • Grafický znak z ASCII (sada kódů 0) je reprezentován jako jeho obvyklá jednobajtová reprezentace v rozsahu 0x21-0x7E. Zatímco některé varianty z EUC-JP zakódovat dolní polovinu z JIS X 0201 zde, většina kódování ASCII, včetně W3C / WHATWG kódovací standard používá HTML5 , a tak se EUC-JIS-2004. I když to znamená, že 0x5C je typicky mapováno na Unicode jako U+005C REVERSE SOLIDUS ( zpětné lomítko ASCII ), U+005C může být zobrazeno jako znak Yen některými fonty japonského národního prostředí, např. V systému Microsoft Windows, kvůli kompatibilitě se spodní polovinou z JIS X 0201 .
  • Znak z JIS X 0208 (sada kódů 1) je reprezentován dvěma bajty, oba v rozsahu 0xA1 - 0xFE. To se liší od reprezentace ISO-2022-JP tím, že je nastaven vysoký bit. Tato sada kódů může také obsahovat rozšíření dodavatele v některých variantách EUC-JP. V EUC-JIS-2004 je zde zakódována první rovina JIS X 0213 , což je ve skutečnosti nadmnožina standardu JIS X 0208 .
  • Charakter od horní poloviny roku JIS X 0201 ( poloviční šířka kana , nastavené číslo 2) je reprezentován dvěma bajty, z nichž první je 0x8E, druhý je obvyklá JIS X 0201 zastoupení v rozmezí 0xA1 - 0xDF. Tato sada může v některých variantách obsahovat rozšíření dodavatelů IBM .
  • Znak z JIS X 0212 (sada kódů 3) je v EUC-JP reprezentován třemi bajty, z nichž první je 0x8F, následující dva jsou v rozsahu 0xA1–0xFE, tj. S vysokou bitovou sadou. Kromě standardního JIS X 0212 může sada kódů 3 některých variant EUC-JP také obsahovat rozšíření v řádcích 83 a 84, aby představovala znaky z rozšíření IBM Shift JIS, kterým chybí standardní mapování JIS X 0212, která mohou být kódována v jednom ze dvou rozvržení, jedno definované samotnou IBM a jedno definované OSF . V EUC-JIS-2004 je zde zakódována druhá rovina JIS X 0213 , která nekoliduje s přidělenými řádky ve standardu JIS X 0212 . Některé implementace EUC-JIS-2004, například ta, kterou používá Python , umožňují v této sadě znaky JIS X 0212 a JIS X 0213 rovina 2.

Související metody japonského kódování

Rozšíření dodavatelů EUC-JP (například od Open Software Foundation , IBM nebo NEC ) byla často přidělována v rámci jednotlivých kódových sad, na rozdíl od používání neplatných sekvencí EUC (jako v populárních rozšířeních EUC-CN a EUC-KR ).

Některá kódování specifická pro dodavatele jsou však částečně kompatibilní s EUC-JP kvůli kódování JIS X 0208 přes GR, ale nedodržují zabalenou strukturu EUC. Často tyto nezahrnují použití jednotlivých směn z EUC-JP, a nejedná se tedy o přímé rozšíření EUC-JP, s výjimkou Super DEC Kanji.

DEC Kanji

Společnost Digital Equipment Corporation definuje dvě varianty EUC-JP, které jsou pouze částečně v souladu s formátem zabaleným v EUC, ale také mají určitou podobnost s kompletním dvoubajtovým formátem. Celkový formát kódování „DEC Kanji“ většinou odpovídá EUC s pevnou šířkou (kompletní dvoubajtový); kódová sada 0 však nemusí být vyplněna levými bajty s nulovými bajty (podobně jako zabalený formát). JIS X 0208 se jako obvykle používá pro sadu kódů 1; sada kódů 2 (katakana s poloviční šířkou) chybí; sada kódů 3 je kódována jako dvoubajtový formát s pevnou šířkou (tj. bez posuvného bajtu a pouze s první sadou vysokých bitů), ale používá se pro dvoubajtové znaky definované uživatelem, nikoli pro JIS X 0212. V základním Kódování „DEC Kanji“, pouze prvních 31 řádků kódové sady 3 se používá pro znaky definované uživatelem: řádky 32 až 94 jsou vyhrazeny, podobně jako nepoužívané řádky v kódové sadě 1.

Kódování „Super DEC Kanji“ přijímá kódy jak z kódování „DEC Kanji“, tak z zabaleného formátu EUC, celkem tedy pět sad kódů. Umožňuje také použít celou uživatelem definovanou sadu kódů a nepoužité řádky na koncích kódových sad JIS X 0208 a JIS X 0212 (řádky 85–94 a 78–94 v daném pořadí) pro znaky definované uživatelem.

HP-16

Společnost Hewlett-Packard definuje kódování označované jako „HP-16“. To doprovází jejich kódování „HP-15“, což je varianta Shift JIS . HP-16 kóduje JIS X 0208 pomocí stejných bajtů jako v EUC-JP, ale nepoužívá kódy s jedním posunem (čímž vynechává sady kódů 2 a 3) a přidává tři uživatelsky definované oblasti, které nedodržují zabalený formát Struktura EUC:

  • Olověné bajty 0xA1 – C2, stezkové bajty 0x21–7E
  • Olověné bajty 0xC3 – E3, stezkové bajty 0x21–3F
  • Olověné bajty 0xC3 – E1, stopové bajty 0x40–64

IKIS

Kódování IKIS (Interactive Kanji Information System) používané společností Data General připomíná EUC-JP bez jednotlivých posunů, tj. Pouze s kódovými sadami 0 a 1. Katakana s poloviční šířkou je místo toho zahrnuta v řádku 8 JIS X 0208 (kolize s rámečkem- kreslení postav přidaných ke standardu v roce 1983). JIS X 0208 řádky 9 až 12 se používají pro znaky definované uživatelem.

Adaptace EUC-JP pro EBCDIC

Hlavní článek: japonský jazyk v EBCDIC

KEIS (Extended Information System Kanji-processing Extended Information System) je kódování EBCDIC používané společností Hitachi , přičemž dvoubajtové znaky (kódování DBCS-Host) jsou zahrnuty pomocí posunovacích sekvencí, což z něj činí stavové kódování. Sekvence se konkrétně 0x0A 0x41přepne do jednobajtového režimu a sekvence se 0x0A 0x42přepne do dvoubajtového režimu. Znaky JIS X 0208 jsou však kódovány pomocí stejných bajtových sekvencí, jaké byly použity pro jejich kódování v EUC-JP. Výsledkem je duplicitní kódování ideografického prostoru- 0x4040 podle struktury kódu DBCS-Host a 0xA1A1 jako v EUC-JP. To se liší od kódování IBM DBCS-Host pro japonštinu, jehož rozložení vychází z verzí, které předcházejí JIS X 0208. Rozsah bajtů svodů je rozšířen zpět na 0x59, z nichž jsou bajty svodů 0x81 – A0 určeny pro znaky definované uživatelem a zbývající část je použita pro znaky definované společností, včetně kanji i bez kanji.

JEF (Extended Feature-Japanese-processing Extended Feature) je kódování EBCDIC používané na sálových počítačích Fujitsu FACOM, kontrastující s FMR (varianta Shift JIS) používaným na počítačích Fujitsu. Stejně jako KEIS je JEF stavové kódování, které přepíná na dvoubajtový režim DBCS-Host pomocí posunovacích sekvencí (kde 0x29přechází do jednobajtového režimu a 0x28přepíná do dvoubajtového režimu). Podobně jako u KEIS jsou kódy JIS X 0208 zastoupeny stejně jako v EUC-JP. Rozsah vedoucích bajtů je rozšířen zpět na 0x41, přičemž 0x80 – A0 je určeno pro definici uživatele; vést bajtů 0x41-7F jsou přiřazena čísla řádků 101 až 163 pro kuten účely, i když řada 162 (olovo bajt 0x7e) je nepoužitý. Řady 101 až 148 se používají pro rozšířené kanji, zatímco řádky 149 až 163 se používají pro rozšířené jiné než kanji.

EUC-KR

„EUC-KR“ přeadresuje tady. Variantu takto pojmenovanou ve standardech HTML najdete v článku Unified Hangul Code .
EUC-KR
EUC-KR bez rozšíření. Svg
Struktura kódu EUC-KR
MIME / IANA EUC-KR
Přezdívky Wansung, IBM-970
Jazyk (y) Korejština , angličtina , ruština
Standard KS X 2901 (KS C 5861)
Klasifikace Rozšířená ISO 646 , kódování s proměnnou šířkou , kódování CJK , EUC
Rozšiřuje US-ASCII nebo ISO 646: KR
Rozšíření Mac OS Korean , IBM-949 , Unified Hangul Code (Windows-949)
Transformuje / kóduje KS X 1001
Uspěl Unified Hangul Code (webové standardy)

EUC-KR je kódování s proměnnou šířkou, které představuje korejský text pomocí dvou kódovaných znakových sad, KS X 1001 (dříve KS C 5601) a buď ISO 646 : KR ( KS X 1003 , dříve KS C 5636 ) nebo US-ASCII , v závislosti na na variantě. KS X 2901 (dříve KS C 5861 ) stanoví kódování a RFC  1557 jej nazval EUC-KR.

Znak získaný z KS X 1001 (G1, sada kódů 1) je kódován jako dva bajty v GR (0xA1–0xFE) a znak z KS X 1003 nebo US-ASCII (G0, sada kódů 0) má jeden byte v GL ( 0x21–0x7E).

To je obvykle označován jako Wansung ( korejský : 완성 , romanized :  Wanseong , rozsvícený  ' precomposed ') v Korejské republice . IBM označuje dvoubajtovou komponentu jako kódovou stránku 971 a EUC-KR s ASCII jako kódovou stránku 970 . Je implementován jako kódová stránka 20949 („Korean Wansung“) a kódová stránka 51949 („EUC Korean“) společností Microsoft.

V říjnu 2021 0,1% všech webových stránek na celém světě používá EUC-KR, což je zavádějící, protože 7,8% jihokorejských webových stránek používá (pouze země, pro kterou je kódování určeno), což z něj činí nejpopulárnější non -UTF-8 / Kódování Unicode pro jazykovou/webovou doménu, zatímco pouze 3,9% webových stránek používá korejský jazyk (takže použití UTF-8, 92,2%, je v Jižní Koreji méně populární než ve (zdánlivě) všech zemích světa). Včetně rozšíření je to nejpoužívanější kódování starších znaků v Koreji na všech třech hlavních platformách ( macOS , jiné unixové OS a Windows), ale jeho používání se velmi pomalu přesouvá na UTF-8, protože získává na popularitě, zejména na Linuxu a macOS.

Stejně jako u většiny ostatních kódování je nyní pro nové použití upřednostňován UTF-8 , který řeší problémy s konzistencí mezi platformami a dodavateli.

Související korejské kódovací systémy

Sjednocený kód Hangul

Hlavní článek: Unified Hangul Code

Běžným rozšířením EUC-KR je Unified Hangul Code ( 통합형 한글 코드 , Tonghabhyeong Hangeul Kodeu nebo 통합 완성형 , Tonghab Wansunghyung ), což je výchozí korejská kódová stránka v systému Microsoft Windows. Společnost Microsoft mu dala číslo kódové stránky 949 a IBM 1261 nebo 1363. Kódová stránka IBM 949 je jiné, nesouvisející rozšíření EUC-KR.

Sjednocený kód Hangul rozšiřuje EUC-KR pomocí kódů, které neodpovídají struktuře EUC, k začlenění dalších bloků slabik, čímž se doplňuje pokrytí složených bloků slabik dostupných v Johab a Unicode. W3C / WHATWG Kódování Standardní používají HTML5 zahrnuje Unified rozšíření Hangul kód do své definice EUC-KR.

Mac OS Korean (HangulTalk)

Mezi další kódování zahrnující EUC-KR jako podmnožinu patří korejský skript Mac OS (známý jako Code page 10003 or x-mac-korean), který byl používán HangulTalk (MacOS-KH), korejskou lokalizací klasického Mac OS . Byl vyvinut společností Elex Computer ( 일 렉스 ), kteří byli v té době autorizovaným distributorem počítačů Apple Macintosh v Jižní Koreji.

HangulTalk přidává znaky rozšíření s olověnými bajty mezi 0xA1 a 0xAD, a to jak v nevyužitém prostoru v rovině EUC-KR GR (stopy bajtů 0xA1–0xFE), tak i mimo něj používají kódy mimo EUC (stopy bajtů 0x41–0xA0). Některé z těchto postav jsou stylizované dingbaty nezávislé na stylu písma . Mnoho z těchto znaků nemá přesná mapování Unicode a software Apple tyto případy různě mapuje na kombinování sekvencí , na aproximaci mapování s připojeným znakem soukromého použití jako modifikátorem pro účely zpáteční cesty nebo na znaky soukromého použití.

Apple také používá určité jednobajtové kódy mimo rovinu EUC-KR pro další znaky: 0x80 pro požadovaný prostor , 0x81 pro znaménko vyhráno (₩), 0x82 pro en dash (-), 0x83 pro znak autorských práv (© ), 0x84 pro široké podtržítko (＿) a 0xFF pro elipsu (...). Ačkoli žádný z těchto dodatečných jednobajtových kódů není v rozsahu vedoucích bajtů prostého EUC-KR (na rozdíl od rozšíření Apple o EUC-CN, viz výše ), některé jsou v rozsahu vedoucích bajtů Unified Hangul Code (konkrétně 0x81, 0x82 (0x83 a 0x84).

EUC-KP

Hlavní článek: KPS 9566

Podobně jako KS X 1001 se severokorejský standard KPS 9566 obvykle používá ve formě EUC; v těchto kontextech je někdy označován jako EUC-KP. Novější verze standardu rozšiřují reprezentaci EUC o znaky využívající dvoubajtové kódy jiné než EUC, podobným způsobem jako Unified Hangul Code.

EUC-TW

EUC-TW je kódování s proměnnou šířkou, které podporuje US-ASCII a 16 letadel CNS 11643 , z nichž každé je 94x94. Jedná se o zřídka používané kódování pro tradiční čínské znaky používané na Tchaj -wanu . Varianty Big5 jsou mnohem běžnější než EUC-TW, přestože Big5 kóduje pouze první dvě roviny hanzi CNS 11643 , zatímco UTF-8 je stále běžnější.

  • Jako kódování EUC/ ISO 2022 jsou řídicí znaky C0 , mezera ASCII a DEL kódovány jako v ASCII.
  • Grafický znak z US-ASCII (G0, sada kódů 0) je zakódován v GL jako jeho obvyklá jednobajtová reprezentace (0x21–0x7E).
  • Znak z roviny 1 CNS 11643 (sada kódů 1) je kódován jako dva bajty v GR (0xA1–0xFE).
  • Znak v rovině 1 až 16 CNS 11643 (sada kódů 2) je kódován jako čtyři bajty:
    • První bajt je vždy 0x8E (Single Shift 2).
    • Druhý bajt (0xA1–0xB0) označuje rovinu, jejíž počet se získá odečtením 0xA0 od tohoto bajtu.
    • Třetí a čtvrtý bajt jsou v GR (0xA1–0xFE).

Pamatujte, že rovina 1 CNS 11643 je kódována dvakrát jako kódová sada 1 a část kódové sady 2.

Viz také

Poznámky

Reference

  1. ^ a b c d IBM . „Architektura reprezentace dat znaků (CDRA)“ . s. 157–162.
  2. ^ a b c Lunde, Ken (2008). Zpracování informací CJKV: čínské, japonské, korejské a vietnamské počítače . O'Reilly. s. 242–244. ISBN 9780596800925.
  3. ^ „Sady znaků“ . IANA.
  4. ^ "4.2. Názvy a štítky" . Kódovací standard . CO JE?
  5. ^ a b c d „Mapa (externí verze) z čínského zjednodušeného kódování systému Mac OS na Unicode 3.0 a novější“ . Apple, Inc .
  6. ^ a b "Vlastnost Encoding.WindowsCodePage - .NET Framework (aktuální verze)" . MSDN . Microsoft.
  7. ^ Lunde, Ken (1998). Příloha F: GB/T 12345 (PDF) . Zpracování informací CJKV . O'Reilly Media . ISBN 9781565922242.
  8. ^ Standardization Administration of China (SAC) (2005-11-18). GB 18030-2005: Informační technologie-čínská kódovaná znaková sada .
  9. ^ a b „Historické trendy ve využívání kódování znaků pro webové stránky“ . W3Techs.
  10. ^ "Informační dokument CCSID 954" . Archivováno od originálu dne 2016-03-27.
  11. ^ Mezinárodní komponenty pro Unicode (ICU), ibm-954_P101-2007.ucm , 2002-12-03
  12. ^ a b c d "Tabulky mapování kódu JIS X 0213" . x0213.org.
  13. ^ "Nejasnosti při převodu z japonského EUC na Unicode (nenormativní)" . Japonský profil XML . W3C.
  14. ^ "Dekodér EUC-JP" . Kódovací standard . CO JE? "Pokud je byte bajtem ASCII, vraťte bod kódu, jehož hodnota je byte."
  15. ^ "3.1.1 Podrobnosti o problémech" . Problémy a řešení pro znaky Unicode a znaky definované uživatelem/dodavatelem . Otevřená skupina Japonsko. Archivovány od originálu na 1999-02-03 . Citováno 2019-08-14 .
  16. ^ Kaplan, Michael S. (2005-09-17). „Kdy není zpětné lomítko zpětné lomítko?“ .
  17. ^ a b "4.2 Proces kontroly pravidel pro převod sady kódů mezi eucJP-open a UCS" . Problémy a řešení pro znaky Unicode a znaky definované uživatelem/dodavatelem . Otevřená skupina Japonsko. Archivovány od originálu na 1999-02-03 . Citováno 2019-08-14 .
  18. ^ a b Lunde, Ken (13. ledna 2009). „Dodatek J: Japonské znakové sady“ (PDF) . Zpracování informací CJKV (2. vyd.). ISBN 978-0-596-51447-1.
  19. ^ a b Chang, Hyeshik. „Soubor Readme pro CJKCodecs“ . cPython . Python Software Foundation.
  20. ^ a b c d e f g h i Lunde, Ken (13. ledna 2009). „Příloha F: Metody kódování dodavatele“ (PDF) . Zpracování informací CJKV (2. vyd.). ISBN 978-0-596-51447-1.
  21. ^ a b c d e f g h i j Lunde, Ken (2009). „Dodatek E: Standardy znakové sady dodavatele“ (PDF) . Zpracování informací CJKV: čínské, japonské, korejské a vietnamské počítače (2. vydání). Sebastopol, CA : O'Reilly . ISBN 978-0-596-51447-1.
  22. ^ a b "2: Kodeky a převod kodetů" . Technická reference DIGITAL UNIX pro používání japonských funkcí . Digital Equipment Corporation , Compaq .
  23. ^ "KS X 1001: 1992" (PDF) .
  24. ^ "KS C 5601: 1987" (PDF) . 1988-10-01.
  25. ^ Lunde, Ken (2009). „Kapitola 3: Standardy znakové sady“ . Zpracování informací CJKV . p. 146. ISBN 978-0596514471.
  26. ^ "IBM Globalization - Kódované identifikátory znakové sady - CCSID 971" . Citováno 2021-09-03 .
  27. ^ "CCSID 970" . Globalizace IBM . IBM. Archivováno od originálu dne 2014-12-01.
  28. ^ "ibm-970_P110_P110-2006_U2 (alias euc-kr)" . Explorer Converter - Demonstrace ICU . Mezinárodní komponenty pro Unicode.
  29. ^ Mezinárodní komponenty pro Unicode (ICU), ibm-970_P110_P110-2006_U2.ucm , 2002-12-03
  30. ^ a b „Identifikátory kódové stránky“ . Centrum pro vývojáře Windows . Microsoft.
  31. ^ Julliard, Alexandre. "dump_krwansung_codepage: build Korean Wansung table from the KSX1001 file" . make_unicode: Generujte soubory .c kódové stránky z popisů ftp.unicode.org . Projekt vína .
  32. ^ "Distribuce kódování znaků mezi weby, které používají .kr" . w3techs.com . Citováno 2021-10-17 .
  33. ^ "Distribuce kódování znaků mezi weby, které používají korejštinu" . w3techs.com . Citováno 2020-07-03 .
  34. ^ "한글 코드 에 대하여" (v korejštině). W3C. Archivovány od originálu dne 2013-05-24 . Citováno 2019-01-07 .
  35. ^ V ucnv_lmb.cpp , souboru pocházejícím od IBM a zahrnutém vezdrojovém stromu International Components for Unicode , je hlavní bajt 0x11 komentován jako odkazující na „korejský: ibm-1261“ po definiciULMBCS_GRP_KOa je mapován na"windows-949"kodek ICU vOptGroupByteToCPNamepoli později v souboru.
  36. ^ "Identifikátory kódované znakové sady-CCSID 1363" , IBM Globalization , IBM, archivováno z originálu dne 2014-11-29
  37. ^ "5. Indexy (§ index EUC-KR)" , kódovací standard , WHATWG
  38. ^ Gil, Hojin. „HangulTalk: De facto standardní prostředí Hangul pro Mac“ . Průvodce používáním Hangul na Macintosh .
  39. ^ a b Apple (2005-04-05). „Mapa (externí verze) z korejského kódování Mac OS na Unicode 3.2 a novější“ . Konsorcium Unicode .
  40. ^ Kim, Kyongsok (2002-11-30). „Třícestné tabulky odkazů-KS X 1001, KPS 9566 a UCS“ (PDF) . ISO/IEC JTC 1/SC 2 /WG 2 N2564.[Poznámka: aktualizované odkazy na tabulky doprovázející dokument: [1] [2] ]
  41. ^ Chung, Jaemin (2018-01-05). „Informace o nejnovější verzi KPS 9566 (KPS 9566-2011?)“ (PDF) . UTC L2/18-011.

externí odkazy