O UTF-16 deve ser considerado prejudicial?

Vou perguntar o que provavelmente é uma pergunta bastante controversa: "Uma das codificações mais populares, UTF-16, deve ser considerada prejudicial?"

Por que faço essa pergunta?

Quantos programadores estão cientes do fato de que o UTF-16 é realmente uma codificação de comprimento variável? Com isso, quero dizer que existem pontos de código que, representados como pares substitutos, levam mais de um elemento.

Eu sei; muitos aplicativos, estruturas e APIs usam UTF-16, como String de Java, String de C #, APIs Win32, bibliotecas Qt GUI, biblioteca ICU Unicode etc. No entanto, com tudo isso, existem muitos bugs básicos no processamento de caracteres fora do BMP (caracteres que devem ser codificados usando dois elementos UTF-16).

Por exemplo, tente editar um desses caracteres:

• 𝄞 ( U + 1D11E ) SÍMBOLO MUSICAL G CLEF
• 𝕥 ( U + 1D565 ) T PEQUENO DE CURSO DUPLO MATEMÁTICO
• 𝟶 ( U + 1D7F6 ) ZERO DO DÍGITO DO MONOSPAÇO MATEMÁTICO
• 𠂊 ( U + 2008A ) Personagem Han

Você pode perder alguns, dependendo das fontes instaladas. Esses caracteres estão todos fora do BMP (Basic Multilingual Plane). Se você não conseguir ver esses caracteres, tente também examiná-los na referência de Caracteres Unicode .

Por exemplo, tente criar nomes de arquivos no Windows que incluam esses caracteres; tente excluir esses caracteres com um "backspace" para ver como eles se comportam em diferentes aplicativos que usam UTF-16. Eu fiz alguns testes e os resultados são muito ruins:

• O Opera tem problemas com a edição (exclua 2 pressionamentos necessários no backspace)
• O bloco de notas não pode lidar com eles corretamente (exclua 2 pressionamentos necessários no backspace)
• Edição de nomes de arquivo nas caixas de diálogo da Janela quebradas (excluir 2 pressionadas necessárias no backspace)
• Todos os aplicativos QT3 não podem lidar com eles - mostram dois quadrados vazios em vez de um símbolo.
• O Python codifica esses caracteres incorretamente quando usado diretamente u'X'!=unicode('X','utf-16')em algumas plataformas quando o caractere X está fora do BMP.
• O unicodedata do Python 2.5 falha ao obter propriedades desses caracteres quando o python é compilado com seqüências de caracteres Unicode UTF-16.
• O StackOverflow parece remover esses caracteres do texto se editado diretamente como caracteres Unicode (esses caracteres são mostrados usando escapes Unicode HTML).
• O WinForms TextBox pode gerar uma seqüência de caracteres inválida quando limitada ao MaxLength.

Parece que esses erros são extremamente fáceis de encontrar em muitos aplicativos que usam UTF-16.

Então ... Você acha que o UTF-16 deve ser considerado prejudicial?

Esta é uma resposta antiga.
Consulte UTF-8 em todos os lugares para obter as atualizações mais recentes.

Opinião: Sim, o UTF-16 deve ser considerado prejudicial . A razão pela qual existe é que, há algum tempo, costumava haver uma crença equivocada de que o widechar seria o que o UCS-4 agora é.

Apesar do "anglocentrismo" do UTF-8, ele deve ser considerado a única codificação útil para o texto. Pode-se argumentar que nunca deveriam existir códigos-fonte de programas, páginas da Web e arquivos XML, nomes de arquivos do SO e outras interfaces de texto de computador para computador. Mas quando o fazem, o texto não é apenas para leitores humanos.

Por outro lado, a sobrecarga UTF-8 é um preço baixo a ser pago, enquanto apresenta vantagens significativas. Vantagens como compatibilidade com código inconsciente que apenas passa strings com char*. Isso é ótimo. Existem poucos caracteres úteis que são MAIS CURTOS no UTF-16 do que no UTF-8.

