Unicode en SQL Server: caracteres, bytes y pérdida de texto

Cambiar una columna a nvarchar no repara texto convertido previamente en signos de interrogación. La corrección Unicode depende de todo el recorrido: decodificación, aplicación, parámetros, expresiones SQL, columna y exportación deben conservar los mismos caracteres.

Separar caracteres y almacenamiento

En nvarchar(n), n representa pares de bytes UTF-16, no garantiza n caracteres visibles. Los caracteres suplementarios pueden necesitar dos unidades. Un carácter mostrado también puede combinar varios puntos de código, como letra y acento. Los límites visuales de la aplicación y los del almacenamiento pueden diferir.

DECLARE @text nvarchar(20)=N'café ';
SELECT LEN(@text) AS LengthWithoutTrailingSpaces,
       DATALENGTH(@text) AS StorageBytes;
DECLARE @emoji nvarchar(2)=N'😀';
SELECT LEN(@emoji COLLATE Latin1_General_100_CI_AS_SC) AS Characters,
       DATALENGTH(@emoji) AS StorageBytes;

La primera medición demuestra que LEN ignora espacios finales y DATALENGTH mide bytes. LEN por sí solo no valida preservación exacta. La segunda usa una intercalación compatible con caracteres suplementarios: el emoji cuenta como un carácter, pero ocupa cuatro bytes en nvarchar.

N crea un literal Unicode. Sin ese prefijo, una conversión por una página de códigos puede perder caracteres antes de asignar nvarchar. Los parámetros de aplicación también deben usar el tipo Unicode previsto. Incluya texto no latino real, no únicamente nombres ASCII.

Comparar codificaciones con datos representativos

SQL Server 2019 admite UTF-8 para varchar con intercalaciones apropiadas. Eso no convierte automáticamente todas las columnas varchar existentes en Unicode. Importan intercalación y expresiones intermedias. En varchar(n), n limita bytes; los caracteres multibyte reducen la cantidad almacenable.

UTF-8 puede ahorrar espacio con contenido mayormente ASCII, pero otras escrituras necesitan más bytes. Compare valores e índices representativos sin asumir un ahorro universal del cincuenta por ciento. Versión, límites y compatibilidad de clientes forman parte de la decisión.

Cambiar intercalación también afecta unicidad. Comparaciones sin distinción de acentos o mayúsculas pueden considerar iguales entradas diferentes. Textos visualmente idénticos pueden tener secuencias distintas de puntos de código. Defina normalización e identidad de forma explícita.

Verificar el recorrido completo

Prepare acentos, cirílico, CJK, emoji, marcas combinadas, comillas y espacios finales significativos. Envíelos por API real, inserción parametrizada, lectura, serialización y exportación. Compare secuencia devuelta y original, además de bytes cuando corresponda. Una inserción correcta prueba solo una etapa.

Antes de migrar, mida longitudes máximas en bytes y valores cercanos al límite. Revise índices, restricciones, columnas calculadas e integraciones con parámetros varchar. Una copia de pruebas con comparación de ida y vuelta detecta pérdidas que un conteo de filas no muestra.

Si los datos antiguos ya contienen reemplazos, busque la fuente original. Una conversión de tipo no adivina texto perdido. Recupérelo desde fuente o respaldo verificado e identifique filas imposibles de restaurar fielmente.

El objetivo es devolver la misma secuencia introducida, salvo normalización acordada. Pruebe también descarga y reimportación de archivos. Añada valores justo en la capacidad máxima y otros que la excedan para confirmar un rechazo explícito, no una pérdida silenciosa. El controlador y las transformaciones importan tanto como la definición de columna.

Referencias técnicas: Microsoft Learn: nvarchar · Microsoft Learn: Unicode and UTF-8 · Microsoft Learn: DATALENGTH.