Código Unix estendido - Extended Unix Code

Extended Unix Code ( EUC ) é um sistema de codificação de caracteres multibyte usado principalmente para japonês , coreano e chinês simplificado .

Os códigos EUC mais comumente usados ​​são codificações de largura variável com um caractere pertencente a um conjunto de caracteres codificados em conformidade com ISO / IEC 646 (como ASCII ) recebendo um byte, e um caractere pertencente a um conjunto de caracteres codificados 94x94 (como GB 2312 ) representado em dois bytes. A forma EUC-CN do GB 2312 e EUC-KR são exemplos de tais códigos EUC de dois bytes. EUC-JP inclui caracteres representados por até três bytes, incluindo um código de deslocamento inicial , enquanto um único caractere em EUC-TW pode ocupar até quatro bytes.

Os aplicativos modernos são mais propensos a usar UTF-8 , que oferece suporte a todos os glifos dos códigos EUC e mais, e geralmente é mais portátil com menos erros e desvios do fornecedor. No entanto, EUC ainda é muito popular, especialmente EUC-KR para a Coreia do Sul.

Estrutura de codificação

Relação entre EUC compactado e outros perfis ISO 2022 de 8 bits

A estrutura da EUC é baseada no padrão ISO / IEC 2022 , que especifica um sistema de conjuntos de caracteres gráficos que podem ser representados com uma sequência de 94 bytes de 7 bits 0x 21–7E, ou alternativamente 0xA1 – FE se um oitavo bit está disponível. Isso permite conjuntos de 94 caracteres gráficos, ou 8836 (94 2 ) caracteres, ou 830584 (94 3 ) caracteres. Embora inicialmente 0x20 e 0x7F fossem sempre o caractere de espaço e exclusão e 0xA0 e 0xFF não fossem usados, as edições posteriores da ISO / IEC 2022 permitiram o uso dos bytes 0xA0 e 0xFF (ou 0x20 e 0x7F) dentro de conjuntos sob certas circunstâncias, permitindo a inclusão de conjuntos de 96 caracteres. Os intervalos 0x00–1F e 0x80–9F são usados ​​para códigos de controle C0 e C1 .

EUC é uma família de perfis de 8 bits de ISO / IEC 2022 , ao contrário de perfis de 7 bits, como ISO-2022-JP . Como tal, apenas conjuntos de caracteres compatíveis com ISO 2022 podem ter formulários EUC. Até quatro conjuntos de caracteres codificados (referidos como G0, G1, G2 e G3 ou como conjuntos de códigos 0, 1, 2 e 3) podem ser representados com o esquema EUC. O conjunto G0 é definido para um conjunto de caracteres codificados em conformidade com ISO / IEC 646 , como US-ASCII , ISO 646: KR ( KS X 1003 ) ou ISO 646: JP (a metade inferior de JIS X 0201 ) e invocado sobre GL (ou seja 0x21–0x7E, com o bit mais significativo apagado). Se US-ASCII for usado, isso tornará o código uma codificação ASCII estendida ; o desvio mais comum de US-ASCII é que 0x5C ( barra invertida em US-ASCII) é frequentemente usado para representar um sinal de iene em EUC-JP (veja abaixo) e um sinal de won em EUC-KR.

Os outros conjuntos de códigos são chamados por GR (ou seja, com o conjunto de bits mais significativo). Portanto, para obter a forma EUC de um caractere, o bit mais significativo de cada byte de codificação é definido (equivalente a adicionar 128 a cada byte de codificação de 7 bits ou adicionar 160 a cada número no código kuten ); isso permite ao software distinguir facilmente se um determinado byte em uma seqüência de caracteres pertence ao código ISO 646 ou ao código estendido. Os caracteres nos conjuntos de códigos 2 e 3 são prefixados com os códigos de controle SS2 (0x8E) e SS3 (0x8F), respectivamente, e invocados por GR. Além do código de deslocamento inicial, qualquer byte fora do intervalo 0xA0–0xFF aparecendo em um caractere dos conjuntos de códigos 1 a 3 não é um código EUC válido.

O código EUC em si não faz uso das sequências de anúncio e designação da ISO 2022 . No entanto, a especificação do código é equivalente à seguinte sequência de quatro sequências de anúncio ISO 2022 , com os significados divididos da seguinte forma.

