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

62

Estamos usando o MySQL na empresa em que trabalhamos e construímos aplicativos internos e voltados para o cliente usando o Ruby on Rails.

Quando comecei a trabalhar aqui, deparei com um problema que nunca havia encontrado antes; o banco de dados no servidor de produção é configurado para Latin-1, o que significa que o gem do MySQL lança uma exceção sempre que houver entrada do usuário onde o usuário copia & cola os caracteres UTF-8.

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

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

Existem outras razões para usar o Latin-1 em UTF-8? No meu entender, é superior e se torna mais onipresente.

    
por Ravenstine 30.01.2015 / 22:18
fonte

6 respostas

128

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!

    
por 30.01.2015 / 22:54
fonte
62

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.

    
por 31.01.2015 / 07:09
fonte
49

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 .

    
por 30.01.2015 / 22:48
fonte
4

Algumas situações em que restringir o conjunto de caracteres apenas a ASCII podem fazer sentido para campos de escolha limitada, por exemplo, campos de status, porque você controla estritamente os valores que podem estar lá, e chave estrangeira / referências ao sistema externo, porque raramente há motivos para que eles tenham algo além de caracteres alfanuméricos e alguns símbolos.

Para quaisquer outros textos, basta usar o UTF-8.

    
por 31.01.2015 / 23:23
fonte
3

Para começar com a resposta, não importa como seu 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 legados) é 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 bancos de dados principais em produção usam UTF-8.

Falando de "espaço desperdiçado" - você não pode realisticamente chamar dados importantes de um desperdício, não é? O aumento do espaço de armazenamento, no entanto, será diferente dependendo do idioma dos seus dados. De um aumento insignificante (menos de 1%) se o site for principalmente em inglês e até 100%, se for mailny usando caracteres fora da faixa ASCII . E ainda mais, se você se mover para o leste. Mais tarde, as especificações UTF-8 (chamadas de UTF8mb4) permitem até 4 bytes por ponto de código.

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

    
por 02.02.2015 / 05:20
fonte
0

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

É muito mais fácil ter o utf-8 / unicode desde o front-end até o back-end do que lidar com os vários problemas que resultam do utf-8- > latim-1- > utf-8.

    
por 03.02.2015 / 02:56
fonte