Compatibilidad con la intercalación y Unicode

  • Artículo

Se aplica a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Punto de conexión de análisis SQL en Microsoft FabricAlmacenamiento en Microsoft Fabric

Las intercalaciones de SQL Server proporcionan propiedades de distinción entre mayúsculas y minúsculas, acentos y reglas de ordenación para los datos. Las intercalaciones que se usan con tipos de datos de caracteres, como char y varchar, dictan la página de códigos y los caracteres correspondientes que se pueden representar para ese tipo de datos.

Si va a instalar una instancia nueva de SQL Server, restaurar una copia de seguridad de la base de datos o conectar el servidor a bases de datos cliente, es importante conocer los requisitos de configuración regional, el criterio de ordenación y la distinción entre mayúsculas y minúsculas, y acentos de los datos con los que se trabaja. Para obtener una lista de las intercalaciones disponibles en la instancia de SQL Server, vea sys.fn_helpcollations (Transact-SQL).

Al seleccionar una intercalación para el servidor, base de datos, columna o expresión, se asignan ciertas características a los datos. Estas características afectan a los resultados de muchas operaciones de la base de datos. Por ejemplo, cuando se crea una consulta con ORDER BY, es posible que el criterio de ordenación del conjunto de resultados dependa de la intercalación que se aplica a la base de datos o que se dicta en una cláusula COLLATE en el nivel de expresión de la consulta.

Para hacer el mejor uso posible de la compatibilidad con la intercalación en SQL Server, se deben conocer los términos que se definen en este artículo y cómo se relacionan con las características de los datos.

Términos de intercalación

Intercalación

Una intercalación especifica los patrones de bits que representan a cada carácter de un conjunto de datos. Las intercalaciones también determinan las reglas que ordenan y comparan los datos. SQL Server permite almacenar los objetos que tienen intercalaciones diferentes en una sola base de datos. En las columnas que no sean Unicode, la configuración de intercalación especifica la página de códigos de los datos y qué caracteres se pueden representar. Los datos que se mueven entre columnas que no sean Unicode se deben convertir de la página de códigos de origen a la de destino.

Los resultados de las instrucciones de Transact-SQL pueden variar cuando se ejecutan en el contexto de bases de datos distintas que tengan una configuración de intercalación diferente. Si es posible, use una intercalación normalizada para su organización. De esta manera no tiene que especificar la intercalación en todos los caracteres o expresiones Unicode. Si debe trabajar con objetos que tienen configuraciones de intercalación y de página de códigos diferentes, conviene codificar las consultas para tener en cuenta las reglas de prioridad de intercalación. Para obtener más información, vea Prioridad de intercalación (Transact-SQL).

Las opciones asociadas con una intercalación son la distinción de mayúsculas y minúsculas, la distinción de acentos, la distinción de kana, la distinción de ancho y la distinción de selector de variación. SQL Server 2019 (15.x) presenta una opción adicional para la codificación UTF-8.

Para especificar estas opciones se anexan al nombre de la intercalación. Por ejemplo, la intercalación Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 es una intercalación con distinción entre mayúsculas y minúsculas, distinción de acentos, distinción de tipos de kana, distinción de ancho y con codificación UTF-8. Otro ejemplo: la intercalación Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS no distingue entre mayúsculas y minúsculas ni acentos, distingue los tipos de kana, el ancho, el selector de variación y usa codificación distinta de Unicode.

El comportamiento asociado a estas diversas opciones se describe en la tabla siguiente:

Opción Descripción
Distinguir mayúsculas de minúsculas (_CS) Distingue entre letras mayúsculas y minúsculas. Si se selecciona esta opción, las letras minúsculas se ordenan por delante de sus versiones en mayúsculas. Si esta opción no está seleccionada, la intercalación no distinguirá mayúsculas de minúsculas. Es decir, SQL Server considera las versiones mayúscula y minúscula de las letras como letras idénticas a efectos de ordenación. Puede seleccionar explícitamente no distinguir entre mayúsculas y minúsculas especificando _CI.
Distinguir acentos (_AS) Distingue entre caracteres acentuados y no acentuados. Por ejemplo, "a" no es igual a "ấ". Si esta opción no está seleccionada, la intercalación no distinguirá los acentos. Es decir, SQL Server considera las versiones acentuadas y no acentuadas de las letras como letras idénticas a efectos de ordenación. Puede seleccionar explícitamente no distinguir acentos especificando _AI.
Distinguir kana (_KS) Distingue entre dos tipos de caracteres kana japoneses: Hiragana y Katakana. Si esta opción no está seleccionada, la intercalación no distinguirá los caracteres kana. Es decir, SQL Server considera los caracteres Hiragana y Katakana como caracteres iguales a efectos de ordenación. La omisión de esta opción es el único método para especificar que no se distinguen los caracteres kana.
Distinguir ancho (_WS) Distingue entre caracteres de ancho total y ancho medio. Si no se selecciona esta opción, SQL Server considera que la representación de ancho completo y de ancho medio del mismo carácter son idénticas con fines de ordenación. La omisión de esta opción es el único método para especificar no distinción de ancho.
Distinguir selector de variación (_VSS) Distingue entre varios selectores de variación ideográfica en las intercalaciones del japonés Japanese_Bushu_Kakusu_140 y Japanese_XJIS_140, introducidas en SQL Server 2017 (14.x). Una secuencia de variación consta de un carácter base y de un selector de variación. Si no se selecciona esta opción _VSS, la intercalación no distinguirá el selector de variación y este no se tendrá en cuenta en la comparación. Es decir, SQL Server considera que los caracteres que se basan en el mismo carácter base con diferentes selectores de variación son idénticos con fines de ordenación. Para más información, vea Unicode Ideographic Variation Database (Base de datos de variaciones ideográficas de Unicode).

Las intercalaciones que distinguen selectores de variación (_VSS) no se admiten en los índices de búsqueda de texto completo. Los índices de búsqueda de texto completo solo admiten opciones que distinguen acentos (_AS), que distinguen kana (_KS) y que distinguen ancho (_WS). Los motores XML y CLR de SQL Server no admiten selectores de variación (_VSS).
Binario (_BIN)1 Ordena y compara datos de las tablas de SQL Server basándose en los patrones de bits definidos para cada carácter. El orden binario distingue entre mayúsculas y minúsculas, y acentos. El orden binario es también el más rápido. Para más información, vea la sección Intercalaciones binarias de este artículo.
Punto de código binario (_BIN2)1 Ordena y compara datos de las tablas de SQL Server según los puntos de código Unicode de datos Unicode. Para los datos que no son Unicode, el punto de código binario usa comparaciones idénticas a las de las ordenaciones binarias.

La ventaja de usar un criterio de ordenación de punto de código binario es que no es necesaria ninguna reordenación de los datos en aplicaciones que comparan los datos de SQL Server ordenados. Por consiguiente, el criterio de ordenación de punto de código binario proporciona un desarrollo más simple de las aplicaciones y posibles aumentos en el rendimiento. Para más información, vea la sección Intercalaciones binarias de este artículo.
UTF-8 (_UTF8) Permite que los datos con codificación UTF-8 se almacenen en SQL Server. Si no se selecciona esta opción, SQL Server usa el formato de codificación distinto de Unicode predeterminado para los tipos de datos aplicables. Para más información, vea la sección Compatibilidad con UTF-8 de este artículo.

1 Si están seleccionadas las opciones Binario o Punto de código binario, las opciones Distinguir mayúsculas de minúsculas (_CS), Distinguir acentos (_AS), Distinguir kana (_KS) y Distinguir ancho (_WS) no estarán disponibles.

Ejemplos de opciones de intercalación

Cada intercalación se combina como una serie de sufijos para definir la distinción entre mayúsculas y minúsculas, acentos, ancho o kana. En estos ejemplos se describe el comportamiento del criterio de ordenación de diversas combinaciones de sufijos.

