Por que existem várias codificações Unicode?

Eu pensei que o Unicode foi projetado para contornar todo o problema de ter muitas codificações diferentes devido a um pequeno espaço de endereço (8 bits) na maioria das tentativas anteriores (ASCII, etc.).

Por que, então, existem tantas codificações Unicode? Até várias versões do (essencialmente) o mesmo, como UTF-8, UTF-16, etc.

Porque as pessoas não querem gastar 21 bits em cada personagem. Em todos os sistemas modernos, isso significaria essencialmente o uso de três bytes por caractere, o que é três vezes mais do que as pessoas estavam acostumadas, portanto, não estavam dispostas a adotar o Unicode. É necessário encontrar compromissos: por exemplo, o UTF-8 é ótimo para o texto em inglês porque os arquivos ASCII herdados não precisam ser convertidos, mas são menos úteis para os idiomas europeus e pouco utilizados para os idiomas asiáticos.

Então, basicamente, sim, poderíamos ter definido uma única codificação universal e um único gráfico de caracteres universal, mas o mercado não a aceitaria.

Unicode é um caractere de 21 bits que codifica exclusivamente os "CodePoints", cada pontos de código sendo representados por um glifo (uma representação gráfica).

• 16 bits usados ​​para identificar um ponto de código em um plano (a maioria dos pontos de código está no plano 0).
• 5 bits para identificar o avião.

As codificações suportadas são:

• UTF-8 (para codificar cada ponto usando valores de 8 bits)
• UTF-16 (para codificar cada ponto usando valores de 16 bits)
• UTF-32 (para codificar cada ponto usando valores de 32 bits)