Acredito que todas as outras codificações acabarão morrendo. Isso envolve que o MS-Windows, Java, ICU, python parem de usá-lo como favorito. Após longas pesquisas e discussões, as convenções de desenvolvimento da minha empresa proíbem o uso de UTF-16 em qualquer lugar, exceto nas chamadas da API do SO, e isso apesar da importância do desempenho em nossos aplicativos e do fato de usarmos o Windows. As funções de conversão foram desenvolvidas para converter UTF8s sempre assumidos em std::stringUTF-16 nativo, que o próprio Windows não suporta adequadamente .

Para as pessoas que dizem " usam o que é necessário onde é necessário ", digo: há uma enorme vantagem em usar a mesma codificação em todos os lugares e não vejo razão suficiente para fazer o contrário. Em particular, acho que adicionar wchar_tao C ++ foi um erro, assim como as adições Unicode ao C ++ 0x. O que deve ser exigido de implementações STL, porém, é que cada std::stringou char*parâmetro seria considerado unicode compatível.

Também sou contra a abordagem " use o que você quer ". Não vejo razão para tanta liberdade. Há confusão suficiente no assunto do texto, resultando em todo esse software danificado. Dito isto, estou convencido de que os programadores devem finalmente chegar a um consenso sobre o UTF-8 como uma maneira adequada. (Eu venho de um país que não fala ascii e cresci no Windows, então seria esperado que eu atacasse o UTF-16 com base em motivos religiosos).

Gostaria de compartilhar mais informações sobre como faço para escrever texto no Windows e o que recomendo a todos os demais para correção de unicode verificada em tempo de compilação, facilidade de uso e melhor plataforma do código. A sugestão difere substancialmente do que geralmente é recomendado como a maneira correta de usar o Unicode no Windows. No entanto, a pesquisa aprofundada dessas recomendações resultou na mesma conclusão. Então aqui vai:

• Não use wchar_tou std::wstringem qualquer lugar que não seja o ponto adjacente às APIs que aceitam UTF-16.
• Não use _T("")ou L""literais UTF-16 (estes devem ser retirados do padrão da IMO, como parte da reprovação de UTF-16).
• Não use tipos, funções ou seus derivados sensíveis à _UNICODEconstante, como LPTSTRou CreateWindow().
• No entanto, _UNICODEsempre definido, para evitar que as char*strings para o WinAPI sejam silenciosamente compiladas
• std::stringse char*em qualquer lugar do programa são considerados UTF-8 (se não dito o contrário)
• Todas as minhas strings são std::string, embora você possa passar char * ou literal para convert(const std::string &).

• use apenas funções Win32 que aceitam widechars ( LPWSTR). Nunca aqueles que aceitam LPTSTRou LPSTR. Passe os parâmetros desta maneira:

  ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())
  

  (A política usa as funções de conversão abaixo.)

• Com seqüências de caracteres MFC:

  CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:
  
  std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
  AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);
  

• Trabalhando com arquivos, nomes de arquivos e fstream no Windows:

  • Nunca passe std::stringou const char*argumentos nome do arquivo para fstreama família. O MSVC STL não suporta argumentos UTF-8, mas possui uma extensão não padrão que deve ser usada da seguinte maneira:

  • Converta std::stringargumentos para std::wstringcom Utils::Convert:

    std::ifstream ifs(Utils::Convert("hello"),
                      std::ios_base::in |
                      std::ios_base::binary);
    

    Teremos que remover manualmente a conversão, quando a atitude da MSVC fstreammudar.

  • Este código não é multiplataforma e pode ter que ser alterado manualmente no futuro
  • Consulte o fstreamcaso de pesquisa / discussão unicode 4215 para obter mais informações.
  • Nunca produza arquivos de saída de texto com conteúdo não UTF8
  • Evite usar fopen()por razões RAII / OOD. Se necessário, use as _wfopen()convenções e WinAPI acima.