Sufijo de intercalación de Windows Descripción del orden
_BIN1 Orden binario
_BIN21, 2 Criterio de ordenación Punto de código binario
_CI_AI2 No distingue mayúsculas de minúsculas, ni acentos, ni kana, ni ancho.
_CI_AI_KS2 No distingue mayúsculas de minúsculas, ni acentos, ni ancho pero sí distingue Kana.
_CI_AI_KS_WS2 No distingue mayúsculas de minúsculas, ni acentos, pero sí distingue Kana y ancho.
_CI_AI_WS2 No distingue mayúsculas de minúsculas, ni acentos, ni Kana pero sí distingue ancho.
_CI_AS2 No distingue mayúsculas de minúsculas, ni Kana ni ancho, pero sí acentos.
_CI_AS_KS2 No distingue mayúsculas de minúsculas, ni ancho, pero sí acentos y Kana.
_CI_AS_KS_WS2 No distingue mayúsculas de minúsculas, pero sí distingue acentos, Kana y ancho.
_CI_AS_WS2 No distingue entre mayúsculas y minúsculas, ni Kana, pero sí acentos y ancho.
_CS_AI2 Distingue mayúsculas de minúsculas, pero no distingue acentos, ni Kana, ni ancho.
_CS_AI_KS2 Distingue mayúsculas de minúsculas y Kana, pero no distingue acentos ni ancho.
_CS_AI_KS_WS2 Distingue mayúsculas de minúsculas, Kana y ancho, pero no distingue acentos.
_CS_AI_WS2 Distingue mayúsculas de minúsculas y ancho, pero no distingue Kana ni acentos.
_CS_AS2 Distingue mayúsculas de minúsculas y acentos, pero no distingue Kana ni ancho.
_CS_AS_KS2 Distingue mayúsculas de minúsculas, acento y Kana, pero no distingue ancho.
_CS_AS_KS_WS2 Distingue mayúsculas de minúsculas, acentos, Kana y ancho.
_CS_AS_WS2 Distingue mayúsculas de minúsculas, acentos y ancho, pero no distingue Kana.

1 Si están seleccionadas las opciones Binario o Punto de código binario, las opciones Distinguir mayúsculas de minúsculas (_CS), Distinguir acentos (_AS), Distinguir kana (_KS) y Distinguir ancho (_WS) no estarán disponibles.

2 La adición de la opción UTF-8 (_UTF8) permite codificar datos Unicode mediante UTF-8. Para más información, vea la sección Compatibilidad con UTF-8 de este artículo.

Conjuntos de intercalación

SQL Server admite los siguientes conjuntos de intercalación:

intercalaciones de Windows

Las intercalaciones de Windows definen reglas para almacenar los datos de caracteres que se basan en una configuración regional del sistema Windows asociada. En una intercalación de Windows, se puede implementar una comparación de datos no Unicode con el mismo algoritmo que la de los datos Unicode. Las reglas de intercalación básicas de Windows especifican qué alfabeto o idioma se usa cuando se aplica una ordenación de diccionario. Las reglas también especifican la página de códigos que se usa para almacenar los datos de caracteres que no son Unicode. Tanto la ordenación Unicode y como la ordenación no Unicode son compatibles con comparaciones de cadenas de una determinada versión de Windows. Esto proporciona coherencia entre los tipos de datos de SQL Server y permite a los desarrolladores ordenar las cadenas de sus aplicaciones mediante las mismas reglas que usa SQL Server. Para más información, vea Nombre de intercalación de Windows (Transact-SQL).

Intercalaciones binarias

Las intercalaciones binarias ordenan los datos según la secuencia de valores codificados definidos por la configuración regional y el tipo de datos. Distinguen mayúsculas de minúsculas Una intercalación binaria de SQL Server define la configuración regional y la página de códigos ANSI que se usa. Esto exige un criterio de ordenación binario. Como son relativamente simples, las intercalaciones binarias ayudan a mejorar el rendimiento de la aplicación. En los tipos de datos que no son Unicode, las comparaciones de datos se basan en los puntos de código que se definen en la página de códigos ANSI. En tipos de datos Unicode, las comparaciones de datos dependen de los puntos de código Unicode. En las intercalaciones binarias de tipos de datos Unicode, la configuración regional no se tiene en cuenta a la hora de ordenar los datos. Por ejemplo, Latin1_General_BIN y Japanese_BIN generan resultados de orden idénticos cuando se usan en datos Unicode. Para más información, vea Nombre de intercalación de Windows (Transact-SQL).

Hay dos tipos de intercalaciones binarias en SQL Server:

  • Las intercalaciones BIN heredadas, que han realizado una comparación de punto de código a punto de código incompleta para los datos Unicode. Estas intercalaciones binarias heredadas comparaban el primer carácter como WCHAR, seguido de una comparación byte a byte. En una intercalación BIN solo el primer carácter se ordena de acuerdo al punto de código y el resto de ellos se ordenan según sus valores de byte.

  • Las intercalaciones BIN2 más recientes, que implementan una comparación pura de punto de código. En una intercalación BIN2 todos los caracteres se ordenan de acuerdo a sus puntos de código. Como la plataforma de Intel tiene una arquitectura "little endian", los caracteres de codificación Unicode siempre se intercambian por bytes.

Intercalaciones de SQL Server

Las intercalaciones de SQL Server (SQL_*) son compatibles en cuanto al criterio de ordenación con las versiones anteriores de SQL Server. Las reglas de ordenación de diccionario para datos que no son Unicode son incompatibles con cualquier rutina de ordenación suministrada por los sistemas operativos Windows. Sin embargo, la ordenación de datos Unicode es compatible con una versión especial de las reglas de ordenación de Windows. Como las intercalaciones de SQL Server usan reglas de comparación diferentes para los datos Unicode y para los que no son Unicode, ve resultados diferentes en las comparaciones de los mismos datos, dependiendo del tipo de datos subyacente.

Por ejemplo, si usa la intercalación de SQL SQL_Latin1_General_CP1_CI_AS, la cadena 'a-c' que no es Unicode es menor que la cadena 'ab' porque el guion (-) se ordena como un carácter independiente que va antes de b. Sin embargo, si convierte estas cadenas en Unicode y realiza la misma comparación, la cadena Unicode N'a-c' se considera mayor que N'ab', ya que las reglas de ordenación Unicode usan una ordenación de palabras que omite el guion.

Para más información, vea Nombre de intercalación de SQL Server (Transact-SQL).

Durante la configuración de SQL Server, la opción de intercalación de instalación predeterminada viene determinada por la configuración regional del sistema operativo (SO). Puede cambiar las intercalaciones de nivel de servidor durante la instalación o si modifica la configuración regional del SO antes de la instalación. Para la compatibilidad con versiones anteriores, la intercalación predeterminada se establece en la versión más antigua disponible que esté asociada a cada configuración regional concreta. Por tanto, esta no es siempre la intercalación recomendada. Para aprovechar al máximo las características de SQL Server, cambie la configuración de instalación predeterminada para que use las intercalaciones de Windows. Por ejemplo, para la configuración regional del sistema operativo "Inglés (Estados Unidos)" (página de códigos 1252), la intercalación predeterminada durante la instalación es SQL_Latin1_General_CP1_CI_AS y se puede cambiar a la intercalación de Windows homóloga más cercana, Latin1_General_100_CI_AS_SC.

Nota

Al actualizar una instancia en idioma inglés de SQL Server, se pueden especificar intercalaciones de SQL Server (SQL_*) para la compatibilidad con las instancias existentes de SQL Server. Como la intercalación predeterminada de una instancia de SQL Server se define durante la instalación, asegúrese de especificar con cuidado la configuración de la intercalación cuando se cumplan las condiciones siguientes:

  • El código de la aplicación depende del comportamiento de las intercalaciones de SQL Server anteriores.
  • Se deben almacenar datos de caracteres que reflejen varios idiomas.

Niveles de intercalación

Se admite el establecimiento de intercalaciones en los siguientes niveles de una instancia de SQL Server:

Intercalaciones de nivel de servidor

La intercalación predeterminada de servidor se determina durante la instalación de SQL Server y se convierte en la intercalación predeterminada de las bases de datos del sistema y de todas las bases de datos del usuario.