Sequência individual Hexadecimal Característica de EUC denotada
ESC SP C 1B 20 43 ISO-8 (8 bits, G0 em GL, G1 em GR)
ESC SP Z 1B 20 5A G2 acessado usando SS2
ESC SP [ 1B 20 5B G3 acessado usando SS3
ESC SP \ 1B 20 5C Turnos únicos invocam sobre GR

Formato de largura fixa

A codificação de largura variável baseada em ISO-2022 descrita acima é algumas vezes referida como o formato empacotado EUC , que é o formato de codificação geralmente rotulado como EUC. No entanto, o processamento interno de dados EUC pode fazer uso de um formato de transformação de largura fixa denominado formato EUC completo de dois bytes . Isto representa:

  • Código definido como 0 como dois bytes no intervalo 0x21–0x7E (exceto que o primeiro pode ser 0x00).
  • Código definido 1 como dois bytes no intervalo 0xA0–0xFF (exceto que o primeiro pode ser 0x80).
  • Código definido 2 como um byte no intervalo 0x20–0x7E (ou 0x00) seguido por um byte no intervalo 0xA0–0xFF.
  • Código definido 3 como um byte no intervalo 0xA0–0xFF (ou 0x80) seguido por um byte no intervalo 0x21–0x7E.

Os bytes iniciais de 0x00 e 0x80 são usados ​​nos casos em que o conjunto de códigos usa apenas um byte. Também existe um formato de comprimento fixo de quatro bytes. Esses formatos de codificação de comprimento fixo são adequados para processamento interno e geralmente não são encontrados no intercâmbio.

EUC-JP está registrado na IANA em ambos os formatos, o formato compactado como "EUC-JP" ou "csEUCPkdFmtJapanese" e o formato de largura fixa como "csEUCFixWidJapanese". Apenas o formato compactado está incluído no padrão de codificação WHATWG usado pelo HTML5 .

EUC-CN

EUC-CN
EUCCN encoding.svg
MIME / IANA GB2312
Apelido) csGB2312
Línguas) Chinês simplificado , inglês , russo
Padrão GB 2312 (1980)
Classificação ASCII estendido , codificação de largura variável , codificação CJK , EUC
Estende US-ASCII
Extensões 748, GBK , GB 18030 , x-mac-chinesesimp
Transformações / Codificações GB 2312
Sucedido por GBK , GB 18030

EUC-CN é a forma codificada usual do padrão GB 2312 para caracteres chineses simplificados . Ao contrário do caso do japonês JIS X 0208 e ISO-2022-JP , GB 2312 não é normalmente usado em uma versão de código ISO 2022 de 7 bits , embora uma forma variante chamada HZ (que delimita o texto GB 2312 com sequências ASCII) tenha sido usada às vezes na USENET .

Um caractere ASCII é representado em sua codificação usual. Um caractere do GB 2312 é representado por dois bytes, ambos no intervalo 0xA1–0xFE.

Sistemas relacionados de codificação do Continente Chinês

Código 748

Uma codificação relacionada ao EUC-CN é o código "748" usado no sistema de composição WITS desenvolvido pela Founder Technology de Pequim (agora obsoleto por seu novo sistema de composição FITS). O código 748 contém todo o GB 2312 , mas não é compatível com ISO 2022 e, portanto, não é um código EUC verdadeiro. (Ele usa um byte inicial de 8 bits, mas distingue entre um segundo byte com seu conjunto de bits mais significativo e um com seu bit mais significativo apagado e, portanto, é mais semelhante em estrutura ao Big5 e outros sistemas de codificação DBCS não compatíveis com ISO 2022 .) A parte não GB2312 do código 748 contém caracteres tradicionais e de Hong Kong e outros glifos usados ​​na composição de jornais.

GBK e GB 18030

Artigos principais: GBK (codificação de caracteres) e GB 18030

GBK é uma extensão do GB 2312 . Ele define uma forma estendida da codificação EUC-CN capaz de representar uma matriz maior de caracteres CJK originados em grande parte do Unicode 1.1 , incluindo caracteres chineses tradicionais e caracteres usados ​​apenas em japonês . Não é, no entanto, um código EUC verdadeiro, porque os bytes ASCII podem aparecer como bytes de trilha (e bytes C1 , não limitados a deslocamentos únicos, podem aparecer como bytes de inicial ou final), devido à necessidade de um espaço de codificação maior.

Variantes de GBK são implementadas por página do Windows código 936 (o Microsoft Windows página de código para chinês simplificado), e pela página de código do IBM 1386.

