Pergunta

Ok. Eu sei que isto se parece com o típico "Por que ele não apenas o Google-lo ou ir para a www.unicode.org e procurá-lo? " questão, mas para uma pergunta tão simples a resposta ainda me escapa depois de verificar ambas as fontes.

Estou bastante certo de que todos os três destes sistemas de codificação suportam todos os caracteres Unicode, mas eu preciso para confirmá-la antes de eu fazer essa reivindicação em uma apresentação.

Bônus pergunta: Será que essas codificações diferem no número de caracteres que pode ser estendido para suportar

?
Foi útil?

Solução

Não, eles são simplesmente diferentes métodos de codificação. Eles todo o apoio que codifica o mesmo conjunto de caracteres.

UTF-8 usa de um a quatro bytes por caractere, dependendo do que personagem que você está codificação. Caracteres dentro da faixa de ASCII tomar apenas um byte, enquanto personagens muito incomuns levar de quatro.

UTF-32 usa quatro bytes por caractere, independentemente de qual personagem é, por isso sempre vai usar mais espaço do que UTF-8 para codificar a mesma cadeia. A única vantagem é que você pode calcular o número de caracteres em uma string UTF-32 por bytes única contagem.

UTF-16 usa dois bytes para a maioria dos charactes, quatro bytes para os incomuns.

http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings

Outras dicas

Não há caracteres Unicode que podem ser armazenados em uma codificação, mas não outra. Isto é simplesmente porque os caracteres Unicode válidos foram restringidas ao que pode ser armazenado em UTF-16 (que tem a menor capacidade dos três codificações). Em outras palavras, UTF-8 e e UTF-32 pode ser usado para representar uma gama mais ampla de caracteres de UTF-16, mas eles não são . Leia sobre para obter mais detalhes.

UTF-8

UTF-8 é um código de comprimento variável. Alguns caracteres requerem um byte, alguns requerem 2, cerca de 3 e cerca de 4. Os bytes para cada caractere são simplesmente escritos um após o outro como uma corrente contínua de bytes.

Enquanto alguns caracteres UTF-8 pode ser de 4 bytes de comprimento, UTF-8 não pode codificar 2 ^ 32 caracteres . Não é nem perto. Vou tentar explicar as razões para isso.

O software que lê um fluxo UTF-8 só fica uma sequência de bytes - como é suposto para decidir se os próximos 4 bytes é um único caractere de 4 bytes, ou dois caracteres de 2 bytes, ou quatro de 1 byte caracteres (ou alguma outra combinação)? Basicamente isso é feito ao decidir que certas sequências de 1 byte não são caracteres válidos, e certas sequências de 2 bytes não são caracteres válidos, e assim por diante. Quando essas sequências inválidos aparecem, presume-se que eles formam parte de um mais sequência.

Você já viu um exemplo bastante diferente deste, eu tenho certeza: ele é chamado escapar. Em muitas linguagens de programação é decidido que o personagem \ no código-fonte de uma string não se traduz em qualquer caractere válido em forma "compilada" da string. Quando uma \ é encontrado na fonte, presume-se que seja parte de uma sequência mais longa, como \n ou \xFF. Note-se que \x é uma seqüência de 2 caracteres inválidos, e \xF é uma sequência de 3 caracteres inválidos, mas \xFF é uma seqüência de 4 caracteres válido.

Basicamente, há um trade-off entre ter muitos personagens e ter caracteres mais curtos. Se você quiser 2 ^ 32 caracteres, eles precisam ser, em média, 4 bytes de comprimento. Se você quiser todos os seus personagens para ser 2 bytes ou menos, então você não pode ter mais de 2 ^ 16 caracteres. UTF-8 dá um compromisso razoável: todos ASCII caracteres (ASCII 0 a 127) são dadas 1- representações de byte, que é ótimo para a compatibilidade, mas muitos mais caracteres são permitidos.

Como a maioria das codificações de comprimento variável, incluindo os tipos de sequências de escape mostradas acima, UTF-8 é um instantânea código. Isto significa que, o decodificador apenas lê byte a byte e assim que alcança o último byte de um caractere, ele sabe o que o personagem é (e ele sabe que não o início de uma mais de caracteres).

Por exemplo, o caractere 'A' é representado usando o byte 65, e não há dois caracteres / três / quatro bytes cujo primeiro byte é 65. Caso contrário, o decodificador não seria capaz de dizer os personagens para além de um 'A' seguido por outra coisa.

Mas UTF-8 é restrito ainda mais. Ele garante que a codificação de um personagem menor nunca aparece qualquer dentro da codificação de um personagem mais. Por exemplo, nenhum dos bytes de um carácter de 4 bytes pode ser 65.

Desde UTF-8 tem 128 diferentes caracteres de 1 byte (cujos valores são byte 0-127), todos os caracteres 2, 3 e 4 bytes devem ser compostas unicamente de bytes no intervalo 128-256. Isso é uma grande restrição. No entanto, permite funções de cadeia orientada a byte para trabalhar com pouca ou nenhuma modificação. Por exemplo, C de strstr() função sempre funciona como esperado se suas entradas são válidos UTF-8 cordas.