En la tabla siguiente se muestran las designaciones predeterminadas de intercalación, determinadas por la configuración regional del sistema operativo (SO), incluidos los respectivos identificadores de código de idioma (LCID) de Windows y SQL:

Configuración regional de Windows LCID de Windows LCID de SQL Intercalación predeterminada
Afrikáans (Sudáfrica) 0x0436 0x0409 Latin1_General_CI_AS
Albanés (Albania) 0x041c 0x041c Albanian_CI_AS
Alsaciano (Francia) 0x0484 0x0409 Latin1_General_CI_AS
Amárico (Etiopía) 0x045e 0x0409 Latin1_General_CI_AS
Árabe (Argelia) 0x1401 0x0401 Arabic_CI_AS
Árabe (Bahréin) 0x3c01 0x0401 Arabic_CI_AS
Árabe (Egipto) 0x0c01 0x0401 Arabic_CI_AS
Árabe (Iraq) 0x0801 0x0401 Arabic_CI_AS
Árabe (Jordania) 0x2c01 0x0401 Arabic_CI_AS
Árabe (Kuwait) 0x3401 0x0401 Arabic_CI_AS
Árabe (Líbano) 0x3001 0x0401 Arabic_CI_AS
Árabe (Libia) 0x1001 0x0401 Arabic_CI_AS
Árabe (Marruecos) 0x1801 0x0401 Arabic_CI_AS
Árabe (Omán) 0x2001 0x0401 Arabic_CI_AS
Árabe (Qatar) 0x4001 0x0401 Arabic_CI_AS
Árabe (Arabia Saudí) 0x0401 0x0401 Arabic_CI_AS
Árabe (Siria) 0x2801 0x0401 Arabic_CI_AS
Árabe (Túnez) 0x1c01 0x0401 Arabic_CI_AS
Árabe (E. A. U.) 0x3801 0x0401 Arabic_CI_AS
Árabe (Yemen) 0x2401 0x0401 Arabic_CI_AS
Armenio (Armenia) 0x042b 0x0419 Latin1_General_CI_AS
Asamés (India) 0x044d 0x044d No disponible en el nivel de servidor
Azerbaiyano (Azerbaiyán, cirílico) 0x082c 0x082c Obsoleta, no disponible en el nivel de servidor
Azerbaiyano (Azerbaiyán, latino) 0x042c 0x042c Obsoleta, no disponible en el nivel de servidor
Baskir (Rusia) 0x046d 0x046d Latin1_General_CI_AI
Vasco (España) 0x042d 0x0409 Latin1_General_CI_AS
Bielorruso (Bielorrusia) 0x0423 0x0419 Cyrillic_General_CI_AS
Bengalí (Bangladesh) 0x0845 0x0445 No disponible en el nivel de servidor
Bengali (India) 0x0445 0x0439 No disponible en el nivel de servidor
Bosnio (cirílico, Bosnia-Herzegovina) 0x201a 0x201a Latin1_General_CI_AI
Bosnio (latino, Bosnia-Herzegovina) 0x141a 0x141a Latin1_General_CI_AI
Bretón (Francia) 0x047e 0x047e Latin1_General_CI_AI
Búlgaro (Bulgaria) 0x0402 0x0419 Cyrillic_General_CI_AS
Catalán (España) 0x0403 0x0409 Latin1_General_CI_AS
Chino (Hong Kong ZAE, RPC) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Chinese (Macao SAR) 0x1404 0x1404 Latin1_General_CI_AI
Chinese (Macao SAR) 0x21404 0x21404 Latin1_General_CI_AI
Chino (RPC) 0x0804 0x0804 Chinese_PRC_CI_AS
Chino (RPC) 0x20804 0x20804 Chinese_PRC_Stroke_CI_AS
Chinese (Singapore) 0x1004 0x0804 Chinese_PRC_CI_AS
Chinese (Singapore) 0x21004 0x20804 Chinese_PRC_Stroke_CI_AS
Chino (Taiwán) 0x30404 0x30404 Chinese_Taiwan_Bopomofo_CI_AS
Chino (Taiwán) 0x0404 0x0404 Chinese_Taiwan_Stroke_CI_AS
Corso (Francia) 0x0483 0x0483 Latin1_General_CI_AI
Croata (Bosnia y Herzegovina, latino) 0x101a 0x041a Croatian_CI_AS
Croata (Croacia) 0x041a 0x041a Croatian_CI_AS
Checo (República Checa) 0x0405 0x0405 Czech_CI_AS
Danés (Dinamarca) 0x0406 0x0406 Danish_Norwegian_CI_AS
Dari (Afganistán) 0x048c 0x048c Latin1_General_CI_AI
Divehi (Maldivas) 0x0465 0x0465 No disponible en el nivel de servidor
Neerlandés (Bélgica) 0x0813 0x0409 Latin1_General_CI_AS
Neerlandés (Países Bajos) 0x0413 0x0409 Latin1_General_CI_AS
Inglés (Australia) 0x0c09 0x0409 Latin1_General_CI_AS
Inglés (Belice) 0x2809 0x0409 Latin1_General_CI_AS
Inglés (Canadá) 0x1009 0x0409 Latin1_General_CI_AS
Inglés (Caribe) 0x2409 0x0409 Latin1_General_CI_AS
Inglés (India) 0x4009 0x0409 Latin1_General_CI_AS
Inglés (Irlanda) 0x1809 0x0409 Latin1_General_CI_AS
Inglés (Jamaica) 0x2009 0x0409 Latin1_General_CI_AS
Inglés (Malasia) 0x4409 0x0409 Latin1_General_CI_AS
Inglés (Nueva Zelanda) 0x1409 0x0409 Latin1_General_CI_AS
Inglés (Filipinas) 0x3409 0x0409 Latin1_General_CI_AS
Inglés (Singapur) 0x4809 0x0409 Latin1_General_CI_AS
Inglés (Sudáfrica) 0x1c09 0x0409 Latin1_General_CI_AS
Inglés (Trinidad y Tobago) 0x2c09 0x0409 Latin1_General_CI_AS
Inglés (Reino Unido) 0x0809 0x0409 Latin1_General_CI_AS
Spanish (Traditional Sort) - Spain 0x0409 0x0409 SQL_Latin1_General_CP1_CI_AS
Inglés (Zimbabue) 0x3009 0x0409 Latin1_General_CI_AS
Estonio (Estonia) 0x0425 0x0425 Estonian_CI_AS
Feroés (Islas Feroe) 0x0438 0x0409 Latin1_General_CI_AS
Filipino (Filipinas) 0x0464 0x0409 Latin1_General_CI_AS
Finés (Finlandia) 0x040b 0x040b Finnish_Swedish_CI_AS
Francés (Bélgica) 0x080c 0x040c French_CI_AS
Francés (Canadá) 0x0c0c 0x040c French_CI_AS
Francés (Francia) 0x040c 0x040c French_CI_AS
Francés (Luxemburgo) 0x140c 0x040c French_CI_AS
Francés (Mónaco) 0x180c 0x040c French_CI_AS
Francés (Suiza) 0x100c 0x040c French_CI_AS
Frisón (Países Bajos) 0x0462 0x0462 Latin1_General_CI_AI
Gallego 0x0456 0x0409 Latin1_General_CI_AS
Georgiano (Georgia) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
Georgiano (Georgia) 0x0437 0x0419 Latin1_General_CI_AS
Alemán (alfabetización de libreta de teléfonos, DIN) 0x10407 0x10407 German_PhoneBook_CI_AS
Alemán (Austria) 0x0c07 0x0409 Latin1_General_CI_AS
Alemán (Alemania) 0x0407 0x0409 Latin1_General_CI_AS
Alemán (Liechtenstein) 0x1407 0x0409 Latin1_General_CI_AS
Alemán (Luxemburgo) 0x1007 0x0409 Latin1_General_CI_AS
Alemán (Suiza) 0x0807 0x0409 Latin1_General_CI_AS
Griego (Grecia) 0x0408 0x0408 Greek_CI_AS
Groenlandés (Groenlandia) 0x046f 0x0406 Danish_Norwegian_CI_AS
Gujarati (India) 0x0447 0x0439 No disponible en el nivel de servidor
Hausa (Nigeria, latino) 0x0468 0x0409 Latin1_General_CI_AS
Hebreo (Israel) 0x040d 0x040d Hebrew_CI_AS
Hindi (India) 0x0439 0x0439 No disponible en el nivel de servidor
Húngaro (Hungría) 0x040e 0x040e Hungarian_CI_AS
Húngaro técnico 0x1040e 0x1040e Hungarian_Technical_CI_AS
Islandés (Islandia) 0x040f 0x040f Icelandic_CI_AS
Igbo (Nigeria) 0x0470 0x0409 Latin1_General_CI_AS
Indonesio (Indonesia) 0x0421 0x0409 Latin1_General_CI_AS
Inuktitut (Canadá, latino) 0x085d 0x0409 Latin1_General_CI_AS
Inuktitut (silábico, Canadá) 0x045d 0x045d Latin1_General_CI_AI
Irlandés (Irlanda) 0x083c 0x0409 Latin1_General_CI_AS
Italiano (Italia) 0x0410 0x0409 Latin1_General_CI_AS
Italiano (Suiza) 0x0810 0x0409 Latin1_General_CI_AS
Japonés (Japón XJIS) 0x0411 0x0411 Japanese_CI_AS
Japonés (Japón) 0x040411 0x40411 Latin1_General_CI_AI
Canarés (India) 0x044b 0x0439 No disponible en el nivel de servidor
Kazajo (Kazajistán) 0x043f 0x043f Kazakh_90_CI_AS
Jemer (Camboya) 0x0453 0x0453 No disponible en el nivel de servidor
Quiché (Guatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Kinyarwanda (Ruanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (India) 0x0457 0x0439 No disponible en el nivel de servidor
Coreano (Orden del diccionario coreano) 0x0412 0x0412 Korean_Wansung_CI_AS
Kirguizo (Kirguizistán) 0x0440 0x0419 Cyrillic_General_CI_AS
Lao (R.D.P. de Laos) 0x0454 0x0454 No disponible en el nivel de servidor
Letón (Letonia) 0x0426 0x0426 Latvian_CI_AS
Lituano (Lituania) 0x0427 0x0427 Lithuanian_CI_AS
Bajo sorbio (Alemania) 0x082e 0x0409 Latin1_General_CI_AS
Luxemburgués (Luxemburgo) 0x046e 0x0409 Latin1_General_CI_AS
Macedonio (Macedonia del Norte) 0x042f 0x042f Macedonian_FYROM_90_CI_AS
Malayo (Brunéi Darussalam) 0x083e 0x0409 Latin1_General_CI_AS
Malayo (Malasia) 0x043e 0x0409 Latin1_General_CI_AS
Malayalam (India) 0x044c 0x0439 No disponible en el nivel de servidor
Maltés (Malta) 0x043a 0x043a Latin1_General_CI_AI
Maorí (Nueva Zelanda) 0x0481 0x0481 Latin1_General_CI_AI
Mapuche (Chile) 0x047a 0x047a Latin1_General_CI_AI
Maratí (India) 0x044e 0x0439 No disponible en el nivel de servidor
Mohawk (Canadá) 0x047c 0x047c Latin1_General_CI_AI
Mongol (Mongolia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongol (RPC) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepalí (Nepal) 0x0461 0x0461 No disponible en el nivel de servidor
Noruego (Bokmål, Noruega) 0x0414 0x0414 Latin1_General_CI_AI
Noruego (nynorsk, Noruega) 0x0814 0x0414 Latin1_General_CI_AI
Occitano (Francia) 0x0482 0x040c French_CI_AS
Odia (India) 0x0448 0x0439 No disponible en el nivel de servidor
Pastún (Afganistán) 0x0463 0x0463 No disponible en el nivel de servidor
Persa (Irán) 0x0429 0x0429 Latin1_General_CI_AI
Polaco (Polonia) 0x0415 0x0415 Polish_CI_AS
Portugués (Brasil) 0x0416 0x0409 Latin1_General_CI_AS
Portugués (Portugal) 0x0816 0x0409 Latin1_General_CI_AS
Punjabí (India) 0x0446 0x0439 No disponible en el nivel de servidor
Quechua (Bolivia) 0x046b 0x0409 Latin1_General_CI_AS
Quechua (Ecuador) 0x086b 0x0409 Latin1_General_CI_AS
Quechua (Perú) 0x0c6b 0x0409 Latin1_General_CI_AS
Rumano (Rumanía) 0x0418 0x0418 Romanian_CI_AS
Romanche (Suiza) 0x0417 0x0417 Latin1_General_CI_AI
Ruso (Rusia) 0x0419 0x0419 Cyrillic_General_CI_AS
Sakha (Rusia) 0x0485 0x0485 Latin1_General_CI_AI
Sami (inari, Finlandia) 0x243b 0x083b Latin1_General_CI_AI
Sami (Lule, Noruega) 0x103b 0x043b Latin1_General_CI_AI
Sami (lule, Suecia) 0x143b 0x083b Latin1_General_CI_AI
Sami (septentrional, Finlandia) 0x0c3b 0x083b Latin1_General_CI_AI
Sami (septentrional, Noruega) 0x043b 0x043b Latin1_General_CI_AI
Sami (septentrional, Suecia) 0x083b 0x083b Latin1_General_CI_AI
Sami (skolt, Finlandia) 0x203b 0x083b Latin1_General_CI_AI
Sami (meridional, Noruega) 0x183b 0x043b Latin1_General_CI_AI
Sami (meridional, Suecia) 0x1c3b 0x083b Latin1_General_CI_AI
Sánscrito (India) 0x044f 0x0439 No disponible en el nivel de servidor
Serbio (cirílico, Bosnia-Herzegovina) 0x1c1a 0x0c1a Latin1_General_CI_AI
Serbio (latino, Bosnia-Herzegovina) 0x181a 0x081a Latin1_General_CI_AI
Serbio (cirílico, Serbia) 0x0c1a 0x0c1a Latin1_General_CI_AI
Serbio (latino, Serbia) 0x081a 0x081a Latin1_General_CI_AI
Sesotho sa Leboa/sotho septentrional (Sudáfrica) 0x046c 0x0409 Latin1_General_CI_AS
Setswana/tswana (Sudáfrica) 0x0432 0x0409 Latin1_General_CI_AS
Cingalés (Sri Lanka) 0x045b 0x0439 No disponible en el nivel de servidor
Eslovaco (Eslovaquia) 0x041b 0x041b Slovak_CI_AS
Esloveno (Eslovenia) 0x0424 0x0424 Slovenian_CI_AS
Español (Argentina) 0x2c0a 0x0c0a Modern_Spanish_CI_AS
Español (Bolivia) 0x400a 0x0c0a Modern_Spanish_CI_AS
Español (Chile) 0x340a 0x0c0a Modern_Spanish_CI_AS
Español (Colombia) 0x240a 0x0c0a Modern_Spanish_CI_AS
Español (Costa Rica) 0x140a 0x0c0a Modern_Spanish_CI_AS
Español (República Dominicana) 0x1c0a 0x0c0a Modern_Spanish_CI_AS
Español (Ecuador) 0x300a 0x0c0a Modern_Spanish_CI_AS
Español (El Salvador) 0x440a 0x0c0a Modern_Spanish_CI_AS
Español (Guatemala) 0x100a 0x0c0a Modern_Spanish_CI_AS
Español (Honduras) 0x480a 0x0c0a Modern_Spanish_CI_AS
Español (México) 0x080a 0x0c0a Modern_Spanish_CI_AS
Español (Nicaragua) 0x4c0a 0x0c0a Modern_Spanish_CI_AS
Español (Panamá) 0x180a 0x0c0a Modern_Spanish_CI_AS
Español (Paraguay) 0x3c0a 0x0c0a Modern_Spanish_CI_AS
Español (Perú) 0x280a 0x0c0a Modern_Spanish_CI_AS
Español (Puerto Rico) 0x500a 0x0c0a Modern_Spanish_CI_AS
Español (España) 0x0c0a 0x0c0a Modern_Spanish_CI_AS
Español (España, tradicional) 0x040a 0x040a Traditional_Spanish_CI_AS
Español (Estados Unidos) 0x540a 0x0409 Latin1_General_CI_AS
Español (Uruguay) 0x380a 0x0c0a Modern_Spanish_CI_AS
Español (Venezuela) 0x200a 0x0c0a Modern_Spanish_CI_AS
Swahili (Kenia) 0x0441 0x0409 Latin1_General_CI_AS
Sueco (Finlandia) 0x081d 0x040b Finnish_Swedish_CI_AS
Sueco (Suecia) 0x041d 0x040b Finnish_Swedish_CI_AS
Sirio (Siria) 0x045a 0x045a No disponible en el nivel de servidor
Tayiko (Tayikistán) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazight (latino, Argelia) 0x085f 0x085f Latin1_General_CI_AI
Tamil (India) 0x0449 0x0439 No disponible en el nivel de servidor
Tatar (Rusia) 0x0444 0x0444 Cyrillic_General_CI_AS
Telugu (India) 0x044a 0x0439 No disponible en el nivel de servidor
Tailandés (Tailandia) 0x041e 0x041e Thai_CI_AS
Tibetano (RPC) 0x0451 0x0451 No disponible en el nivel de servidor
Turco (Turquía) 0x041f 0x041f Turkish_CI_AS
Turcomano (Turkmenistán) 0x0442 0x0442 Latin1_General_CI_AI
Uigur (RPC) 0x0480 0x0480 Latin1_General_CI_AI
Ucraniano (Ucrania) 0x0422 0x0422 Ukrainian_CI_AS
Alto sorbio (Alemania) 0x042e 0x042e Latin1_General_CI_AI
Urdú (Pakistán) 0x0420 0x0420 Latin1_General_CI_AI
Uzbeko (cirílico, Uzbekistán) 0x0843 0x0419 Cyrillic_General_CI_AS
Uzbeko (Uzbekistán, latín) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Vietnamita (Vietnam) 0x042a 0x042a Vietnamese_CI_AS
Galés (Reino Unido) 0x0452 0x0452 Latin1_General_CI_AI
Wolof (Senegal) 0x0488 0x040c French_CI_AS
Xhosa/isiXhosa (Sudáfrica) 0x0434 0x0409 Latin1_General_CI_AS
Yi (RPC) 0x0478 0x0409 Latin1_General_CI_AS
Yoruba (Nigeria) 0x046a 0x0409 Latin1_General_CI_AS
Zulú/isiZulu (Sudáfrica) 0x0435 0x0409 Latin1_General_CI_AS

Después de que haya asignado una intercalación al servidor, solo la puede cambiar si exporta todos los objetos y datos de base de datos, vuelve a compilar la base de datos master e importa todos los objetos y datos de base de datos. En lugar de cambiar la intercalación predeterminada de una instancia de SQL Server, puede especificar la intercalación deseada al crear una base de datos o una columna de base de datos.

Para consultar la intercalación del servidor de una instancia de SQL Server, use la función SERVERPROPERTY:

SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));

Para consultar todas las intercalaciones disponibles del servidor, utilice la siguiente función integrada de fn_helpcollations():

SELECT * FROM sys.fn_helpcollations();

Intercalación de Azure SQL Database

No puede cambiar ni establecer la intercalación del servidor lógico en Azure SQL Database, pero puede configurar las intercalaciones de cada base de datos tanto para los datos como para el catálogo. La intercalación de catálogo determina la intercalación para los metadatos del sistema, como identificadores de objeto. Ambas intercalaciones se pueden especificar de forma independiente al crear la base de datos en Azure Portal, en T-SQL con CREATE DATABASE, en PowerShell con New-AzSqlDatabase.

Intercalaciones en Azure SQL Managed Instance

La intercalación de nivel de servidor en Instancia administrada de Azure SQL se puede especificar al crear la instancia y no se puede cambiar posteriormente.

Para obtener más información, vea Configurar o cambiar la intercalación del servidor.

Intercalaciones de nivel de base de datos

Cuando se crea o modifica una base de datos, se puede usar la cláusula COLLATE de la instrucción CREATE DATABASE o ALTER DATABASE para especificar la intercalación de base de datos predeterminada. Si no se especifica ninguna intercalación, se asigna a la base de datos la intercalación de servidor.

No se puede cambiar la intercalación de las bases de datos del sistema a menos que se cambie la intercalación del servidor.

  • En SQL Server y Azure SQL Managed Instance, la intercalación de base de datos se usa para todos los metadatos de la base de datos, y es la predeterminada para todas las columnas de cadena, los objetos temporales, los nombres de variable y cualquier otra cadena que se use en la base de datos.
  • En Azure SQL Database, no hay intercalación de servidor, por lo que cada base de datos tiene una intercalación para los datos y una intercalación para el catálogo. La intercalación CATALOG_COLLATION se usa para todos los metadatos de la base de datos, y es la predeterminada para todas las columnas de cadena, los objetos temporales, los nombres de variable y cualquier otra cadena que se use en la base de datos. CATALOG_COLLATION se establece tras la creación y no se puede cambiar.

Cuando se cambia la intercalación de una base de datos de usuario, pueden producirse conflictos de intercalación cuando las consultas en la base de datos tienen acceso a tablas temporales. Las tablas temporales se almacenan siempre en la base de datos del sistema de tempdb, que usa la intercalación de la instancia. Es posible que las consultas que comparan datos de caracteres entre la base de datos de usuario y tempdb generen un error si las intercalaciones producen un conflicto en la evaluación de los datos de caracteres. Puede resolver esta incidencia si especifica la cláusula COLLATE en la consulta. Para más información, vea COLLATE (Transact-SQL).

La intercalación de una base de datos de usuario se puede cambiar con una instrucción ALTER DATABASE similar al siguiente ejemplo de código:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Importante

La alteración de la intercalación de nivel de base de datos no afecta a las intercalaciones de nivel de columna o de expresión. No afecta a los datos de las columnas existentes.

Puede recuperar la intercalación actual de una base de datos mediante una instrucción similar al siguiente ejemplo de código:

SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));

