Porque o MS SQL Server tem um suporte ruim para o UTF-8 em comparação com outros RDBMS.
O MS SQL Server segue a convenção, usada no próprio Windows, de que seqüências de caracteres "estreitas" ( char
em C ++ CHAR
ou VARCHAR
SQL) são codificadas em uma "página de códigos" herdada. O problema com as páginas de código é que eles têm um número limitado de caracteres (a maioria é codificação de byte único, o que limita o porto a 256 caracteres) e são projetados em um único idioma (ou grupo de idiomas com alfabetos semelhantes). Isso dificulta o armazenamento de dados multilíngues. Por exemplo, você não pode armazenar dados em russo e hebraico porque o russo usa a página de códigos 1251 e o hebraico usa a página de códigos 1255 .
O Unicode resolve esse problema usando um único conjunto de caracteres codificados gigantes com espaço para mais de um milhão de caracteres, o suficiente para representar todos os idiomas do mundo. Existem vários esquemas de codificação Unicode; A Microsoft prefere usar UTF-16 , por razões históricas . Como o UTF-16 representa cadeias de caracteres como uma sequência de unidades de código de 16 bits em vez dos tradicionais de 8 bits, é necessário um tipo de caractere separado. No MSVC ++, é isso wchar_t
. E no MS SQL, é NCHAR
ou NVARCHAR
. A N
expressão "nacional" , que me parece inversa, porque o Unicode é sobre inter- nacionalização, mas essa é a terminologia ISO.
Outras implementações SQL permitem armazenar texto UTF-8 em uma VARCHAR
coluna. UTF-8 é uma codificação de comprimento variável (1-4 bytes por caractere) otimizada para os casos em que seus dados estão principalmente no intervalo Latim básico (que são representados como o mesmo 1 byte por caractere que ASCII), mas podem representar qualquer caractere Unicode. Assim, você evitaria o problema "duas vezes mais espaço" mencionado por bwalk2895.
Infelizmente, o MS SQL Server não oferece suporte a UTF-8VARCHAR
; portanto, você deve usar UTF-16 (e desperdiçar espaço para texto ASCII), usar uma página de código que não seja Unicode (e perder a capacidade de representar caracteres estrangeiros), ou armazene UTF-8 em uma BINARY
coluna (e lide com inconvenientes, como as funções de cadeia de caracteres SQL que não estão funcionando corretamente ou com a exibição dos dados como um dump hexadecimal no gerenciador de banco de dados da GUI).