Que limitação encararemos se cada caractere percebido pelo usuário for atribuído a um codepoint?

5

Quais limitações teremos se os padrões Unicode tivessem decidido atribuir um e apenas um ponto de código a cada caractere percebido pelo usuário?

Atualmente, o Unicode possui pontos de código que correspondem à combinação de caracteres. Esses caracteres se combinam com um ponto de código anterior (ou sequência dele) para apresentar ao usuário o que parece ser um único caractere.

Pelo que vejo, o padrão atual é cheio de complexidades. (Estamos não falando sobre problema de codificação aqui. Mesmo que tentemos evitar qualquer tipo de complexidade usando uma codificação como UTF-32, o problema ainda persiste .

Por exemplo, em Unicode quando um cluster de grafema é representado internamente por uma sequência de caracteres que consiste em caractere base + acento, então quando o usuário clica no botão para pular para o próximo usuário percebido caractere, tivemos que pular do início do caractere base para o final do último caractere do cluster.

Por que precisa ser tão difícil? Por que o Unicode não pode atribuir um único ponto de código a cada caractere percebido pelo usuário? Ir ao personagem percebido pelo usuário é simplesmente uma questão de ler o próximo ponto de código?

O site unicode parece reconhecer essa complexidade:

In those relatively rare [not rare at all!] circumstances where programmers need to supply end users with user-perceived character counts, the counts should correspond to the number of segments delimited by grapheme clusters. Grapheme clusters may also be used in searching and matching

Os diacríticos também são a razão pela qual as coisas não funcionam como esperado. Por exemplo, se eu jogar 2 ピ caracteres (japonês katakana PI usando a representação unicode U+30d2 U+309a ) em um Construtor de strings e invertê-lo, eu naturalmente esperaria que a saída fosse de 2 ピ caracteres (ou seja, ピ ピ), mas dá uma saída inválida de ゚ ピ ヒ!

Se o Unicode tivesse atribuído pontos de código individuais para cada caractere percebido pelo usuário e descartasse a ideia de clusters de grafema, isso não teria acontecido.

O que eu gostaria de saber é, o que exatamente está errado em representar cada caractere percebido pelo usuário como um ponto de código unicode? É provável que isso ultrapasse U + 10FFFF possíveis pontos de código (se exceder os pontos de código U + 10FFFF não vejo razão para que eles não tenham definido o limite para 2 ^ 32 em primeiro lugar), mesmo quando há muito espaço livre para incluir toda a família de Idiomas Elfos ?

Estados Unicode :

If you wanted, for example, to give each “instance of a character on paper throughout history” its own code, you might need trillions or quadrillions of such codes;

Mas, falando sério, isso não faz sentido. Onde está a fonte para fazer tal afirmação? Um trilhão de códigos é uma afirmação exagerada.

    
por Pacerier 09.12.2011 / 00:10
fonte

3 respostas

4

As origens da Unicode remontam a 1987-1988, quando Joseph D. Becker publicou a primeira proposta preliminar Unicode . Uma codificação de largura fixa de 16 bits (UCS-2) era uma parte indispensável de seu design. Ele estava muito orgulhoso da distinção que ele fez entre caracteres e glifos, apenas para espremer tudo para esse pequeno intervalo. Infelizmente suas hipóteses ingênuas foram provadas erradas, ou pelo menos irrealistas, quando em 1996 o espaço de código Unicode foi aumentado além do limite de 16 bits e o UCS-2 foi estendido para UTF-16. Atualmente, o Unicode tem quase o dobro de pontos de código alocados do que o espaço de código do design original de Becker.

[...] if it does exceed U+10FFFF code points I see no reason why they couldn't have set the limit to 2^32 in the first place [...]

Atualmente é limitado por U + 10FFFF, porque é o máximo alcance possível de ser codificado com UTF-16. O UTF-16 é um hack feio aplicado no final do dia para estender o espaço de código. Não é extensível. UTF-8, por outro lado é. Originalmente, o UTF-8 permitia codificar 2 31 codepoints e, posteriormente, limitou-se a apenas corresponder ao mesmo intervalo que o UTF-16. Na verdade, você pode estender indefinidamente o esquema usado pelo UTF-8, até mesmo codificar 2 128 codepoints e preservar todas as boas propriedades do UTF-8 ao mesmo tempo (correspondência de substring não ambígua lexicograficamente comparável com UTF-8). -8 código inconsciente, etc ...) exceto que você não será capaz de determinar o tamanho do codepoint do primeiro byte.

From what I can see, the current standard is full of complexities. Even if I try to avoid any kind of complexities by using an encoding like UTF-32, this problem still persists. It's not an encoding issue at all.

Exatamente! Gostaria de salientar que as codificações de tamanho variável não são o problema . De fato, encontrar o próximo ponto de código em uma string UTF-8 é simples, basta procurar pelo próximo byte do formulário 0xxxxxxx ou 11xxxxxx . Assim, poderíamos facilmente aumentar o espaço de código disponível sem aumentar o consumo médio de memória. O problema real é que, para encontrar o próximo grafema, você deve ter um banco de dados Unicode disponível (de alguma forma), que é definitivamente complexo e caro para muitas aplicações simples.

    
por 31.12.2011 / 21:17
fonte
3

Se um script tiver M letras e N diacríticos, uma representação pré-composta precisará de até M*N pontos de código, enquanto uma representação decomposta requer apenas M+N . A combinação de caracteres impede que o Unicode "fique sem pontos de código".

    
por 09.12.2011 / 01:52
fonte
2

é porque, antigamente, uma unidade de dados era de 8 bits, a arquitetura de 32 bits difundida é mais jovem do que o antigo padrão ASCII no qual as variantes UTF são baseadas (para compatibilidade com versões anteriores)

além de programadores naquelas arquiteturas antigas ( sizeof(int)== 16 bits ) nunca gostaram de usar mais recursos do que o necessário (memória em particular lembre-se que UTF32 ocupa 4 vezes tanta memória quanto UTF8 para texto somente no alfabeto latino ) como no passado você só tem algumas centenas de kilobytes à sua disposição na melhor das hipóteses

e você não precisa de nenhum outro caractere que não seja ASCII se estiver programando apenas para o inglês (ou qualquer outro idioma sem sotaque)

uma grande lição que você pode aprender aqui é: qualquer coisa que cresça para mudar requisitos raramente é uma prova futura contra a próxima mudança nos requisitos e geralmente apenas boa o suficiente para os requisitos atuais e se alguém pensar em uma solução que excede os requisitos provavelmente será abatido por várias razões (mais comum será o desempenho, uso de memória e compatibilidade)

também permite que eu aponte para este comic xkcd que pode lançar alguma luz sobre a situação

    
por 09.12.2011 / 00:37
fonte