Mas não importa qual seja a codificação quando você decodifica, todos eles são mapeados de volta para um ponto de código específico que tem o mesmo significado (e é por isso que é legal).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LATINA PEQUENA LATINA OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Não atribuído (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

Este é um formato de tamanho variável. Onde cada ponto de código é representado por 1 a 4 bytes.

UTF-16

Este é um formato de tamanho variável. Os pontos de código no "Plano multilíngue básico" (BMP ou Plano 0) podem ser representados por um valor único de 16 bits. Os pontos de código em outros planos são representados por um par substituto (2 valores de 16 bits).

UTF-32

Este é um formato de tamanho fixo. Todos os pontos de código são representados por um único valor de 32 bits.

Eu acho que é útil separar as 2 idéias:

1. Unicode - mapeamento de caracteres de todo o mundo para pontos de código.
2. Codificação - mapeamento de pontos de código para padrões de bits (UTF-8, UTF-16, etc).

As codificações UTF-8, UTF-16 e outras possuem vantagens e desvantagens. Melhor consultar a Wikipedia sobre isso.

UTF-7, UTF-8, UTF-16 e UTF-32 são simplesmente formatos de transformação algorítmica da mesma codificação (pontos de código) de caracteres. São codificações de um sistema de codificação de caracteres.

Eles também são algoritmicamente mais fáceis de navegar para frente e para trás do que a maioria dos esquemas anteriores para lidar com conjuntos de caracteres maiores que 256 caracteres.

Isso é muito diferente da codificação de glifos geralmente específica para o país e, às vezes, para o fornecedor. Somente no japonês, havia uma tonelada de variações do JIS sozinho, sem mencionar o EUC-JP e a transformação do JIS orientada por página de código que as máquinas DOS / Windows usavam chamada Shift-JIS. (Até certo ponto, houve transformações algorítmicas delas, mas elas não eram particularmente simples e havia diferenças específicas de fornecedor em caracteres que estavam disponíveis. Multiplique isso por algumas centenas de países e a evolução gradual de sistemas de fontes mais sofisticados (post greenscreen era) e você teve um pesadelo real.

Por que você precisaria dessas formas de transformação do Unicode? Como muitos sistemas legados assumiram sequências de caracteres de 7 bits do intervalo ASCII, você precisou de uma solução limpa de 7 bits que passasse com segurança os dados não corrompidos por esses sistemas; portanto, precisava de UTF-7. Depois, havia sistemas mais modernos que podiam lidar com conjuntos de caracteres de 8 bits, mas os nulos geralmente tinham significados especiais para eles, portanto o UTF-16 não funcionava para eles. 2 bytes poderiam codificar todo o plano multilíngue básico do Unicode em sua primeira encarnação, de modo que o UCS-2 parecia uma abordagem razoável para sistemas que seriam "sensíveis ao Unicode desde o início" (como Windows NT e Java VM); as extensões além desses precisavam de caracteres adicionais, que resultou na transformação algorítmica dos 21 bits de codificações reservadas pelo padrão Unicode, e nasceram pares substitutos; isso exigia UTF-16. Se você tivesse alguma aplicação em que a consistência da largura dos caracteres fosse mais importante que a eficiência do armazenamento, o UTF-32 (uma vez chamado UCS-4) era uma opção.

UTF-16 é a única coisa remotamente complexa de se lidar, e é facilmente mitigada pelo pequeno intervalo de caracteres afetados por essa transformação e pelo fato de que as sequências principais de 16 bits estão ordenadamente em um intervalo totalmente distinto do final Sequências de 16 bits. Também é um mundo mais fácil do que tentar avançar e retroceder em muitas codificações do início do Leste Asiático, onde você precisava de uma máquina de estado (JIS e EUC) para lidar com as seqüências de escape ou potencialmente retrocedeu vários caracteres até encontrar algo garantido. ser apenas um byte principal (Shift-JIS). O UTF-16 tinha algumas vantagens em sistemas que também podiam executar sequências de 16 bits com eficiência.

A menos que você tenha que viver com dezenas (centenas, realmente) de codificações diferentes por aí, ou tenha que criar sistemas que suportem vários idiomas em codificações diferentes, às vezes até no mesmo documento (como o WorldScript nas versões mais antigas do MacOs), você pode pensar dos formatos de transformação unicode como complexidade desnecessária. Mas é uma redução drástica da complexidade em relação às alternativas anteriores, e cada formato resolve uma restrição técnica real. Eles também são realmente eficientemente conversíveis entre si, não exigindo tabelas de pesquisa complexas.

O Unicode não foi projetado para contornar todo o problema de ter muitas codificações diferentes.

O Unicode foi projetado para contornar toda a questão de um número que representa muitas coisas diferentes, dependendo da página de código em uso. Os números de 0 a 127 representam os mesmos caracteres em qualquer página de código Ansi. Isso é também conhecido como gráfico ASCII ou conjunto de caracteres. Nas páginas de código Ansi, que permitem 256 caracteres, os números 128 a 255 representam caracteres diferentes em diferentes páginas de código.

Por exemplo

• O número $ 57 representa um W maiúsculo em todas as páginas de código, mas
• O número $ EC representa o símbolo de inifinity na página de código 437 (EUA), mas uma "LETRA LATINA PEQUENA N COM CEDILHA" na página de código 775 (Báltico)
• O sinal de centavo é o número $ 9B na página de código 437, mas o número 96 na página de código 775

O que o Unicode fez foi virar tudo de cabeça para baixo. No Unicode, não há "reutilização". Cada número representa um único caractere único. O número $ 00A2 em Unicode é o sinal de centavo e o sinal de centavo não aparece em nenhum outro lugar na definição de Unicode.

Por que, então, existem tantas codificações Unicode? Até várias versões do (essencialmente) o mesmo, como UTF-8, UTF-16, etc.

Não há várias versões da mesma codificação. Existem várias codificações do mesmo mapa de definição de caracteres Unicode e elas foram "inventadas" para administrar requisitos de armazenamento para diferentes usos dos vários planos linguais existentes no Unicode.

Unicode define (ou tem espaço para definir) 4.294.967.295 caracteres únicos. Se você deseja mapear esses dados para o armazenamento em disco / memória sem fazer nenhuma conversão algorítmica, precisará de 4 bytes por caractere. Se você precisar armazenar textos com caracteres de todos os planos linguais, provavelmente é o que você precisa UTF-32 (que é basicamente uma codificação direta de armazenamento de 1 caractere - 4 bytes da definição de unicode).

Mas quase nenhum texto usa caracteres de todos os planos linguais. E então usar 4 bytes por caractere parece um grande desperdício. Especialmente quando você leva em consideração que a maioria dos idiomas do mundo é definida dentro do que é conhecido como Plano Multilíngue Básico (BMP): os primeiros 65536 números da definição Unicode.

E foi aí que entrou o UTF-16. Se você usar apenas caracteres do BMP, o UTF-16 armazenará isso de maneira muito eficiente usando apenas dois bytes por caractere. Ele usará apenas mais bytes para caracteres fora do BMP. A distinção entre UTF-16LE (Little Endian) e UTF-16BE (Big Endian) realmente tem algo a ver com a forma como os números são representados na memória do computador (padrão de bytes que A0significa hex $ A0 ou $ 0A).

Se o seu texto usar ainda menos caracteres diferentes, como a maioria dos textos nos idiomas da Europa Ocidental, você desejará restringir ainda mais os requisitos de armazenamento para seus textos. Portanto, o UTF-8, que usa um único byte para armazenar os caracteres presentes no gráfico ASCII (os primeiros 128 números) e uma seleção dos caracteres Ansi (os segundos 128 números das várias páginas de códigos). Ele usará apenas mais bytes para caracteres fora deste conjunto de "caracteres mais usados".

Então, para recapitular:

• Unicode é um mapeamento dos caracteres em todos os idiomas do mundo (e alguns klingon para inicializar) e depois alguns (matemáticos, musicais, etc.) para um número único.
• Codificações são algoritmos definidos para armazenar textos usando os números desse mapa de caracteres exclusivo da maneira mais eficiente possível, com o espaço possível, considerando o "uso médio" dos caracteres nos textos.

Unicode define o mapa entre números e caracteres. No entanto, quando você envia um número para um destinatário, ainda precisa definir como representar esse número. É para isso que serve a UTF. Ele define como representar um número em um fluxo de bytes.

A lógica por trás do UTF-32 é simples: é a representação mais direta dos pontos de código Unicode. Então, por que não está tudo em UTF-32? Duas razões principais:

Um é o tamanho . UTF-32 requer 4 bytes para cada caractere. Para texto que usa apenas caracteres no local multilíngue básico, isso é duas vezes mais espaço que UTF-16. Para texto em inglês, é 4 vezes mais espaço que US-ASCII.

A razão maior é a compatibilidade com versões anteriores . Cada codificação Unicode diferente do UTF-32 "não codificado" foi projetada para compatibilidade com versões anteriores com um padrão anterior.

• UTF-8: Compatibilidade com versões anteriores com US-ASCII.
• UTF-16: Compatibilidade com versões anteriores do UCS-2 (Unicode de 16 bits antes de ser expandido além do BMP).
• UTF-7: Compatibilidade com versões anteriores com servidores de correio não limpos de 8 bits.
• GB18030: Compatibilidade com versões anteriores com as codificações GB2312 e GBK para chinês.
• UTF-EBCDIC: Compatibilidade com versões anteriores com o subconjunto Latino básico do EBCDIC.

Eu pensei que o Unicode foi projetado para contornar toda a questão de ter muitas codificações diferentes

Foi, e fez. É muito mais fácil converter entre UTF-8, -16 e -32 do que lidar com o sistema antigo de centenas de codificações de caracteres diferentes para diferentes idiomas e sistemas operacionais diferentes.

Você sabe que um arquivo zip pode compactar um arquivo para ser muito menor (especialmente texto) e descompactá-lo em uma cópia idêntica do arquivo original.

Na verdade, o algoritmo de zipagem tem vários algoritmos diferentes com características diferentes para escolher: armazenado (sem compactação), Encolhido, Reduzido (métodos 1-4), Imploded, Tokenizing, Deflated, Deflate64, BZIP2, LZMA (EFS), WavPack, PPMd, onde, teoricamente, poderia tentar todos eles e escolher o melhor resultado, mas geralmente basta usar Deflated.

UTF funciona da mesma maneira. Existem vários algoritmos de codificação, cada um com características diferentes, mas geralmente você escolhe UTF-8 porque ele é amplamente suportado em oposição a outras variantes UTF, o que, por sua vez, é porque é bit a bit compatível com o ASCII de 7 bits, facilitando use na maioria das plataformas de computadores modernas que geralmente usam uma extensão de 8 bits do ASCII.