Intercalaciones de columna

Cuando cree o modifique una tabla, puede especificar intercalaciones para cada columna de cadena de caracteres mediante la cláusula COLLATE. Si no especifica ninguna intercalación, se asigna a la columna la intercalación predeterminada de la base de datos.

La intercalación de una columna se puede cambiar con una instrucción ALTER TABLE similar al siguiente ejemplo de código:

ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI;

Intercalaciones de nivel de expresión

Las intercalaciones de nivel de expresión se establecen cuando se ejecuta una instrucción y afectan al modo en que se devuelve un conjunto de resultados. Esto permite que los resultados de la ordenación ORDER BY sean específicos de la configuración regional. Para implementar intercalaciones de nivel de expresión, use una cláusula COLLATE como el siguiente ejemplo de código:

SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;

Configuración regional

Una configuración regional es un conjunto de información que está asociado a una ubicación o referencia cultural. La información puede incluir el nombre e identificador del idioma hablado, la escritura que se usa para escribir el idioma y las convenciones culturales. Las intercalaciones pueden estar asociadas a una o varias configuraciones regionales. Para obtener más información, vea Id. de configuración regional asignados por Microsoft.

Página de códigos

Una página de códigos es un juego ordenado de caracteres en un script determinado en el que un índice numérico, o un valor de punto de código, está asociado con cada carácter. Una página de códigos de Windows se denomina normalmente juego de caracteres o charset. Las páginas de códigos se usan para ofrecer compatibilidad con los juegos de caracteres y las distribuciones de teclado que se usan en distintas configuraciones regionales del sistema Windows.