A codificação de caracteres GB 18030 baseada em Unicode define uma extensão de GBK capaz de codificar todo o Unicode . No entanto, Unicode codificado como GB 18030 é uma codificação de largura variável que pode usar até quatro bytes por caractere, devido à necessidade de um espaço de codificação ainda maior. Sendo uma extensão do GBK, é um superconjunto do EUC-CN, mas não é um verdadeiro código EUC. Por ser uma codificação Unicode, seu repertório é idêntico ao de outros formatos de transformação Unicode , como UTF-8 .

Mac OS Chinês simplificado

Outras variantes de EUC-CN que se desviam do mecanismo de EUC incluem o script simplificado em chinês do Mac OS (conhecido como página de código 10008 ou x-mac-chinesesimp). Ele usa os bytes 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE e 0xFF para o U com trema (ü), dois caracteres métricos de fonte especiais, o espaço sem quebra , o sinal de copyright (©), o sinal de marca registrada (™ ) e as reticências (…) respectivamente. Isso difere no que é considerado um caractere de byte único versus o primeiro byte de um caractere de dois bytes de EUC (onde, desses, 0xFD e 0xFE são definidos como bytes principais) e GBK (onde, daqueles, 0x81, 0x82, 0xFD e 0xFE são definidos como bytes iniciais).

Este uso de 0xA0, 0xFD, 0xFE e 0xFF corresponde à variante Shift_JIS da Apple .

Além dessas alterações no intervalo de bytes principais, a outra característica distintiva da parte de byte duplo do Mac OS Chinês simplificado é a inclusão de duas extensões para o GB 2312-80 básico definido nas linhas 6 e 8. Estas são consideradas "extensões padrão para GB 2312 ", nenhum dos quais é propriedade da Apple: a extensão da linha 8 foi tirada do GB 6345.1 , ambas as extensões foram incluídas pelo GB / T 12345 (a variante do chinês tradicional do GB 2312) e ambas as extensões foram incluídas pelo GB 18030 (o sucessor de GB 2312).

EUC-JP

EUC-JP
EUC-JP.svg
MIME / IANA EUC-JP
Apelido) JIS Unixized (UJIS), csEUCPkdFmtJapanese
Línguas) Japonês , inglês , russo
Classificação ISO 646 estendida , codificação de largura variável , codificação CJK , EUC
Estende US-ASCII ou ISO 646: JP
Transformações / Codificações JIS X 0208 , JIS X 0212 , JIS X 0201
Sucedido por EUC-JISx0213
EUC-JIS-2004
Apelido) EUC-JISx0213
Línguas) Japonês , Ainu , Inglês , Russo
Padrão JIS X 0213
Classificação ASCII estendido , codificação de largura variável , codificação CJK , EUC
Estende US-ASCII
Transformações / Codificações JIS X 0213 , JIS X 0201 (Kana)
Precedido por EUC-JP

EUC-JP é uma codificação de largura variável usada para representar os elementos de três padrões de conjunto de caracteres japoneses , a saber, JIS X 0208 , JIS X 0212 e JIS X 0201 . Outros nomes para essa codificação incluem Unixized JIS (ou UJIS ) e AT&T JIS . 0,1% de todas as páginas da web usam EUC-JP desde agosto de 2018, enquanto 2,5% dos sites em japonês usam essa codificação (menos usada do que Shift JIS ou UTF-8 ). É chamado de página de código 954 pela IBM. A Microsoft possui dois números de página de código para essa codificação (51932 e 20932).

Este esquema de codificação permite a fácil mistura de ASCII de 7 bits e japonês de 8 bits sem a necessidade dos caracteres de escape empregados pelo ISO-2022-JP , que é baseado nos mesmos padrões de conjunto de caracteres, e sem bytes ASCII aparecendo como bytes de trilha (ao contrário do Shift JIS ).

Uma codificação relacionada e parcialmente compatível, chamada EUC-JISx0213 ou EUC-JIS-2004 , codifica JIS X 0201 e JIS X 0213 (de forma semelhante a Shift_JISx0213 , sua contraparte baseada em Shift_JIS).

Comparado com EUC-CN ou EUC-KR, EUC-JP não se tornou tão amplamente adotado em sistemas PC e Macintosh no Japão, que usavam Shift JIS ou suas extensões ( página de código do Windows 932 no Microsoft Windows e MacJapanese no Mac OS clássico ) , embora tenha se tornado muito usado por Unix ou sistemas operacionais semelhantes ao Unix (exceto para HP-UX ). Portanto, se os sites japoneses usam EUC-JP ou Shift_JIS, muitas vezes depende de qual sistema operacional o autor usa.

