• Articles
• admin

No, no hay forma de «arreglar» los datos porque los datos ya no están allí. Al convertir a VARCHAR, los valores subyacentes de cada carácter se cambiaron al valor ASCII de ?. Esto no es un problema de visualización, esos caracteres ahora son físicamente un signo de interrogación regular. Por desgracia, tendrá que hacer una restauración a partir de una copia de seguridad.

El siguiente código de ejemplo muestra que una vez que un carácter Unicode se convierte en VARCHAR (suponiendo que la página de códigos indicada por la intercalación no admite ese carácter), se convierte en un signo de interrogación normal, y para siempre permanecerá como tal:

DECLARE @Character NCHAR(1) = NCHAR(0x3525);SELECT @Character AS , UNICODE(@Character) AS , ASCII(@Character) AS , UNICODE(CONVERT(VARCHAR(5), @Character)) AS , UNICODE(CONVERT(NVARCHAR(5), CONVERT(VARCHAR(5), @Character))) AS , ASCII('?') AS , UNICODE(N'?') AS ;-- 㔥 13605 63 63 63 63 63

El siguiente ejemplo muestra una instancia de un carácter Unicode que es muy dudoso (al menos en este momento) que se admita en la mayoría de las fuentes, por lo que aparece como un cuadro cuadrado, pero la función UNICODE built-n muestra que el código subyacente sigue siendo el Punto de código Unicode correcto:

SELECT NCHAR(0xABBF), N'ꮿ', UNICODE(N'ꮿ');-- ꮿ ꮿ 43967

El carácter real se puede ver aquí: Cherokee Letra pequeña YA U + ABBF. Este es un problema de visualización, y muchos caracteres que no están representados en varias fuentes se mostrarán de la misma manera sin alterar el valor real del carácter, pero siguen siendo caracteres distintos.