Criterio de ordenación

El criterio de ordenación especifica cómo se ordenan los valores de datos. El orden afecta a los resultados de la comparación de los datos. Los datos se ordenan con las intercalaciones, y se pueden optimizar mediante los índices.

Compatibilidad con Unicode

Unicode es un estándar que permite asignar puntos de código con caracteres. Como se ha diseñado para abarcar todos los caracteres de todos los idiomas del mundo, no es preciso usar otras páginas de códigos para controlar los distintos juegos de caracteres.

Conceptos básicos de Unicode

El almacenamiento de datos en varios idiomas dentro de una misma base de datos es difícil de controlar cuando solo se usan datos de tipo carácter y páginas de códigos. También es difícil encontrar una página de códigos para la base de datos que pueda almacenar todos los caracteres específicos de cada idioma. Además, es difícil asegurar la traducción adecuada de los caracteres especiales cuando se leen o actualizan desde clientes diferentes que ejecutan distintas páginas de códigos. Las bases de datos que admiten clientes internacionales siempre deberían usar tipos de datos Unicode en vez de tipos de datos no Unicode.

Por ejemplo, imaginemos que una base de datos de clientes en Norteamérica tiene que administrar tres idiomas:

  • Nombres y direcciones en español para México
  • Nombres y direcciones en francés para Quebec
  • Nombres y direcciones en inglés para el resto de Canadá y para Estados Unidos