Os caracteres são codificados da seguinte maneira:

  • Como uma codificação compatível com EUC / ISO 2022 , os caracteres de controle C0 , espaço e DEL são representados como em ASCII.
  • Um caractere gráfico de ASCII (conjunto de códigos 0) é representado como sua representação usual de um byte, no intervalo 0x21 - 0x7E. Enquanto algumas variantes de EUC-JP codificam a metade inferior do JIS X 0201 aqui, a maioria codifica ASCII, incluindo o padrão de codificação W3C / WHATWG usado pelo HTML5 , e o mesmo acontece com o EUC-JIS-2004. Embora isso signifique que 0x5C é tipicamente mapeado para Unicode como U + 005C REVERSE SOLIDUS (a barra invertida ASCII ), U + 005C pode ser exibido como um sinal de iene por certas fontes de localidade japonesa, por exemplo, no Microsoft Windows, para compatibilidade com a metade inferior de JIS X 0201 .
  • Um caractere de JIS X 0208 (conjunto de códigos 1) é representado por dois bytes, ambos no intervalo 0xA1 - 0xFE. Isso difere da representação ISO-2022-JP por ter o bit alto definido. Este conjunto de códigos também pode conter extensões do fornecedor em algumas variantes EUC-JP. Em EUC-JIS-2004, o primeiro plano de JIS X 0213 é codificado aqui, que é efetivamente um superconjunto do padrão JIS X 0208 .
  • Um caractere da metade superior de JIS X 0201 ( kana de meia largura , conjunto de códigos 2) é representado por dois bytes, o primeiro sendo 0x8E, o segundo sendo a representação JIS X 0201 usual no intervalo 0xA1 - 0xDF. Este conjunto pode conter extensões de fornecedores IBM em algumas variantes.
  • Um caractere de JIS X 0212 (conjunto de códigos 3) é representado em EUC-JP por três bytes, o primeiro sendo 0x8F, os dois seguintes estando no intervalo 0xA1–0xFE, ou seja, com o bit alto definido. Além do JIS X 0212 padrão , o conjunto de códigos 3 de algumas variantes EUC-JP também pode conter extensões nas linhas 83 e 84 para representar caracteres das extensões Shift JIS da IBM que não possuem mapeamentos JIS X 0212 padrão, que podem ser codificados em qualquer um dos dois layouts, um definido pela própria IBM e outro definido pela OSF . Em EUC-JIS-2004, o segundo plano de JIS X 0213 é codificado aqui, o que não colide com as linhas alocadas no padrão JIS X 0212 . Algumas implementações de EUC-JIS-2004, como a usada pelo Python , permitem caracteres do plano 2 JIS X 0212 e JIS X 0213 neste conjunto.

Métodos de codificação japoneses relacionados

As extensões do fornecedor para EUC-JP (por exemplo, da Open Software Foundation , IBM ou NEC ) eram frequentemente alocadas dentro dos conjuntos de códigos individuais, em oposição ao uso de sequências EUC inválidas (como em extensões populares de EUC-CN e EUC-KR )

No entanto, algumas codificações específicas do fornecedor são parcialmente compatíveis com EUC-JP, devido à codificação JIS X 0208 sobre GR, mas não seguem a estrutura EUC compactada. Freqüentemente, estes não incluem o uso de turnos únicos de EUC-JP e, portanto, não são extensões diretas de EUC-JP, com exceção de Super DEC Kanji.

DEC Kanji

A Digital Equipment Corporation define duas variantes de EUC-JP apenas parcialmente em conformidade com o formato EUC compactado, mas também mantendo alguma semelhança com o formato completo de dois bytes. O formato geral da codificação "DEC Kanji" corresponde principalmente a EUC de largura fixa (dois bytes completos); no entanto, o conjunto de códigos 0 não precisa ser preenchido à esquerda com bytes nulos (de forma semelhante ao formato compactado). JIS X 0208 é, como de costume, usado para o conjunto de códigos 1; o conjunto de códigos 2 (katakana de meia largura) está ausente; o conjunto de códigos 3 é codificado como o formato de largura fixa de dois bytes (ou seja, sem um byte de deslocamento e apenas com o primeiro conjunto de bits alto), mas usado para caracteres de dois bytes definidos pelo usuário em vez de ser especificado para JIS X 0212. No básico Na codificação "DEC Kanji", apenas as primeiras 31 linhas do conjunto de códigos 3 são usadas para caracteres definidos pelo usuário: as linhas 32 a 94 são reservadas, de forma semelhante às linhas não utilizadas no conjunto de códigos 1.

