Compatibilidad con la intercalación y Unicode
Se aplica a: 
SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) Punto de conexión de análisis SQL en Microsoft Fabric Almacenamiento 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
- Intercalaciones de nivel de base de datos
- Intercalaciones de nivel de columna
- Intercalaciones de nivel de expresión
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)aCHAR(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 queNCHAR(10)requiere 20 bytes para el almacenamiento, mientras queCHAR(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.
Tareas relacionadas
| 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:
- Prácticas recomendadas para cambiar las intercalaciones en SQL Server
- Uso del formato de caracteres Unicode para importar o exportar datos (SQL Server)
- Escribir instrucciones Transact-SQL internacionales
- Migración de los procedimientos recomendados de SQL Server a Unicode (ya no se mantiene)
- Unicode Consortium
- Unicode estándar
- Compatibilidad de UTF-8 con el controlador OLE DB para SQL Server
- Nombre de intercalación de SQL Server (Transact-SQL)
- Nombre de intercalación de Windows (Transact-SQL)
- Introducing UTF-8 support for SQL Server (Presentación de la compatibilidad de UTF-8 con SQL Server)
- COLLATE (Transact-SQL)
- Prioridad de intercalación