Cuando use solo columnas de caracteres y páginas de códigos, debe prestar atención para asegurarse de que la base de datos esté instalada con una página de códigos que controle los caracteres de los tres idiomas. También debe prestar atención para asegurar la traducción adecuada de los caracteres de uno de los idiomas cuando se lean en clientes que ejecuten una página de códigos para otro idioma.

Nota

Las páginas de códigos que un cliente usa se determinan en la configuración del sistema operativo (SO). Para establecer las páginas de códigos del cliente en los sistemas operativos Windows, use Configuración regional en el Panel de control.

Sería difícil elegir una página de códigos para los tipos de datos de carácter que admita todos los caracteres que precisa un público mundial. La forma más fácil de administrar los datos de caracteres en las bases de datos internacionales es usar siempre un tipo de datos que admita Unicode.

Tipos de datos Unicode

Si almacena datos de caracteres que reflejan varios idiomas SQL Server (SQL Server 2005 (9.x) y versiones posteriores), use tipos de datos Unicode (nchar, nvarchar y ntext) en lugar de tipos de datos que no sean Unicode (char, varchar y text).

Nota

Para los tipos de datos Unicode, Motor de base de datos puede representar hasta 65 536 caracteres mediante UCS-2 o el intervalo completo de Unicode (1 114 112 caracteres) si se usan caracteres complementarios. Para más información sobre cómo habilitar caracteres adicionales, vea Caracteres adicionales.

Como alternativa, a partir de SQL Server 2019 (15.x), si se usa una intercalación compatible con UTF-8 (_UTF8), los tipos de datos anteriores que no son Unicode (char y varchar) se convierten en tipos de datos Unicode con la codificación UTF-8. SQL Server 2019 (15.x) no cambia el comportamiento de los tipos de datos Unicode que existieran antes (nchar, nvarchar y ntext), que seguirán usando la codificación UCS-2 o UTF-16. Para más información, vea Diferencias de almacenamiento entre UTF-8 y UTF-16.

Consideraciones de Unicode

Hay limitaciones significativas asociadas a los tipos de datos no Unicode. Esto se debe a que un equipo que no es Unicode está limitado a usar una única página de códigos. Es posible que experimente una ganancia de rendimiento al usar Unicode, ya que requiere menos conversiones de páginas de códigos. Las intercalaciones Unicode se deben seleccionar de forma individual en el nivel de expresión, base de datos o columna porque no se admiten en el nivel de servidor.

Al mover los datos de un servidor a un cliente, los controladores de cliente anteriores podrían no reconocer la intercalación del servidor. Esto puede ocurrir al mover los datos de un servidor Unicode a un cliente no Unicode. La mejor opción podría ser actualizar el sistema operativo cliente para que las intercalaciones del sistema subyacentes se actualicen. Si el cliente tiene instalado software cliente de base de datos, se puede considerar la posibilidad de aplicar a dicho software una actualización de servicio.

Sugerencia

También puede intentar utilizar una intercalación diferente para los datos del servidor. Elija una intercalación que se asigne a una página de códigos en el cliente.

Para usar las intercalaciones UTF-16 disponibles en SQL Server (SQL Server 2012 (11.x) y versiones posteriores) a fin de mejorar la búsqueda y la ordenación de algunos caracteres Unicode (solo en las intercalaciones de Windows), puede seleccionar una de las intercalaciones de caracteres adicionales (_SC), o bien una de las de la versión 140.

Para usar las intercalaciones UTF- 8 disponibles en SQL Server 2019 (15.x) a fin de mejorar la búsqueda y la ordenación de algunos caracteres Unicode (solo en las intercalaciones de Windows), debe seleccionar las intercalaciones compatibles con la codificación UTF-8 (_UTF8).

  • La marca UTF8 se puede aplicar a:

    • Intercalaciones lingüísticas que ya son compatibles con caracteres adicionales (_SC) o reconocimiento de la distinción de selector de variación (_VSS)
    • Intercalación binaria BIN2

  • La marca UTF8 no se puede aplicar a:

    • Intercalaciones lingüísticas que no son compatibles con caracteres adicionales (_SC) o reconocimiento de la distinción de selector de variación (_VSS)
    • Intercalaciones binarias BIN
    • Intercalaciones SQL_*

Para evaluar completamente los problemas relacionados con el uso de tipos de datos Unicode y no Unicode, pruebe su escenario para cuantificar las diferencias de rendimiento en su entorno. Se recomienda normalizar la intercalación que se usa en los sistemas de una organización e implementar servidores y clientes Unicode siempre que sea posible.

En muchos casos, SQL Server interactúa con otros servidores o clientes, y es posible que la organización use varios estándares de acceso a datos entre las aplicaciones y las instancias de servidor. Los clientesSQL Server son uno de los dos tipos principales:

  • Clientes Unicode que usan OLE DB y Conectividad abierta de bases de datos (ODBC) versión 3.7 o posterior.
  • Clientes no Unicode que usan DB-Library y ODBC versión 3.6 o anterior.

En la tabla siguiente se proporciona información sobre cómo usar datos multilingües con varias combinaciones de servidores Unicode y no Unicode:

Server Remoto Beneficios o limitaciones
Unicode Unicode Dado que los datos Unicode se usan en todo el sistema, este escenario proporciona el máximo rendimiento y protección frente a daños de los datos recuperados. Se trata de la situación con Objetos de datos ActiveX (ADO), OLE DB y ODBC versión 3.7 o posterior.
Unicode No Unicode En este escenario y especialmente con las conexiones entre un servidor que ejecuta un sistema operativo más reciente y un cliente que ejecuta una versión anterior de SQL Server, o bien un sistema operativo anterior, puede haber limitaciones o producirse errores al mover los datos a un equipo cliente. Los datos Unicode del servidor intentan asignarse a una página de códigos correspondiente en el cliente no Unicode para convertir los datos.
No Unicode Unicode No es una configuración idónea para usar datos multilingües. No puede escribir datos Unicode en el servidor no Unicode. Es probable que se produzcan problemas si los datos se envían a servidores externos a la página de códigos del servidor.
No Unicode No Unicode Se trata de un escenario muy limitado para datos multilingües. Puede usar solo una única página de códigos.

Caracteres adicionales

Unicode Consortium asigna a cada carácter un punto de código único, que es un valor en el intervalo comprendido entre 000000 y 10FFFF. Los caracteres usados con más frecuencia tienen valores de punto de código en el intervalo comprendido entre 000000 y 00FFFF (65 536 caracteres) que se ajustan a una palabra de 8 o 16 bits en memoria y en disco. Este intervalo normalmente se designa como el plano multilingüe básico (BMP).