A codificação "Super DEC Kanji" aceita códigos tanto da codificação "DEC Kanji" quanto de EUC de formato compactado, para um total de cinco conjuntos de códigos. Também permite que todo o conjunto de códigos definidos pelo usuário e as linhas não utilizadas nas extremidades dos conjuntos de códigos JIS X 0208 e JIS X 0212 (linhas 85–94 e 78–94 respectivamente) sejam usados ​​para caracteres definidos pelo usuário.

HP-16

A Hewlett-Packard define uma codificação conhecida como "HP-16". Isso acompanha a codificação "HP-15", que é uma variante do Shift JIS . HP-16 codifica JIS X 0208 usando os mesmos bytes que em EUC-JP, mas não usa os códigos de deslocamento único (omitindo os conjuntos de código 2 e 3) e adiciona três regiões definidas pelo usuário que não seguem o formato compactado Estrutura EUC:

  • Bytes iniciais 0xA1 – C2, bytes finais 0x21–7E
  • Bytes iniciais 0xC3 – E3, bytes finais 0x21–3F
  • Bytes iniciais 0xC3 – E1, bytes finais 0x40–64

IKIS

A codificação IKIS (Interactive Kanji Information System) usada pelo Data General se assemelha ao EUC-JP sem turnos únicos, ou seja, com apenas conjuntos de código 0 e 1. Katakana de meia largura são incluídos na linha 8 do JIS X 0208 (colidindo com a caixa- desenho de personagens adicionados ao padrão em 1983). JIS X 0208 linhas 9 a 12 são usadas para caracteres definidos pelo usuário.

Adaptações de EUC-JP para EBCDIC

Artigo principal: Língua japonesa em EBCDIC

KEIS (Kanji-processing Extended Information System) é uma codificação EBCDIC usada pela Hitachi , com caracteres de byte duplo (uma codificação DBCS-Host) incluídos usando sequências de deslocamento, tornando-a uma codificação stateful . Especificamente, a sequência 0x0A 0x41muda para o modo de byte único e a sequência 0x0A 0x42muda para o modo de byte duplo. No entanto, os caracteres JIS X 0208 são codificados usando as mesmas sequências de bytes usadas para codificá-los em EUC-JP. Isso resulta em codificações duplicadas para o espaço ideográfico - 0x4040 pela estrutura de código DBCS-Host e 0xA1A1 como em EUC-JP. Isso difere da codificação DBCS-Host da IBM para japonês, cujo layout se baseia em versões anteriores ao JIS X 0208. O intervalo de bytes iniciais é estendido para 0x59, dos quais os bytes iniciais 0x81 – A0 são designados para caracteres definidos pelo usuário e o restante é usado para caracteres definidos pela empresa, incluindo kanji e não kanji.

JEF (recurso estendido de processamento japonês) é uma codificação EBCDIC usada em mainframes Fujitsu FACOM, contrastando com FMR (uma variante de Shift JIS) usada em PCs Fujitsu. Como KEIS, JEF é uma codificação stateful, alternando para um modo DBCS-Host de byte duplo usando sequências de deslocamento (onde 0x29alterna para o modo de byte único e 0x28alterna para o modo de byte duplo). Também de forma semelhante a KEIS, os códigos JIS X 0208 são representados da mesma forma que em EUC-JP. O intervalo de bytes iniciais é estendido de volta para 0x41, com 0x80 – A0 designado para definição do usuário; Os bytes iniciais 0x41–7F são atribuídos aos números de linha 101 a 163 para fins de kuten , embora a linha 162 (byte inicial 0x7E) não seja utilizada. As linhas 101 a 148 são usadas para kanji estendido, enquanto as linhas 149 a 163 são usadas para não kanji estendido.

EUC-KR

"EUC-KR" redireciona aqui. Para a variante assim chamada nos padrões HTML, consulte Código Hangul Unificado .
EUC-KR
EUC-KR sem extensões.svg
Estrutura do código EUC-KR
MIME / IANA EUC-KR
Apelido) Wansung, IBM-970
Línguas) Coreano , inglês , russo
Padrão KS X 2901 (KS C 5861)
Classificação ISO 646 estendida , codificação de largura variável , codificação CJK , EUC
Estende US-ASCII ou ISO 646: KR
Extensões Mac OS Coreano , IBM-949 , Código Hangul Unificado (Windows-949)
Transformações / Codificações KS X 1001
Sucedido por Código Hangul Unificado (padrões da web)

