O Latin-1 deve ser usado sobre o UTF-8 quando se trata da configuração do banco de dados?

Unicode é certamente difícil, e a codificação UTF-8 possui algumas propriedades inconvenientes. No entanto, o UTF-8 se tornou a codificação padrão na web, superando o ASCII, o Latin-1, o UCS-2 e o UTF-16. Apenas use UTF-8 em qualquer lugar .

A razão mais importante pela qual você deve suportar o Unicode é que você não deve fazer suposições desnecessárias sobre a entrada do usuário. Eu não tenho idéia do seu domínio, mas coisas como nomes de usuário em hebraico, uma postagem no blog sobre a China, um comentário com Emoji ou simplesmente um texto bem estilizado - como “isso” - devem ser possíveis… Oh, essas foram aspas tipograficamente corretas “” em vez de "" ), traços em largura e reticências, que são caracteres comuns em texto em inglês, mas não suportados por ASCII ou Latin-1. Portanto, não apoiar outros scripts não é apenas um grande problema para outras culturas, mas manter o Latin-1 não permite que você escreva o inglês adequado.

A noção de que o Unicode permite apenas "caracteres ruins" está errada. Sim, o texto é realmente complicado e o Unicode não esconde isso de você. Seu chefe pode estar pensando em caracteres compostos, em que um ponto de código de base, como a , é modificado por pontos de código subsequentes, por exemplo, representam diacríticos para formar um caractere visual, como á . Isso não atrapalha ao tentar fazer buscas se você fizer algum tipo de normalização. Por exemplo, você pode armazenar todo o texto no formulário NFC, que recolhe essas composições no formulário pré-composto, se houver algum disponível. Ao fazer a pesquisa, você também pode retirar todos os caracteres de composição do texto, mas isso pode alterar substancialmente o seu significado em alguns idiomas.

O Unicode também adiciona muitos caracteres não imprimíveis - mas até o ASCII possui muitos deles. Você vai lidar com um NUL no meio de uma corda? Como cerca de 0x1C, um "File Separator"? Eu nunca vi metade deles . O Latin-1 adiciona um hífen suave que indica oportunidades de quebra de palavras, mas é invisível. Isso também interrompe sua pesquisa de texto completo? Em outras palavras, até mesmo o ASCII e o Latin-1 permitem que você quebre completamente sua entrada se você assumir que é tudo apenas um texto imprimível!

Acho que além da questão técnica, seu chefe pode não ter tempo para se manter atualizado sobre os padrões atuais.

Desde que sua posição não é completamente fora para o almoço, apenas desatualizado, respeite sua posição ao discutir este assunto (e você precisa se lembrar de discutir , não discutir), e tentar trabalhar preocupações que ele tem com relação a UTF-8. Suspeito que a questão subjacente não seja uma questão técnica e que possa exigir algum nível de negociação de soft skills.

Which of us is right?

Era uma vez seu chefe. Mas com o passar do tempo, as coisas mudam. Hoje em dia, você é (mas antes de correr para o seu chefe, certifique-se de ler a resposta de Nelson também ).

Versões antigas do MySQL, e versões antigas de principalmente tudo , lidam muito melhor com o antigo Latin1 / ISO-8859-1 (5) do que com o UTF8.

Existe uma razão pela qual o UTF8 foi criado, desenvolvido e implementado principalmente em todos os lugares: se implementado corretamente, ele funciona muito melhor . Há alguns problemas de desempenho e armazenamento decorrentes do fato de um caractere Latin1 ter 8 bits, enquanto um caractere UTF8 pode ter de 8 a 32 bits. Portanto, ao planejar VARCHAR , você precisa levar isso em consideração. E suas rotinas de pesquisa serão um pouco mais lentas. Eles poderão fazer mais coisas (por exemplo, pesquisas com sensibilidade ao sotaque ou sem . faça aqueles em latim1 sem trabalho extenso), mas eles vão demorar um pouco mais de tempo.

Mas por outro lado, o armazenamento é barato , a sobrecarga realística em tamanhos de arquivo é menor que 2-3%, o poder de computação também é barato e fica mais barato bom acordo com a Lei de Moore; enquanto seu tempo e as expectativas de seus clientes definitivamente não são .

Você pode ter que se preocupar com ferramentas de busca, etc., se foi você quem desenvolveu essas ferramentas. Mas você provavelmente não é. Você usa essas ferramentas; mesmo aqueles que não estavam completamente compatíveis com UTF8 ontem (como os primeiros MySQLs não eram), estão hoje, ou logo estarão, (por exemplo, MySQL com suporte a utf8mb4).

Portanto, planejando e implementando cuidadosamente o UTF8 da maneira correta ( não dando um tapa no Latin1 como uma reflexão tardia) você pode ter um código que seja razoavelmente à prova do futuro , , se você planeja fazer negócios com qualquer país asiático, é uma coisa muito boa. E se você não tiver tais planos, outras pessoas terão, e essas pessoas poderão ser seus clientes, fornecedores ou parceiros.

Então, quando eles começarem a enviar seus dados UTF8, você terá que configurar um thingamajig complicado para converter para o Latin1 e lidar com casos insolúveis.

Quando você considera no orçamento o custo de várias escaramuças contra os ninjas malignos mojibake , e considere que eles não vão desaparecer - como você já descobriu - então você perceberá que o UTF8 não é apenas mais simples, mas também mais barato .