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

Question

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

#1 resposta do (4 votos)
#2 resposta do (3 votos)
#3 resposta do (2 votos)

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.

character-encoding unicode internationalization

por Pacerier 09.12.2011 / 00:10

fonte

3 respostas

Tags character-encoding unicode internationalization

Como escolher um bom nome de namespace? (Linguísticamente) GUIs do Windows: Por quanto tempo as APIs 'obsoletas' duram? [fechadas]

score 4 · Answer 1

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 ³¹ 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 ¹²⁸ 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.

score 3 · Answer 2

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".

score 2 · Answer 3

é 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