EUC-KR é uma codificação de largura variável para representar o texto coreano usando dois conjuntos de caracteres codificados, KS X 1001 (anteriormente KS C 5601) e ISO 646 : KR ( KS X 1003 , anteriormente KS C 5636 ) ou US-ASCII , dependendo na variante. KS X 2901 (anteriormente KS C 5861 ) estipula a codificação e o RFC  1557 apelidou-o de EUC-KR.

Um caractere extraído de KS X 1001 (G1, conjunto de códigos 1) é codificado como dois bytes em GR (0xA1–0xFE) e um caractere de KS X 1003 ou US-ASCII (G0, conjunto de códigos 0) leva um byte em GL ( 0x21–0x7E).

É geralmente referido como Wansung ( coreano : 완성 , romanizado :  Wanseong , lit.  'pré-composto') na República da Coréia . A IBM se refere ao componente de byte duplo como página de código 971 e a EUC-KR com ASCII como página de código 970 . Ele é implementado como página de código 20949 ("coreano Wansung") e página de código 51949 ("EUC coreano") pela Microsoft.

Em outubro de 2021, 0,1% de todas as páginas da web globalmente usam EUC-KR, o que é enganoso, pois 7,8% das páginas da web sul-coreanas usam (apenas o país para o qual a codificação se destina), tornando-a a mais popular não UTF-8 / Codificação Unicode para um idioma / domínio da web, enquanto apenas 3,9% das páginas da web usam o idioma coreano (fazendo com que o UTF-8 use, em 92,2%, menos popular na Coreia do Sul do que em (aparentemente) todos os países do mundo). Incluindo extensões, é a codificação de caracteres legada mais amplamente usada na Coreia em todas as três plataformas principais ( macOS , outros sistemas operacionais semelhantes ao Unix e Windows), mas seu uso tem mudado lentamente para UTF-8 à medida que ganha popularidade, especialmente no Linux e macOS.

Como a maioria das outras codificações, o UTF-8 agora é preferido para novos usos, resolvendo problemas de consistência entre plataformas e fornecedores.

Sistemas de codificação coreanos relacionados

Código Hangul Unificado

Artigo principal: Código Hangul Unificado

Uma extensão comum do EUC-KR é o Código Hangul Unificado ( 통합형 한글 코드 , Tonghabhyeong Hangeul Kodeu ou 통합 완성형 , Tonghab Wansunghyung ), que é a página de código coreana padrão no Microsoft Windows. Ele recebe o número de página de código 949 da Microsoft e 1261 ou 1363 da IBM. A página de código 949 da IBM é uma extensão EUC-KR diferente e não relacionada.

O Código Hangul Unificado estende o EUC-KR usando códigos que não estão em conformidade com a estrutura do EUC para incorporar blocos de sílaba adicionais, completando a cobertura dos blocos de sílaba compostos disponíveis em Johab e Unicode. O Padrão de Codificação W3C / WHATWG usado pelo HTML5 incorpora as extensões do Código Hangul Unificado em sua definição de EUC-KR.

Mac OS coreano (HangulTalk)

Outras codificações que incorporam EUC-KR como um subconjunto incluem o script coreano do Mac OS (conhecido como página de código 10003 ou x-mac-korean), que foi usado por HangulTalk (MacOS-KH), a localização coreana do Mac OS clássico . Ele foi desenvolvido pela Elex Computer ( 일 렉스 ), que na época era o distribuidor autorizado de computadores Apple Macintosh na Coréia do Sul.

HangulTalk adiciona caracteres de extensão com bytes iniciais entre 0xA1 e 0xAD, ambos no espaço não utilizado dentro do plano EUC-KR GR (bytes de trilha 0xA1–0xFE), e usando códigos não EUC fora dele (bytes de trilha 0x41–0xA0). Alguns desses caracteres são dingbats estilizados independentes de estilo de fonte . Muitos desses caracteres não têm mapeamentos Unicode exatos, e o software Apple mapeia esses casos de várias maneiras para combinar sequências , para aproximar os mapeamentos com um caractere de uso privado anexado como um modificador para fins de ida e volta ou para caracteres de uso privado.

A Apple também usa determinados códigos de byte único fora do plano EUC-KR para caracteres adicionais: 0x80 para um espaço necessário , 0x81 para um sinal de won (₩), 0x82 para um traço (-), 0x83 para um sinal de copyright (© ), 0x84 para um sublinhado largo (＿) e 0xFF para reticências (…). Embora nenhum desses códigos de byte único adicionais estejam dentro do intervalo de bytes principais do EUC-KR simples (ao contrário das extensões da Apple para EUC-CN, veja acima ), alguns estão dentro do intervalo de bytes principais do Código Hangul Unificado (especificamente, 0x81, 0x82 , 0x83 e 0x84).