UTF-16

UTF-16 também é um código de comprimento variável; seus caracteres consumir 2 ou 4 bytes. valores de 2 bytes no intervalo 0xD800-0xDFFF são reserved para construir caracteres de 4 bytes, e todos os caracteres de 4 bytes consistem de dois bytes no intervalo 0xD800-0xDBFF seguido por 2 bytes no intervalo 0xDC00-0xDFFF. Por esta razão, Unicode não atribui quaisquer caracteres no intervalo de U + D800-U + DFFF.

UTF-32

UTF-32 é um código de comprimento fixo, com cada caractere a ser 4 bytes de comprimento. Enquanto isto permite a codificação de 2 ^ 32 caracteres diferentes, somente valores entre 0 e 0x10FFFF são permitidos neste esquema.

comparação Capacidade:

  • UTF-8: 2.097.152 (na verdade 2166912 mas devido a projetar detalhes alguns deles são mapeados para a mesma coisa)
  • UTF-16: 1.112.064
  • UTF-32: 4294967296 (mas restrita à primeira 1.114.112)

O mais restrita é, portanto, UTF-16! A definição formal Unicode tem limitado os caracteres Unicode para aqueles que podem ser codificados com UTF-16 (i.e. a gama L + 0000 a U + 10FFFF excluindo L + D800 a U + DFFF). UTF-8 e UTF-32 suporte todos esses caracteres.

O sistema UTF-8 é de fato "artificialmente" limitado a 4 bytes. Ele pode ser estendido a 8 bytes sem violar as restrições I descritos anteriormente, e isto produziria uma capacidade de 2 ^ 42. A especificação original UTF-8, de facto, permitido até 6 bytes, o que dá uma capacidade de 2 ^ 31. Mas RFC 3629 limitado para 4 bytes, uma vez que é o quanto é necessário para cobrir tudo o que UTF-16 faz.

Existem outras (principalmente históricas) Unicode esquemas de codificação, nomeadamente UCS-2 (que é apenas capaz de codificar U + 0000 a U + FFFF).

UTF-8, UTF-16 e UTF-32 todo o apoio do conjunto completo de pontos de código Unicode. Não há personagens que são suportados por um, mas não o outro.

Quanto à questão de bônus "Será que essas codificações diferem no número de caracteres que pode ser estendido para suporte?" Sim e não. A maneira UTF-8 e UTF-16 são codificados limites o número total de pontos de código que pode suportar a menos do que 2 ^ 32. No entanto, o Consórcio Unicode não irá adicionar pontos de código para UTF-32 que não podem ser representados em UTF-8 ou UTF-16. Fazê-lo seria violar o espírito dos padrões de codificação, e torná-lo impossível garantir um mapeamento um-para-um de UTF-32 para UTF-8 (ou UTF-16).

Eu, pessoalmente, sempre verificar post de Joel sobre unicode, codificações e conjuntos de caracteres quando em dúvida.

Todos os UTF-8/16/32 codificações pode mapear todos os caracteres Unicode. Consulte Wikipedia

Este artigo IBM codificar seus documentos XML em UTF-8 é muito útil, e indica se você tem a opção, é melhor escolher UTF-8. Principalmente as razões são suporte da ferramenta de largura, e UTF-8 pode normalmente passar por sistemas que não têm conhecimento do unicode.

Na seção O que as especificações dizem na IBM artigo :

Tanto o W3C e IETF tem recentemente se tornou mais inflexível sobre a escolha UTF-8 primeiro, último, e só as vezes. O caráter W3C Modelo para a World Wide Web 1.0: Fundamentos estados ", quando um único codificação de caracteres é necessário, o codificação de caracteres deve ser UTF-8, UTF-16 ou UTF-32. US-ASCII é para cima compatível com UTF-8 (um corda US-ASCII é também um UTF-8 corda, ver [RFC 3629]), e UTF-8 é portanto, apropriado se a compatibilidade com é desejada US-ASCII ". Em prática, a compatibilidade com US-ASCII é tão útil é quase um requerimento. O W3C sabiamente explica, "Em outras situações, como por APIs, UTF-16 ou UTF-32 pode ser mais apropriada. Possíveis razões para escolhendo um destes incluem eficiência de processamento interno e interoperabilidade com outros processos ".

Como todos disse, UTF-8, UTF-16 e UTF-32 podem todos codificar todos os pontos de código Unicode. No entanto, a UCS-2 (por vezes erradamente referida como UCS-16) variante não pode , e isso é o que você encontrar, por exemplo, no Windows XP / Vista .

Consulte Wikipedia para obter mais informações.

Editar: eu estou errado sobre o Windows, NT foi o único a apoiar a UCS-2. No entanto, muitas aplicações do Windows irá assumir uma única palavra por ponto de código como no UCS-2, então é provável que você encontrar bugs. Consulte outro artigo Wikipedia . (Graças JasonTrue)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top