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

Estamos usando o MySQL na empresa em que trabalho e criamos aplicativos internos e voltados para o cliente usando o Ruby on Rails.

Quando comecei a trabalhar aqui, tive um problema que nunca havia encontrado antes; o banco de dados no servidor de produção está definido como Latin-1, o que significa que a jóia do MySQL lança uma exceção sempre que houver entrada do usuário em que o usuário copie e cole caracteres UTF-8.

Meu chefe chama esses "caracteres ruins", pois a maioria deles são caracteres não imprimíveis e diz que precisamos removê-los. Eu encontrei algumas maneiras de fazer isso, mas eventualmente acabamos em uma circunstância em que um caractere UTF-8 era necessário. Além disso, é um pouco complicado, especialmente porque parece que a única solução que eu já li sobre esse problema é definir o banco de dados como UTF-8 (faz sentido para mim).

O único argumento que ouvi sobre o Latin-1 é que permitir caracteres UTF-8 não imprimíveis pode atrapalhar as pesquisas de texto / texto completo no MySQL. Isso é mesmo verdade?

Existem outras razões pelas quais alguém deve usar o Latin-1 em vez do UTF-8? Entendo que é superior e se torna mais onipresente.

O 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 de fato na Web, superando o ASCII, Latin-1, UCS-2 e UTF-16. Basta usar UTF-8 em qualquer lugar .

A razão mais importante pela qual você deve dar suporte ao Unicode é que você não deve fazer suposições desnecessárias sobre a entrada do usuário. Não tenho idéia de qual é o seu domínio, mas coisas como nomes de usuário hebraicos, uma postagem no blog sobre a China, um comentário com Emoji ou texto bem estilizado - como "this" - devem ser possíveis ... Ah, essas eram aspas tipograficamente corretas ( “”em vez de ""), traços inteiros e reticências, que são caracteres comuns no texto em inglês, mas não são suportados pelo ASCII ou pelo Latin-1. Portanto, não dar suporte a outros scripts não é apenas um grande problema para outras culturas, mas aderir ao Latin-1 nem permite que você escreva um inglês adequado.

A noção de que o Unicode permite apenas "caracteres inválidos" está errada. Sim, o texto é realmente complicado e o Unicode não esconde isso de você. Seu chefe pode estar pensando em caracteres compostos, onde um ponto de código base, como aé modificado por pontos de código subseqüentes que, por exemplo, representam diacríticos para formar um caractere visual, como á. Isso realmente não entra no seu caminho ao tentar fazer pesquisas 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 na forma pré-composta, se houver uma disponível. Ao pesquisar, você também pode retirar todos os caracteres de composição do texto, mas isso pode alterar substancialmente o 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 string? Que tal 0x1C, um "Separador de Arquivos"? Eu nunca vi metade disso . 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é o ASCII e o Latin-1 permitem que você quebre completamente sua entrada se você assumir que tudo é apenas texto imprimível!

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

Como sua posição não está completamente fora do almoço, apenas desatualizada, respeite sua posição ao discutir esse assunto (e você precisa se lembrar de discutir , não discuta) e tente resolver as preocupações que ele tem com relação à UTF-8. Suspeito que o problema subjacente não seja técnico e possa exigir algum nível de negociação de habilidades pessoais.

Qual de nós está certo?

Era uma vez, seu chefe era. Mas com o passar do tempo, as coisas mudam. Atualmente você é (mas antes de correr para o seu chefe, não deixe de ler a resposta de Nelson também ).

As versões antigas do MySQL, e as versões antigas de quase tudo , lidavam muito melhor com o Latin1 / ISO-8859-1 (5) mais antigo que o UTF8.

Há uma razão pela qual o UTF8 foi criado, evoluído e promovido principalmente em todos os lugares: se implementado corretamente, funciona muito melhor . Existem 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é necessário levar isso em consideração. E suas rotinas de pesquisa serão um pouco mais lentas. Eles serão capazes de fazer mais coisas (por exemplo, pesquisas com sensibilidade acento ou sem . Não pode fazer aqueles em Latin1 sem um extenso trabalho), mas vai demorar um pouco mais tempo.

Mas, por outro lado, o armazenamento é barato , a sobrecarga realista do tamanho dos arquivos é inferior a 2-3%, o poder da computação também é barato e fica mais barato de 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 para ferramentas de busca etc. se você fosse o único a desenvolver essas ferramentas. Mas você provavelmente não é. Você usa essas ferramentas; mesmo aqueles que não eram completamente compatíveis com UTF8 ontem (como os MySQLs anteriores não eram), são hoje ou serão em breve (por exemplo, MySQL com suporte a utf8mb4).

Portanto, planejando e implementando cuidadosamente o UTF8 da maneira certa ( sem pensar no Latin1 como uma reflexão tardia), você pode ter um código razoavelmente à prova de futuro , o que, se você planeja fazer negócios com qualquer país asiático, é muito bom Coisa. E se você não tiver esses planos, outras pessoas terão, e elas poderão ser seus clientes, fornecedores ou parceiros.

Portanto, quando eles começarem a enviar dados UTF8, você precisará configurar um procedimento complicado para converter para o Latin1 e lidar com casos insolúveis.

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

Algumas situações em que a restrição do conjunto de caracteres apenas para ASCII pode fazer sentido são para campos de escolha limitada, por exemplo, campos de status, porque você controla estritamente os valores que podem estar lá e chaves / referências estrangeiras ao sistema externo, porque raramente existem razões para eles têm apenas caracteres alfanuméricos e alguns símbolos.

Para outros textos, basta usar UTF-8.

Para começar com a resposta, não importa como o servidor está configurado. A codificação de caracteres no MySQL pode ser configurada por coluna (significa que a mesma tabela pode conter caracteres em várias codificações, fácil). Ou seja, meu servidor (e vários bancos de dados herdados) está configurado para cp1251 por padrão para clientes antigos que não conseguem definir o agrupamento correto na conexão (clientes de hardware diferentes), mas os principais bancos de dados em produção estão usando UTF-8.

Falando em "espaço desperdiçado" - você não pode realisticamente chamar dados importantes de lixo, pode? O aumento do espaço de armazenamento, no entanto, será diferente dependendo do idioma em que seus dados estiverem. Desde um aumento insignificante (menos de 1%) se o site estiver principalmente em inglês e até 100%, se estiver usando caracteres fora do intervalo ASCII . E ainda mais, se você se mudar para o leste. As especificações UTF-8 posteriores (chamadas UTF8mb4) permitem até 4 bytes por ponto de código.

E para "quem está certo" ... A verdade é que essa é uma questão social mais do que técnica. Pode haver razões válidas para configurações específicas do servidor, mas você deve conhecer as implicações. Mas se você me perguntar, não há razão para não usar UTF-8. É o único tipo de governar todos os textos do mundo.

Apenas explique a ele que UTF-8 é o padrão para o tráfego da web. E qualquer usuário pode inserir qualquer caractere unicode válido em seu navegador.

É muito mais fácil ter utf-8 / unicode todo o caminho, do front-end ao back-end, do que lidar com os diversos e diversos problemas resultantes do utf-8-> latin-1-> utf-8.