EUC-KP

Artigo principal: KPS 9566

De forma semelhante ao KS X 1001, o padrão norte-coreano KPS 9566 é normalmente usado no formato EUC; nesses contextos, às vezes é referido como EUC-KP. As edições mais recentes do padrão estendem a representação EUC com caracteres usando códigos de dois bytes não EUC, de maneira semelhante ao Código Hangul Unificado.

EUC-TW

EUC-TW é uma codificação de largura variável que suporta US-ASCII e 16 planos de CNS 11643 , cada um dos quais é 94x94. É uma codificação raramente usada para caracteres chineses tradicionais, como em Taiwan . Variantes de Big5 são muito mais comuns do que EUC-TW, embora Big5 codifique apenas os dois primeiros planos de CNS 11643 hanzi , enquanto UTF-8 está se tornando mais comum.

  • Como uma codificação EUC / ISO 2022 , os caracteres de controle C0 , espaço ASCII e DEL são codificados como em ASCII.
  • Um caractere gráfico de US-ASCII (G0, conjunto de códigos 0) é codificado em GL como sua representação usual de byte único (0x21–0x7E).
  • Um caractere do plano 1 do CNS 11643 (conjunto de códigos 1) é codificado como dois bytes em GR (0xA1–0xFE).
  • Um caractere no plano 1 a 16 do CNS 11643 (conjunto de códigos 2) é codificado como quatro bytes:
    • O primeiro byte é sempre 0x8E (Turno Único 2).
    • O segundo byte (0xA1–0xB0) indica o plano, cujo número é obtido subtraindo 0xA0 desse byte.
    • O terceiro e o quarto bytes estão em GR (0xA1–0xFE).

Observe que o plano 1 do CNS 11643 é codificado duas vezes como o conjunto de códigos 1 e uma parte do conjunto de códigos 2.

Veja também

Notas