Pero Unicode Consortium estableció 16 "planos" adicionales de caracteres, cada uno de ellos del mismo tamaño que el BMP. Esta definición ofrece a Unicode la posibilidad de representar 1 114 112 caracteres Unicode (es decir, 216 * 17 caracteres) dentro del intervalo de puntos de código comprendido entre 000000 y 10FFFF. Los caracteres con valores de punto de código mayores que 00FFFF requieren entre dos y cuatro palabras consecutivas de 8 bits (UTF-8) o dos palabras consecutivas de 16 bits (UTF-16). Estos caracteres ubicados más allá del BMP se denominan caracteres adicionales y las dos palabras consecutivas adicionales de 8 o 16 bits se denominan pares suplentes. Para más información sobre los caracteres adicionales, los suplentes y los pares suplentes, consulte el estándar Unicode.

SQL Server proporciona tipos de datos como nchar y nvarchar para almacenar datos Unicode en el intervalo BMP (de 000000 a 00FFFF), que el motor de base de datos codifica mediante UCS-2.

SQL Server 2012 (11.x) introdujo una nueva familia de intercalaciones de caracteres adicionales (_SC) que se pueden usar con los tipos de datos nchar, nvarchar y sql_variant para representar el intervalo de caracteres Unicode completo (de 000000 a 10FFFF). Por ejemplo: Latin1_General_100_CI_AS_SC o, si se usa una intercalación japonesa, Japanese_Bushu_Kakusu_100_CI_AS_SC.

SQL Server 2019 (15.x) amplía la compatibilidad de los caracteres adicionales a los tipos de datos char y varchar con las nuevas intercalaciones habilitadas para UTF-8 (_UTF8). Estos tipos de datos también son capaces de representar el intervalo completo de caracteres Unicode.

Nota

A partir de SQL Server 2017 (14.x), todas las intercalaciones nuevas admiten caracteres complementarios de forma automática.

Si utiliza caracteres adicionales:

  • Los caracteres adicionales se pueden utilizar en las operaciones de ordenación y comparación en las versiones de intercalación 90 o mayores.

  • Todas las intercalaciones de la versión 100 admiten la ordenación lingüística con caracteres adicionales.

  • Los caracteres adicionales no son compatibles con metadatos, como en los nombres de objetos de base de datos.

  • La marca SC se puede aplicar a:

    • Intercalaciones de la versión 90
    • Intercalaciones de la versión 100

  • La marca SC no se puede aplicar a:

    • Intercalaciones de Windows sin versión de la versión 80
    • Intercalaciones binarias BIN o BIN2
    • Intercalaciones SQL*
    • Intercalaciones de la versión 140 (no necesitan la marca SC, dado que ya admiten caracteres adicionales)

En la siguiente tabla se compara el comportamiento de algunas funciones de cadena y algunos operadores de cadena cuando usan caracteres adicionales con y sin intercalación de caracteres adicionales (SCA):

Función u operador de cadena Con una intercalación SCA Sin una intercalación SCA
CHARINDEX

LEN

PATINDEX		 El par suplente de UTF-16 se cuenta como un solo punto de código. El par suplente de UTF-16 se cuenta como dos puntos de código.
LEFT

REPLACE

REVERSE

RIGHT

SUBSTRING

STUFF		 Estas funciones tratan los pares suplentes como un solo punto de código y funcionan de la forma esperada. Es posible que estas funciones dividan cualquier par suplente y provoquen resultados inesperados.
NCHAR Devuelve el carácter correspondiente al valor del punto de código Unicode especificado en el intervalo comprendido entre 0 y 0x10FFFF. Si el valor especificado está en el intervalo comprendido entre 0 y 0xFFFF, se devuelve un carácter. Con valores más altos, se devuelve el suplente correspondiente. Un valor mayor que 0xFFFF devuelve NULL en vez del suplente correspondiente.
UNICODE Devuelve un punto de código UTF-16 en el intervalo comprendido entre 0 y 0x10FFFF. Devuelve un punto de código UCS-2 en el intervalo comprendido entre 0 y 0xFFFF.
Hacer coincidir un carácter comodín

Carácter comodín - caracteres no coincidentes		 Se admiten caracteres adicionales para todas las operaciones de caracteres comodín. No se admiten caracteres adicionales para estas operaciones de caracteres comodín. Se admiten otros operadores de caracteres comodín.

compatibilidad con GB18030

GB18030 es un estándar independiente que se usa en la República Popular China para codificar caracteres chinos. En GB18030, los caracteres pueden tener una longitud de 1, 2 o 4 bytes. SQL Server admite caracteres de codificación GB18030, reconociéndolos en el momento de su entrada en un servidor procedentes de una aplicación del lado cliente y convirtiéndolos y almacenándolos de forma nativa como caracteres Unicode. Una vez almacenados en el servidor, se tratan como caracteres Unicode en las operaciones siguientes.

Puede usar cualquier intercalación china, preferentemente la más reciente: la versión 100. Todas las intercalaciones de la versión 100 admiten la ordenación lingüística con caracteres GB18030. Si los datos incluyen caracteres adicionales (pares suplentes), puede usar las intercalaciones SC disponibles en SQL Server para mejorar la búsqueda y la ordenación.

Nota

Asegúrese de que las herramientas de cliente, como SQL Server Management Studio, usan la fuente Dengxian para mostrar correctamente las cadenas que contienen caracteres con codificación GB18030.

Compatibilidad con escritura compleja

SQL Server puede admitir la entrada, el almacenamiento, el cambio, y la visualización de escrituras complejas. Entre los ejemplos de escritura compleja se encuentran los siguientes tipos:

  • Escritura que incluye la combinación de texto de derecha a izquierda y de izquierda a derecha, caso de una combinación de textos en árabe e inglés.
  • Escritura cuyos caracteres cambian de forma dependiendo de su posición, o al combinarse con otros caracteres como, por ejemplo, los caracteres del árabe, el índico y el tailandés.
  • Idiomas como el tailandés que necesitan diccionarios internos para reconocer palabras porque no existen cortes entre ellas.

Las aplicaciones de base de datos que interactúan con SQL Server deben utilizar controles que sean compatibles con escritura compleja. Los controles de formulario estándar de Windows creados en código administrado están habilitados para escritura compleja.

Intercalaciones japonesas agregadas en SQL Server 2017 (14.x)

A partir de SQL Server 2017 (14.x), se admiten nuevas familias de intercalaciones japonesas, con las permutaciones de varias opciones (_CS, _AS, _KS, _WS y _VSS), así como _BIN y _BIN2.

Para escuchar en estas intercalaciones, puede consultar Motor de base de datos de SQL Server:

SELECT name, description
FROM   sys.fn_helpcollations()  
WHERE  COLLATIONPROPERTY(name, 'Version') = 3;

Todas las nuevas intercalaciones tienen compatibilidad integrada con los caracteres adicionales, por lo que ninguna de las nuevas intercalaciones 140 tienen (o necesitan) la marca SC.

Estas intercalaciones se admiten en los índices, las tablas optimizadas para memoria, los índices de almacén de columnas y los módulos compilados de forma nativa de Motor de base de datos.

Compatibilidad con UTF-8

SQL Server 2019 (15.x) presenta compatibilidad total con la codificación de caracteres UTF-8 ampliamente utilizada como codificación de importación o exportación, y como intercalación de columna o base de datos para los datos de cadena. UTF-8 se permite en los tipos de datos char y varchar, y se habilita al crear o cambiar la intercalación de un objeto a una intercalación con un sufijo UTF8. Un ejemplo es cambiar LATIN1_GENERAL_100_CI_AS_SC a LATIN1_GENERAL_100_CI_AS_SC_UTF8.

UTF-8 solo está disponible para las intercalaciones de Windows que admiten caracteres adicionales, como se presentó en SQL Server 2012 (11.x). Los tipos de datos nchar y nvarchar solo permiten la codificación UCS-2 o UTF-16, y permanecen sin cambios.

Azure SQL Database y Azure SQL Managed Instance admiten UTF-8 en el nivel de base de datos y de columna, mientras que SQL Managed Instance también lo admite a nivel de servidor.

Diferencias de almacenamiento entre UTF-8 y UTF-16

