• Articles
• admin

Non, il n’y a aucun moyen de « réparer » les données car les données ne sont plus là. Lorsque vous avez converti en VARCHAR, les valeurs sous-jacentes de chaque caractère ont été modifiées en valeur ASCII pour ?. Ce n’est pas un problème d’affichage, ces caractères sont maintenant physiquement un point d’interrogation régulier. Vous devrez faire une restauration à partir d’une sauvegarde, malheureusement.

L’exemple de code suivant montre qu’une fois qu’un caractère Unicode est converti en VARCHAR (en supposant que la Page de code indiquée par le Classement ne supporte pas ce caractère), il devient un point d’interrogation régulier et restera-t-il pour toujours en tant que tel:

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

L’exemple suivant montre une instance d’un caractère Unicode dont il est très douteux (du moins pour le moment) d’être pris en charge dans la plupart des polices, il apparaît donc sous la forme d’une boîte carrée, mais la fonction UNICODE built-n montre que le code sous-jacent est toujours le bon Point de code Unicode:

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

Le caractère réel peut être vu ici: Cherokee Petite lettre YA U + ABBF. Il s’agit d’un problème d’affichage, et de nombreux caractères qui ne sont pas représentés dans différentes polices s’afficheront de la même manière sans modifier la valeur réelle du caractère, mais ce sont toujours des caractères distincts.