Referências

  1. ^ a b c d IBM . "Character Data Representation Architecture (CDRA)" . pp. 157–162.
  2. ^ a b c Lunde, Ken (2008). Processamento de informações CJKV: Computação chinesa, japonesa, coreana e vietnamita . O'Reilly. pp. 242–244. ISBN 9780596800925.
  3. ^ "Conjuntos de caracteres" . IANA.
  4. ^ "4.2. Nomes e rótulos" . Padrão de codificação . WHATWG.
  5. ^ a b c d "Mapeie (versão externa) da codificação Mac OS Chinês Simplificado para Unicode 3.0 e posterior" . A Apple, Inc .
  6. ^ a b "Propriedade Encoding.WindowsCodePage - .NET Framework (versão atual)" . MSDN . Microsoft.
  7. ^ Lunde, Ken (1998). Apêndice F: GB / T 12345 (PDF) . Processamento de informações CJKV . O'Reilly Media . ISBN 9781565922242.
  8. ^ Standardization Administration of China (SAC) (2005-11-18). GB 18030-2005: Tecnologia da Informação - conjunto de caracteres codificados em chinês .
  9. ^ a b "Tendências históricas no uso de codificações de caracteres para sites" . W3Techs.
  10. ^ "Documento de informação CCSID 954" . Arquivado do original em 27/03/2016.
  11. ^ International Components for Unicode (ICU), ibm-954_P101-2007.ucm , 2002-12-03
  12. ^ a b c d "Tabelas de mapeamento de código JIS X 0213" . x0213.org.
  13. ^ "Ambiguidades na conversão de EUC japonês para Unicode (não normativo)" . Perfil XML Japonês . W3C.
  14. ^ "Decodificador EUC-JP" . Padrão de codificação . WHATWG. "Se o byte for um byte ASCII, retorna um ponto de código cujo valor é byte."
  15. ^ "3.1.1 Detalhes dos Problemas" . Problemas e soluções para caracteres Unicode e definidos pelo usuário / fornecedor . The Open Group Japan. Arquivado do original em 03/02/1999 . Página visitada em 2014-08-14 .
  16. ^ Kaplan, Michael S. (17/09/2005). "Quando uma barra invertida não é uma barra invertida?" .
  17. ^ a b "4.2 Processo de revisão das regras para a conversão do conjunto de códigos entre eucJP-open e UCS" . Problemas e soluções para caracteres Unicode e definidos pelo usuário / fornecedor . The Open Group Japan. Arquivado do original em 03/02/1999 . Página visitada em 2014-08-14 .
  18. ^ a b Lunde, Ken (13 de janeiro de 2009). "Apêndice J: Conjuntos de caracteres japoneses" (PDF) . CJKV Information Processing (2ª ed.). ISBN 978-0-596-51447-1.
  19. ^ a b Chang, Hyeshik. "Leiame para CJKCodecs" . cPython . Python Software Foundation.
  20. ^ a b c d e f g h i Lunde, Ken (13 de janeiro de 2009). "Apêndice F: Métodos de codificação do fornecedor" (PDF) . CJKV Information Processing (2ª ed.). ISBN 978-0-596-51447-1.
  21. ^ a b c d e f g h i j Lunde, Ken (2009). "Apêndice E: Padrões do conjunto de caracteres do fornecedor" (PDF) . CJKV Information Processing: Chinese, Japanese, Korean & Vietnamese Computing (2nd ed.). Sebastopol, CA : O'Reilly . ISBN 978-0-596-51447-1.
  22. ^ a b "2: Conjuntos de códigos e conversão de conjuntos de códigos" . Referência técnica DIGITAL UNIX para usar recursos japoneses . Digital Equipment Corporation , Compaq .
  23. ^ "KS X 1001: 1992" (PDF) .
  24. ^ "KS C 5601: 1987" (PDF) . 1988-10-01.
  25. ^ Lunde, Ken (2009). "Capítulo 3: Padrões do conjunto de caracteres" . Processamento de informações CJKV . p. 146. ISBN 978-0596514471.
  26. ^ "IBM Globalization - Coded character set identifiers - CCSID 971" . Recuperado em 2021-09-03 .
  27. ^ "CCSID 970" . Globalização da IBM . IBM. Arquivado do original em 01-12-2014.
  28. ^ "ibm-970_P110_P110-2006_U2 (alias euc-kr)" . Converter Explorer - Demonstração ICU . Componentes internacionais para Unicode.
  29. ^ International Components for Unicode (ICU), ibm-970_P110_P110-2006_U2.ucm , 2002-12-03
  30. ^ a b "Identificadores de página de código" . Centro de Desenvolvimento do Windows . Microsoft.
  31. ^ Julliard, Alexandre. "dump_krwansung_codepage: compilar tabela Wansung coreana a partir do arquivo KSX1001" . make_unicode: Gere arquivos de página de código .c a partir de descrições ftp.unicode.org . Wine Project .
  32. ^ "Distribuição de codificações de caracteres entre sites que usam .kr" . w3techs.com . Recuperado em 2021-10-17 .
  33. ^ "Distribuição de codificações de caracteres entre sites que usam coreano" . w3techs.com . Página visitada em 2020-07-03 .
  34. ^ "한글 코드 에 대하여" (em coreano). W3C. Arquivado do original em 24/05/2013 . Recuperado em 07-01-2019 .
  35. ^ Em ucnv_lmb.cpp , um arquivo originário da IBM e incluído naárvore de origem International Components for Unicode , o byte principal 0x11 é comentado como referindo-se a "Korean: ibm-1261" após a definição deULMBCS_GRP_KOe é mapeado para o"windows-949"codec ICU naOptGroupByteToCPNamematriz posteriormente no arquivo.
  36. ^ "Coded character set identifiers - CCSID 1363" , IBM Globalization , IBM, arquivado do original em 2014-11-29
  37. ^ "5. Índices (§ index EUC-KR)" , Padrão de Codificação , WHATWG
  38. ^ Gil, Hojin. "HangulTalk: ambiente Hangul padrão de fato para Mac" . Guia para usar o Hangul no Macintosh .
  39. ^ a b Apple (2005-04-05). "Mapear (versão externa) da codificação Mac OS coreano para Unicode 3.2 e posterior" . Consórcio Unicode .
  40. ^ Kim, Kyongsok (30/11/2002). "Tabelas de referência cruzada de 3 vias - KS X 1001, KPS 9566 e UCS" (PDF) . ISO / IEC JTC 1 / SC 2 / WG 2 N2564.[Nota: links atualizados para as tabelas que acompanham o documento: [1] [2] ]
  41. ^ Chung, Jaemin (05/01/2018). "Informações sobre a versão mais recente do KPS 9566 (KPS 9566-2011?)" (PDF) . UTC L2 / 18-011.

links externos