Unicode Consortium asigna a cada carácter un punto de código único, que es un valor en el intervalo comprendido entre 000000 y 10FFFF. Con SQL Server 2019 (15.x), ambas codificaciones, UTF-8 y UTF-16, están disponibles para representar el intervalo completo:

  • Con la codificación UTF-8, los caracteres del intervalo ASCII (entre 000000 y 00007F) requieren 1 byte, los puntos de código entre 000080 y 0007FF requieren 2 bytes, los puntos de código entre 000800 y 00FFFF requieren 3 bytes y los puntos de código entre 0010000 y 0010FFFF requieren 4 bytes.
  • Con la codificación UTF-16, los puntos de código entre 000000 y 00FFFF requieren 2 bytes y los puntos de código entre 0010000 y 0010FFFF requieren 4 bytes.

En la tabla siguiente se describen los bytes de almacenamiento de la codificación para cada intervalo de caracteres y tipo de codificación:

Intervalo de códigos (hexadecimal) Intervalo de códigos (decimal) Bytes de almacenamiento 1 con UTF-8 Bytes de almacenamiento 1 con UTF-16
000000–00007F 0–127 1 2
000080–00009F
0000A0–0003FF
000400–0007FF		 128–159
160–1.023
1\.024–2.047		 2 2
000800–003FFF
004000–00FFFF		 2\.048–16.383
16.384–65.535		 3 2
010000–03FFFF2

040000–10FFFF2		 65.536–262.1432

262.144–1.114.1112		 4 4

1 Los bytes de almacenamiento hacen referencia a la longitud de bytes codificados, no al tamaño en disco del tipo de datos. Para obtener más información acerca de los tamaños de almacenamiento en disco, consulte nchar y nvarchar y char y varchar.

2 El intervalo de puntos de código para caracteres adicionales.

Sugerencia

Es habitual pensar que en CHAR(n) y VARCHAR(n), o en NCHAR(n) y NVARCHAR(n), la n define el número de caracteres. Esto se debe a que en el ejemplo de una columna CHAR(10), se pueden almacenar 10 caracteres ASCII en el intervalo 0-127 mediante una intercalación como Latin1_General_100_CI_AI, porque cada carácter de este intervalo solo usa 1 byte.

Pero en CHAR(n) y VARCHAR(n), n define el tamaño de la cadena en bytes (0-8.000), mientras que en NCHAR(n) y NVARCHAR(n)n define el tamaño de la cadena en pares de bytes (0-4.000). n nunca define números de caracteres que se pueden almacenar.

Como acaba de ver, elegir la codificación Unicode y el tipo de datos adecuado puede proporcionar ahorros significativos de almacenamiento o aumentar la superficie de memoria, según el juego de caracteres en uso. Por ejemplo, al usar una intercalación Latina habilitada para UTF-8, como Latin1_General_100_CI_AI_SC_UTF8, una columna CHAR(10) almacena 10 bytes y puede contener 10 caracteres ASCII en el intervalo 0-127. Pero solo puede contener cinco caracteres en el intervalo 128-2047 y tres caracteres en el intervalo 2048-65535. Por comparación, como una columna NCHAR(10) almacena 10 pares de bytes (20 bytes), puede contener 10 caracteres en el intervalo 0-65535.

Antes de decidir si usar la codificación UTF-8 o UTF-16 para una base de datos o una columna, tenga en cuenta la distribución de datos de cadena que se almacenarán:

  • Si se encuentra principalmente en el intervalo ASCII 0-127 (por ejemplo, inglés), cada carácter requiere 1 byte con UTF-8 y 2 bytes con UTF-16. El uso de UTF-8 ofrece ventajas de almacenamiento. Si se cambia un tipo de datos de columna existente con caracteres ASCII en el intervalo 0-127 de NCHAR(10) a CHAR(10) mediante una intercalación habilitada para UTF-8, esto se traduce en una reducción del 50 % de los requisitos de almacenamiento. Esta reducción se debe a que NCHAR(10) requiere 20 bytes para el almacenamiento, mientras que CHAR(10) necesita 10 bytes para representar la misma cadena Unicode.
  • Por encima del intervalo ASCII, casi todos los alfabetos basados en el latín y los alfabetos griego, cirílico, copto, armenio, hebreo, árabe, siríaco, tāna y n'ko requieren 2 bytes por carácter tanto en UTF-8 como en UTF-16. En estos casos no existen diferencias de almacenamiento importantes con tipos de datos comparables (por ejemplo, entre el uso de char o nchar).
  • Si los scripts son principalmente de idiomas de Este de Asia (por ejemplo, coreano, chino y japonés), cada carácter requiere 3 bytes con UTF-8 y 2 bytes con UTF-16. El uso de UTF-16 ofrece ventajas de almacenamiento.
  • Los caracteres del intervalo comprendido entre 010000 y 10FFFF requieren 4 bytes en UTF-8 y UTF-16. En estos casos, no existen diferencias en el almacenamiento con tipos de datos comparables (por ejemplo, entre usar char o nchar).

Para otras consideraciones, consulte Escribir instrucciones Transact-SQL internacionales.

Conversión a UTF-8

Dado que en CHAR(n) y VARCHAR(n), o en NCHAR(n) y NVARCHAR(n), n define el tamaño de almacenamiento en bytes y no el número de caracteres permitidos, es importante determinar el tamaño del tipo de datos al que realizar la conversión para evitar que los datos se trunquen.

Por ejemplo, considere una columna definida como NVARCHAR(100) que almacena 180 bytes de caracteres japoneses. En este ejemplo, los datos de la columna están codificados actualmente mediante UCS-2 o UTF-16, que utiliza 2 bytes por carácter. Para evitar el truncamiento de datos no basta con convertir el tipo de columna en VARCHAR(200), ya que el nuevo tipo de datos solo puede almacenar 200 bytes, pero los caracteres japoneses requieren 3 bytes cuando están codificados en UTF-8. Por lo que, para evitar la pérdida de datos a través del truncamiento de datos, la columna debe definirse como VARCHAR(270) .

Por lo tanto, es necesario saber de antemano cuál es el tamaño de bytes previsto para la definición de columna antes de convertir los datos existentes a UTF-8, y ajustar el nuevo tamaño del tipo de datos como corresponda. Consulte el script de Transact-SQL o el bloc de notas de SQL en el GitHub de ejemplos de datos, que usan la función DATALENGTH y la instrucción COLLATE para determinar los requisitos de longitud de datos correctos para las operaciones de conversión UTF-8 en una base de datos existente.

Para cambiar la intercalación de columna y el tipo de datos en una tabla existente, use uno de los métodos descritos en Establecer o cambiar la intercalación de columnas.

Para cambiar la intercalación de bases de datos y permitir que los nuevos objetos hereden la intercalación de las bases de datos de forma predeterminada, o para cambiar la intercalación del servidor y permitir que las bases de datos nuevas hereden la intercalación del sistema de forma predeterminada, consulte la sección Tareas relacionadas de este artículo.

Tarea Artículo
Describe cómo establecer o cambiar la intercalación de la instancia de SQL Server. Cambiar la intercalación de servidor no cambia la de las bases de datos existentes. Configurar o cambiar la intercalación del servidor
Describe cómo establecer o cambiar la intercalación de una base de datos de usuario. Cambiar la intercalación de una base de datos no cambia la de las columnas de tabla existentes. Establecer o cambiar la intercalación de base de datos
Se describe cómo establecer o cambiar la intercalación de una columna de la base de datos. Establecer o cambiar la intercalación de columnas
Se describe cómo devolver información de intercalación en el nivel de servidor, base de datos o columna. Ver información de intercalación
Se describe cómo escribir instrucciones Transact-SQL que sean más portátiles de un idioma a otro, o bien que admitan varios idiomas más fácilmente. Escribir instrucciones Transact-SQL internacionales
Describe cómo cambiar el idioma de los mensajes de error y las preferencias con respecto a cómo usar y mostrar los datos de fecha, hora y divisa. Establecer un idioma de la sesión

Contenido relacionado

Para más información, vea el contenido relacionado siguiente:

Consulte también