// For interface to win32 API functions
std::string convert(const std::wstring& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

std::wstring convert(const std::string& str, unsigned int codePage /*= CP_UTF8*/)
{
    // Ask me for implementation..
    ...
}

// Interface to MFC
std::string convert(const CString &mfcString)
{
#ifdef UNICODE
    return Utils::convert(std::wstring(mfcString.GetString()));
#else
    return mfcString.GetString();   // This branch is deprecated.
#endif
}

CString convert(const std::string &s)
{
#ifdef UNICODE
    return CString(Utils::convert(s).c_str());
#else
    Exceptions::Assert(false, "Unicode policy violation. See W569"); // This branch is deprecated as it does not support unicode
    return s.c_str();   
#endif
}

Pontos de código Unicode não são caracteres! Às vezes, eles nem são glifos (formas visuais).

Alguns exemplos:

• Pontos de código de algarismos romanos como "ⅲ". (Um único caractere que se parece com "iii".)
• Caracteres acentuados como "á", que podem ser representados como um único caractere combinado "\ u00e1" ou um caractere e diacrítico separado "\ u0061 \ u0301".
• Caracteres como sigma minúsculo grego, que têm formas diferentes para as posições do meio ("σ") e final ("ς") das palavras, mas que devem ser consideradas sinônimos para pesquisa.
• Hífen discricionário Unicode U + 00AD, que pode ou não ser exibido visualmente, dependendo do contexto, e que é ignorado na pesquisa semântica.

As únicas maneiras de acertar a edição Unicode é usar uma biblioteca escrita por um especialista ou tornar-se um especialista e escrever você mesmo. Se você está apenas contando pontos de código, está vivendo em um estado de pecado.

Existe uma regra simples sobre qual UTF (Unicode Transformation Form) usar: - utf-8 para armazenamento e comunicação - utf-16 para processamento de dados - você pode usar o utf-32 se a maior parte da API da plataforma usada for utf-32 (comum no mundo UNIX).

Atualmente, a maioria dos sistemas usa utf-16 (Windows, Mac OS, Java, .NET, ICU, Qt). Consulte também este documento: http://unicode.org/notes/tn12/

De volta a "UTF-16 como prejudicial", eu diria: definitivamente não.

As pessoas que têm medo de substitutos (pensando que transformam Unicode em uma codificação de comprimento variável) não entendem as outras complexidades (muito maiores) que tornam o mapeamento entre caracteres e um ponto de código Unicode muito complexo: combinando caracteres, ligaduras, seletores de variação , caracteres de controle etc.

Basta ler esta série aqui http://www.siao2.com/2009/06/29/9800913.aspx e ver como o UTF-16 se torna um problema fácil.

Sim absolutamente.

Por quê? Tem a ver com o exercício do código .

Se você olhar essas estatísticas de uso de ponto de código em um corpus grande de Tom Christiansen, verá que os pontos de código BMP trans-8 bits são usados ​​em várias ordens, se a magnitude for maior que os pontos de código não BMP:

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

Pegue o ditado TDD: "Código não testado é código quebrado" e reformule-o como "código não exercido é código quebrado" e pense na frequência com que os programadores precisam lidar com pontos de código não-BMP.

Erros relacionados ao não lidar com o UTF-16 como uma codificação de largura variável têm muito mais chances de passar despercebidos do que os erros equivalentes no UTF-8 . Algumas linguagens de programação ainda não garantem fornecer UTF-16 em vez de UCS-2, e algumas chamadas linguagens de programação de alto nível oferecem acesso a unidades de código em vez de pontos de código (mesmo C deve fornecer acesso a pontos de código se você usar wchar_t, independentemente do que algumas plataformas possam fazer).

Eu sugeriria que pensar que o UTF-16 pode ser considerado prejudicial diz que você precisa entender melhor o unicode .

Desde que fui votado por apresentar minha opinião sobre uma questão subjetiva, deixe-me elaborar. O que exatamente incomoda você sobre o UTF-16? Você prefere se tudo foi codificado em UTF-8? UTF-7? Ou o UCS-4? Certamente, alguns aplicativos não são projetados para lidar com códigos de caracteres únicos, mas são necessários, especialmente no atual domínio da informação global de hoje, para a comunicação entre fronteiras internacionais.

Mas, realmente, se você acha que o UTF-16 deve ser considerado prejudicial, porque é confuso ou pode ser implementado de maneira inadequada (o unicode certamente pode ser), que método de codificação de caracteres seria considerado não prejudicial?

EDIT: Para esclarecer: Por que considerar implementações impróprias de um padrão um reflexo da qualidade do próprio padrão? Como outros observaram posteriormente, apenas porque um aplicativo usa uma ferramenta de forma inadequada, não significa que a própria ferramenta esteja com defeito. Se fosse esse o caso, provavelmente poderíamos dizer coisas como "palavra-chave var considerada prejudicial" ou "threading considerado prejudicial". Penso que a questão confunde a qualidade e a natureza do padrão com as dificuldades que muitos programadores têm para implementá-lo e usá-lo adequadamente, o que eu acho que decorre mais da falta de compreensão de como o unicode funciona, em vez do próprio unicode.

Não há nada errado com a codificação Utf-16. Mas os idiomas que tratam as unidades de 16 bits como caracteres provavelmente devem ser considerados mal projetados. Ter um tipo chamado ' char' que nem sempre representa um caractere é bastante confuso. Como a maioria dos desenvolvedores espera que um tipo de caractere represente um ponto ou caractere de código, muito código provavelmente será quebrado quando exposto a caracteres além do BMP.

Observe, no entanto, que mesmo usando utf-32 não significa que cada ponto de código de 32 bits sempre representará um caractere. Devido à combinação de caracteres, um caractere real pode consistir em vários pontos de código. Unicode nunca é trivial.

Entre. Provavelmente existe a mesma classe de bugs com plataformas e aplicativos que esperam que os caracteres sejam de 8 bits, alimentados com Utf-8.

Minha escolha pessoal é sempre usar UTF-8. É o padrão no Linux para quase tudo. É compatível com muitos aplicativos herdados. Há uma sobrecarga muito mínima em termos de espaço extra usado para caracteres não latinos versus os outros formatos UTF, e há uma economia significativa de espaço para caracteres latinos. Na web, as línguas latinas reinam supremas, e acho que elas serão no futuro próximo. E para abordar um dos principais argumentos do post original: quase todo programador sabe que o UTF-8 às vezes terá caracteres de vários bytes. Nem todo mundo lida com isso corretamente, mas geralmente está ciente, o que é mais do que pode ser dito para o UTF-16. Mas, é claro, você precisa escolher o mais apropriado para sua aplicação. É por isso que há mais de um em primeiro lugar.

Bem, há uma codificação que usa símbolos de tamanho fixo. Eu certamente quero dizer UTF-32. Mas 4 bytes para cada símbolo são muito espaço desperdiçado, por que usá-lo em situações cotidianas?

Na minha opinião, a maioria dos problemas surge do fato de que alguns softwares ficaram atrás do padrão Unicode, mas não foram rápidos em corrigir a situação. Opera, Windows, Python, Qt - todos eles apareceram antes do UTF-16 se tornar amplamente conhecido ou até mesmo existir. Posso confirmar, porém, que no Opera, Windows Explorer e Bloco de Notas não há mais problemas com caracteres fora do BMP (pelo menos no meu PC). De qualquer forma, se os programas não reconhecem pares substitutos, eles não usam o UTF-16. Quaisquer que sejam os problemas que surgem ao lidar com esses programas, eles não têm nada a ver com o próprio UTF-16.

No entanto, acho que os problemas do software legado com apenas suporte a BMP são um pouco exagerados. Caracteres fora do BMP são encontrados apenas em casos e áreas muito específicos. De acordo com o FAQ oficial do Unicode , "mesmo no texto do leste asiático, a incidência de pares substitutos deve ser bem inferior a 1% de todo o armazenamento de texto em média". Obviamente, caracteres fora do BMP não devem ser negligenciados porque um programa não é compatível com Unicode, mas a maioria dos programas não se destina a trabalhar com textos que contenham esses caracteres. É por isso que se eles não o apóiam, é desagradável, mas não uma catástrofe.

Agora vamos considerar a alternativa. Se o UTF-16 não existisse, não teríamos uma codificação adequada para texto não ASCII, e todo o software criado para o UCS-2 teria que ser completamente reprojetado para permanecer compatível com Unicode. O último provavelmente retardaria apenas a adoção do Unicode. Também não teríamos sido capazes de manter a compabilidade com o texto no UCS-2 como o UTF-8 em relação ao ASCII.

Agora, deixando de lado todos os problemas herdados, quais são os argumentos contra a própria codificação? Eu realmente duvido que os desenvolvedores hoje em dia não saibam que o UTF-16 é de tamanho variável, está escrito em todos os lugares que estão na Wikipedia. O UTF-16 é muito menos difícil de analisar do que o UTF-8, se alguém apontar a complexidade como um possível problema. Também é errado pensar que é fácil atrapalhar a determinação do comprimento da string apenas no UTF-16. Se você usa UTF-8 ou UTF-32, ainda deve estar ciente de que um ponto de código Unicode não significa necessariamente um caractere. Fora isso, não acho que exista algo substancial contra a codificação.

Portanto, não acho que a codificação em si deva ser considerada prejudicial. O UTF-16 é um compromisso entre simplicidade e compacidade, e não há mal algum em usar o que é necessário onde for necessário . Em alguns casos, você precisa permanecer compatível com ASCII e precisa de UTF-8; em alguns casos, deseja trabalhar com ideogramas Han e economizar espaço usando UTF-16; em alguns casos, você precisa de representações universais de caracteres codificação de comprimento. Use o que é mais apropriado, apenas faça-o corretamente.

Anos de trabalho de internacionalização do Windows, especialmente em idiomas do Leste Asiático, podem ter me corrompido, mas eu me inclino para o UTF-16 para representações de strings internas ao programa e UTF-8 para armazenamento em rede ou arquivo de documentos semelhantes a texto sem formatação. No entanto, o UTF-16 geralmente pode ser processado mais rapidamente no Windows, então esse é o principal benefício do uso do UTF-16 no Windows.

Dar o salto para o UTF-16 melhorou drasticamente a adequação de produtos médios que manipulam textos internacionais. Existem apenas alguns casos estreitos em que os pares substitutos precisam ser considerados (exclusões, inserções e quebra de linha, basicamente) e o caso médio é geralmente uma passagem direta. E, diferentemente das codificações anteriores, como as variantes JIS, o UTF-16 limita os pares substitutos a uma faixa muito estreita; portanto, a verificação é realmente rápida e funciona para frente e para trás.

É verdade que também é rápido no UTF-8 codificado corretamente. Mas também existem muitos aplicativos UTF-8 quebrados que codificam incorretamente pares substitutos como duas sequências UTF-8. Portanto, o UTF-8 também não garante a salvação.

O IE lida com pares substitutos razoavelmente bem desde 2000, mais ou menos, mesmo que normalmente os esteja convertendo de páginas UTF-8 para uma representação interna UTF-16; Tenho certeza de que o Firefox também acertou, então não me importo com o que o Opera faz.

O UTF-32 (também conhecido como UCS4) é inútil para a maioria dos aplicativos, pois exige muito espaço, portanto é praticamente um iniciador.

O UTF-8 é definitivamente o caminho a seguir, possivelmente acompanhado pelo UTF-32 para uso interno em algoritmos que precisam de acesso aleatório de alto desempenho (mas que ignora a combinação de caracteres).

Tanto o UTF-16 quanto o UTF-32 (assim como suas variantes LE / BE) sofrem de problemas de resistência, portanto nunca devem ser usados ​​externamente.

UTF-16? definitivamente prejudicial. Apenas meu grão de sal aqui, mas existem exatamente três codificações aceitáveis ​​para texto em um programa:

• ASCII: ao lidar com coisas de baixo nível (por exemplo: microcontroladores) que não podem pagar algo melhor
• UTF8: armazenamento em mídia de largura fixa, como arquivos

• pontos de código inteiro ("CP"?): uma matriz dos maiores números inteiros que são convenientes para a sua linguagem e plataforma de programação (decai para ASCII no limite de baixas reservas). Deve ser int32 em computadores mais antigos e int64 em qualquer coisa com endereçamento de 64 bits.

• Obviamente, as interfaces para o código herdado usam a codificação necessária para que o código antigo funcione corretamente.

O Unicode define pontos de código de até 0x10FFFF (1.114.112 códigos); todos os aplicativos em execução em ambiente multilíngue que lidam com cadeias / nomes de arquivos etc. devem lidar com isso corretamente.

Utf-16 : abrange apenas 1.112.064 códigos. Embora os que estão no final do Unicode sejam dos planos 15 a 16 (Área de uso particular). Não pode crescer mais no futuro, exceto quebrar o conceito Utf-16 .

Utf-8 : abrange, teoricamente, 2.216.757.376 códigos. O intervalo atual de códigos Unicode pode ser representado por uma sequência máxima de 4 bytes. Não sofre com problema de ordem de bytes , é "compatível" com ascii.

Utf-32 : cobre teoricamente 2 ^ 32 = 4,294,967,296 códigos. Atualmente, ele não é codificado em tamanho variável e provavelmente não será no futuro.

Esses fatos são auto-explicativos. Eu não entendo advogar o uso geral do Utf-16 . É de comprimento variável codificado (não pode ser acessado por índice), tem problemas para cobrir todo o intervalo Unicode , mesmo no momento, a ordem dos bytes deve ser tratada, etc. Não vejo nenhuma vantagem, exceto que é usado nativamente no Windows e em alguns outros lugares. Mesmo que ao escrever código multiplataforma seja provavelmente melhor usar o Utf-8 nativamente e fazer conversões apenas nos pontos finais de maneira dependente da plataforma (como já sugerido). Quando o acesso direto pelo índice é necessário e a memória não é um problema, o Utf-32 deve ser usado.

O principal problema é que muitos programadores que lidam com o Windows Unicode = Utf-16 nem sabem ou ignoram o fato de que ele é codificado em tamanho variável.

O modo como geralmente está na plataforma * nix é muito bom, c strings (char *) interpretadas como codificadas por Utf-8 , c strings amplas (wchar_t *) interpretadas como Utf-32 .

Adicione isso à lista:

O cenário apresentado é simples (ainda mais simples, como o apresentarei aqui do que era originalmente!): 1. Um WinForms TextBox fica em um Formulário vazio. Tem um MaxLength definido como 20 .

2.O usuário digita no TextBox ou cola o texto nele.

3.Não importa o que você digite ou cole no TextBox, você está limitado a 20, embora simpaticamente apite em textos além dos 20 (YMMV aqui; alterei meu esquema de som para me dar esse efeito!).

4.O pequeno pacote de texto é enviado para outro lugar, para iniciar uma emocionante aventura.

Agora esse é um cenário fácil, e qualquer pessoa pode escrever isso em seu tempo livre. Eu mesmo escrevi em várias linguagens de programação usando o WinForms, porque estava entediado e nunca tinha tentado antes. E com texto em vários idiomas reais, porque eu sou conectado dessa maneira e tenho mais layouts de teclado do que qualquer um em todo o universo.

Eu até nomeei o formulário Magic Carpet Ride , para ajudar a melhorar o tédio.

Isso não funcionou, pelo que vale a pena.

Em vez disso, inseri os 20 caracteres a seguir no meu formulário Magic Carpet Ride :

0123401234012340123 𠀀

Ah, oh.

Esse último caractere é U + 20000, o primeiro ideograma de extensão B do Unicode (também conhecido como U + d840 U + dc00, para seus amigos íntimos que ele não tem vergonha de se despir, por assim dizer, na frente de ...).

E agora temos um jogo de bola.

Porque quando TextBox.MaxLength fala sobre

Obtém ou define o número máximo de caracteres que podem ser inseridos manualmente na caixa de texto.

o que realmente significa é

Obtém ou define o número máximo de unidades de código UTF-16 LE que podem ser inseridas manualmente na caixa de texto e truncará impiedosamente a porcaria viva de qualquer string que tente jogar jogos engraçados com a noção de caractere linguístico de que apenas alguém tão obcecado quanto que o colega da Kaplan vai achar ofensivo (caramba, ele precisa sair mais!).

Vou tentar ver como atualizar o documento ....
Os leitores regulares que se lembrarem da minha série UCS-2 a UTF-16 notarão minha tristeza com a noção simplista de TextBox.MaxLength e como ele deve lidar no mínimo neste caso onde seu comportamento draconiano cria uma sequência ilegal, que outras partes do .Net Framework podem gerar

• System.Text.EncoderFallbackException: não foi possível converter o caractere Unicode \ uD850 no índice 0 para a página de código especificada. *

exceção se você passar essa string em outro lugar no .Net Framework (como estava fazendo meu colega Dan Thompson).

Agora tudo bem, talvez a série completa UCS-2 a UTF-16 esteja fora do alcance de muitos.
Mas não é razoável esperar que o TextBox.Text não produza um System.Stringque não fará com que outra parte do .Net Framework seja lançada? Quero dizer, não é como se houvesse uma chance na forma de algum evento no controle que informa sobre o próximo truncamento, onde você pode facilmente adicionar a validação mais inteligente - validação que o próprio controle não se importa de fazer. Eu chegaria ao ponto de dizer que esse controle punk está quebrando um contrato de segurança que pode levar a problemas de segurança, se você puder causar exceções inesperadas para encerrar um aplicativo como uma espécie de negação de serviço. Por que qualquer processo, método, algoritmo ou técnica do WinForms produz resultados inválidos?

Fonte: Michael S. Kaplan Blog do MSDN

Eu não diria necessariamente que o UTF-16 é prejudicial. Não é elegante, mas serve para fins de compatibilidade com o UCS-2, assim como o GB18030 com o GB2312 e o UTF-8 com o ASCII.

Mas fazer uma mudança fundamental na estrutura do Unicode no meio do caminho, depois que a Microsoft e a Sun criaram enormes APIs em torno de caracteres de 16 bits, foi prejudicial. O fracasso em divulgar a mudança foi mais prejudicial.

O UTF-16 é o melhor compromisso entre manipulação e espaço e é por isso que a maioria das principais plataformas (Win32, Java, .NET) o utilizam para representação interna de strings.

Eu nunca entendi o objetivo do UTF-16. Se você deseja uma representação com maior eficiência de espaço, use UTF-8. Se você deseja tratar o texto como tamanho fixo, use UTF-32. Se você não quiser, use UTF-16. Pior ainda, como todos os caracteres comuns (plano multilíngue básico) do UTF-16 se encaixam em um único ponto de código, os bugs que assumem que o UTF-16 tem tamanho fixo serão sutis e difíceis de encontrar, enquanto que se você tentar fazer isso isso com UTF-8, seu código falhará rápido e alto assim que você tentar internacionalizar.

_{Como ainda não posso comentar, posto isso como resposta, pois parece que não posso entrar em contato com os autores de utf8everywhere.org. É uma pena que eu não receba automaticamente o privilégio de comentar, pois tenho reputação suficiente em outras alterações de pilha.}

Isso significa um comentário para a Opinião: Sim, o UTF-16 deve ser considerado uma resposta prejudicial .

Uma pequena correção:

Para impedir que alguém passe acidentalmente um UTF-8 char*para versões de string ANSI das funções da API do Windows, deve-se definir UNICODE, não _UNICODE. _UNICODEmapeia funções como _tcslenpara wcslen, e não MessageBoxpara MessageBoxW. Em vez disso, o UNICODEdefine cuida do último. Para prova, isso é do WinUser.hcabeçalho do MS Visual Studio 2005 :

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

No mínimo, esse erro deve ser corrigido utf8everywhere.org.

Uma sugestão:

Talvez o guia deva conter um exemplo de uso explícito da versão de cadeia ampla de uma estrutura de dados, para tornar menos fácil perder / esquecer. O uso de versões de cadeia ampla de estruturas de dados, além de usar versões de funções de cadeia ampla, torna ainda menos provável que alguém acidentalmente chame uma versão de cadeia de caracteres ANSI dessa função.

Exemplo do exemplo:

WIN32_FIND_DATAW data; // Note the W at the end.
HANDLE hSearch = FindFirstFileW(widen("*.txt").c_str(), &data);
if (hSearch != INVALID_HANDLE_VALUE)
{
    FindClose(hSearch);
    MessageBoxW(nullptr, data.cFileName, nullptr, MB_OK);
}

Alguém disse que UCS4 e UTF-32 eram os mesmos. Não, mas eu sei o que você quer dizer. Um deles é uma codificação do outro, no entanto. Eu gostaria que eles pensassem em especificar endianness desde o primeiro, para que não tivéssemos a batalha de endianess aqui também. Eles não poderiam ter visto isso chegando? Pelo menos UTF-8 é o mesmo em todos os lugares (a menos que alguém esteja seguindo a especificação original com 6 bytes).

Se você usa UTF-16 , deve incluir a manipulação de caracteres multibyte. Você não pode ir para o enésimo caractere indexando 2N em uma matriz de bytes. Você precisa caminhar ou ter índices de caracteres. Caso contrário, você escreveu um bug.

O rascunho atual do C ++ diz que o UTF-32 e o UTF-16 podem ter variantes little-endian, big-endian e não especificadas. Realmente? Se o Unicode tivesse especificado que todo mundo tinha que fazer little-endian desde o começo, tudo seria mais simples. (Eu também ficaria bem com o big endian.) Em vez disso, algumas pessoas o implementaram de uma maneira, outras da outra, e agora estamos presos à tolice por nada. Às vezes, é embaraçoso ser um engenheiro de software.

Não acho que seja prejudicial se o desenvolvedor for cuidadoso o suficiente.
E eles devem aceitar essa troca se souberem bem também.

Como desenvolvedor de software japonês, acho que o UCS-2 é grande o suficiente e a limitação do espaço aparentemente simplifica a lógica e reduz a memória de tempo de execução; portanto, usar utf-16 sob a limitação do UCS-2 é bom o suficiente.

Há um sistema de arquivos ou outro aplicativo que assume que os pontos de código e bytes sejam proporcionais, para garantir que o número bruto do ponto de código seja adequado para algum armazenamento de tamanho fixo.

Um exemplo é NTFS e VFAT especificando UCS-2 como sua codificação de armazenamento de nome de arquivo.

Se esse exemplo realmente quiser se estender para oferecer suporte ao UCS-4, eu poderia concordar em usar o utf-8 para tudo, mas o comprimento fixo tem bons pontos, como:

1. pode garantir o tamanho pelo comprimento (tamanho dos dados e comprimento do ponto de código é proporcional)
2. pode usar o número de codificação para pesquisa de hash
3. dados não compactados são de tamanho razoável (em comparação com utf-32 / UCS-4)

No futuro, quando a capacidade de memória / processamento for barata, mesmo em qualquer dispositivo incorporado, podemos aceitar que o dispositivo seja um pouco lento por falhas extras de cache ou falhas de página e uso de memória adicional, mas isso não acontecerá no futuro próximo, eu acho ...

"Uma das codificações mais populares, a UTF-16, deve ser considerada prejudicial?"

Possivelmente, mas as alternativas não devem necessariamente ser vistas como muito melhores.

A questão fundamental é que existem muitos conceitos diferentes sobre: ​​glifos, caracteres, pontos de código e seqüências de bytes. O mapeamento entre cada um deles não é trivial, mesmo com o auxílio de uma biblioteca de normalização. (Por exemplo, alguns caracteres em idiomas europeus que são escritos com um script baseado em latim não são escritos com um único ponto de código Unicode. E isso é no final mais simples da complexidade!) O que isso significa é que, para corrigir tudo, é surpreendentemente surpreendente. difícil; erros bizarros são esperados (e, em vez de apenas reclamar aqui, informe aos mantenedores do software em questão).

A única maneira pela qual o UTF-16 pode ser considerado prejudicial, por oposição ao UTF-8, é que ele possui uma maneira diferente de codificar pontos de código fora do BMP (como um par de substitutos). Se o código deseja acessar ou iterar por ponto de código, isso significa que ele precisa estar ciente da diferença. OTOH, isso significa que um corpo substancial de código existente que assume "caracteres" sempre pode ser ajustado em uma quantidade de dois bytes - uma suposição bastante comum, se incorreta - pode pelo menos continuar trabalhando sem reconstruir tudo. Em outras palavras, pelo menos você consegue ver os personagens que não estão sendo tratados corretamente!

Eu viraria sua pergunta de cabeça para baixo e diria que toda a maldição do Unicode deveria ser considerada prejudicial e todos deveriam usar uma codificação de 8 bits, exceto que eu vi (nos últimos 20 anos) onde isso leva: horrível confusão sobre as várias codificações ISO 8859, além de todo o conjunto de codificações usadas para cirílico e o conjunto EBCDIC e ... bem, o Unicode por todas as suas falhas supera isso. Se ao menos não fosse um compromisso tão desagradável entre os mal-entendidos de diferentes países.