Evitando a mudança de código com o Microsoft SQLServer e Unicode

Question

Como você pode fazer com que o MSSQL Server aceite dados Unicode por padrão em uma coluna VARCHAR ou NVARCHAR?

Eu sei que você pode fazer isso colocando um N na frente da string a ser colocado em campo, mas, por honesto, isso parece um pouco arcaico em 2008 e particularmente com o uso do SQL Server 2005.

Answer 1

o N Sintaxe é como você especifica uma string unicode literal no SQL Server.

N'Unicode string'
'ANSI string'

O SQL Server será convertido automaticamente entre os dois quando possível, usando o agrupamento de uma coluna ou o agrupamento do banco de dados.

Portanto, se seus literais de string não contêm caracteres unicode, você não precisa especificar o N prefixo.

Mas se seus literais de corda Faz conter caracteres unicode e depois usar o N Prefixo é necessário.

Answer 2

Se este for um aplicativo da Web, você provavelmente poderá fazer com que seu servidor da web use o UTF8, pois sua codificação padrão. Dessa forma, todos os dados para o navegador seriam UTF8, que podem ser inseridos nos campos VARCHAR. O UTF8 é uma boa maneira de criar aplicativos que não estejam cientes do Unicode lidar com isso.

Answer 3

Eles realmente precisam de uma maneira de desligar a necessidade do prefixo n ''. O argumento "é necessário para o argumento de compatibilidade com versões anteriores" faz sentido para mim - com certeza, faça esse comportamento o padrão para aplicativos antigos, mas forneça uma opção para eu ativar a unicode Strings por padrão (ou seja, não é necessário prefixo n ''). Estou descobrindo que preciso ir e mexer com grandes áreas do meu aplicativo para me adaptar ao Unicode no SQL Server quando este não é um problema no Oracle e PostgreSQL. Vamos, Microsoft!

Answer 4

Embora você possa simplesmente armazenar o conteúdo UTF8 em um campo Varchar no servidor MSSQL, desde que a tradução do Charset não seja concluída, você deve estar ciente de que:

1. Nenhuma ferramenta de gerenciamento/relatório/dados fora do seu aplicativo poderá entender seus caracteres não ingleses.

2. Manuseio específico do idioma, como classificar uma lista de nomes, não pode ser feita na ordem aceitável para cada idioma.

3. Deve ter cuidado com o truncamento de dados. Truncando um caractere UTF8 multi-bytes causa corrupção de dados para o caractere envolvido. Você sempre deve rejeitar a entrada se exceder o comprimento do campo.

4. Pode não ser tão fácil quanto você pensa desativar a tradução do charset ... mesmo que você o desative no driver do cliente, ele ainda poderá ser superestimado em alguns casos se houver uma diferença significativa de localidade entre o cliente e o RDBMS CodePage usado, o que instantaneamente leva a Corrupção de dados.

5. Se você acha que isso é tudo, você terá que se preocupar com o seu brincadeira.

Em resumo, enquanto você pode ficar tentado a seguir esse caminho, não é uma boa ideia. A alteração do código é necessária ao fazer multi-bytes.