SQL Server 2005/2008 UTF-8 Intercalación / Conjunto de caracteres

No puedo encontrar las opciones directamente para establecer UTF-8 relación Collations/Charsetsen SQL Server 2005/2008, lo mismo que es posible establecer en otros motores SQL, pero en SQL Server 2005/2008 solo hay intercalaciones latinas y SQL.

¿Existe alguna opción para forzar / instalar estas intercalaciones / conjuntos de caracteres en el motor de SQL Server (para ambas versiones) 2005/2008 en el sistema operativo Win2008

No, no hay SQL Server no es compatible con UTF-8.

Debe definir sus columnas como nvarchar / nchar si desea datos unicode. Tenga en cuenta que internamente SQL Server almacena esto como UCS-2.

Tenga en cuenta que esto se ha solicitado a MS en Connect y hay un artículo de KB más antiguo . Y algo de información en este blog también

No puede instalar UTF-8 como un conjunto de caracteres porque no es un conjunto de caracteres, es una codificación.

Si desea almacenar texto Unicode, use el nvarchar tipo de datos.

Si desea almacenar texto codificado con UTF-8, lo almacena como datos binarios ( varbinary).

A partir de SQL Server 2019 (actualmente en versión beta / "Community Tech Preview"), hay soporte nativo para UTF-8 a través de una nueva serie de colaciones UTF-8. SIN EMBARGO, tener la capacidad de usar UTF-8 no significa que debas hacerlo. Existen inconvenientes definitivos para usar UTF-8, tales como:

1. Solo los primeros 128 puntos de código son de 1 byte (es decir, el conjunto ASCII estándar de 7 bits)
2. Los siguientes casi 2000 puntos de código son de 2 bytes, por lo tanto, no hay ahorro de espacio con UTF-16 NVARCHAR
3. Los restantes 63k puntos de código en el BMP (es decir, el rango U + 0800 - U + FFFF) son todos 3 bytes, por lo tanto, 1 byte más grande que el mismo carácter en UTF-16 /NVARCHAR .
4. Solo dígalo: los caracteres suplementarios son de 4 bytes en ambas codificaciones, por lo que no hay diferencia de espacio allí
5. Si bien es posible que ahorre espacio con UTF-8, existe una gran probabilidad de que tenga un impacto en el rendimiento al hacerlo.

Lo que realmente se reduce a esto es: UTF-8 es un diseño de formato de almacenamiento para permitir que los sistemas de 8 bits (que generalmente se diseñaron alrededor de ASCII y ASCII Extended - Páginas de códigos) utilicen Unicode sin romper nada ni requerir ninguna modificación de los existentes. archivos para mantener las cosas funcionando. UTF-8 es maravilloso para sistemas de archivos y redes, pero los datos almacenados dentro de SQL Server tampoco lo son. El hecho de que los datos que se encuentran mayormente (o completamente) dentro del rango ASCII estándar requiere menos espacio que los mismos datos cuando se almacenan como UTF-16 / NVARCHARes un efecto secundario. Claro, es un efecto secundario que puede resultar útil, pero esa decisión debe ser tomada por alguien que entienda tanto los datos como las consecuencias / inconvenientes de esta decisión. Esto esNo es una característica de uso general.

Además, el caso de uso principal para UTF-8 (en SQL Server) es para el código de la aplicación que ya usa UTF-8, posiblemente ya con otro RDBMS que lo admita, y no existe el deseo o la capacidad de actualizar el código de la aplicación / esquema de DB para usar NVARCHARtipos de datos (para tablas, variables, parámetros, etc.) o para prefijar literales de cadena con una "N" mayúscula. El objetivo es el mismo que el motivo de la existencia de UTF-8: habilitar el código de la aplicación para usar Unicode sin cambiar la estructura general o hacer que los datos existentes no sean válidos. Si esto describe su situación, use UTF-8, pero tenga en cuenta que todavía hay algunos errores / problemas con él.

Si no tiene una necesidad explícita de que Unicode funcione sin usar NVARCHARo literales de cadena con el prefijo "N" en mayúsculas, entonces el único otro escenario donde UTF-8 es un beneficio es si tiene MUCHOS datos ASCII en su mayoría estándar que deben permitir Caracteres Unicode, y está utilizando NVARCHAR(MAX)(lo que significa que la compresión de datos no funcionará), y la tabla se actualiza con frecuencia (por lo que el Índice de almacén de columnas en clúster probablemente no va a ayudar realmente).

Para más detalles, vea mi publicación:

Soporte nativo de UTF-8 en SQL Server 2019: ¿Salvador o falso profeta?

En mi caso, tuve que mostrar caracteres árabes y mi base de datos de desarrollo fue en 2014, aquí las cosas funcionaron bien. Aquí, en la consulta pude ver caracteres en árabe y mi intercalación fue SQL_Latin1_General_CP1256_CI_AS

Pero mi producción estaba en SQL Server 2008 y, finalmente, no era compatible con el juego de caracteres UTF-8. Aquí, pude ver todo ??????????? como UTF-8 no es compatible con SQL 2008.

Lo único que hice fue cambiar todo varchar a nvarchar y pude ver árabe char correctamente. También cambio mi intercalación de base de datos de 2008 a SQL_Latin1_General_CP1256_CI_AS