• Articles
• admin

nu, nu există nicio modalitate de a „repara” datele, deoarece datele nu mai există. Când ați convertit la VARCHAR, valorile subiacente pentru fiecare caracter au fost modificate în valoarea ASCII pentru ?. Aceasta nu este o problemă de afișare, aceste caractere sunt acum fizic un semn de întrebare regulat. Va trebui să faceți o restaurare dintr-o copie de rezervă, din păcate.

următorul exemplu de cod arată că odată ce un caracter Unicode este convertit în VARCHAR(presupunând că pagina de cod notată de colaționare nu acceptă acel caracter), devine un semn de întrebare obișnuit și va rămâne pentru totdeauna ca atare:

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

următorul exemplu arată o instanță a unui caracter Unicode care este extrem de îndoielnic (cel puțin în acest moment) să fie acceptat în majoritatea fonturilor, prin urmare, apare ca o cutie pătrată, dar UNICODE built-n funcția arată că codul de bază este încă punctul corect de cod Unicode:

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

caracterul real poate fi văzut aici: Cherokee scrisoare mică YA U+ABBF. Aceasta este o problemă de afișare și multe caractere care nu sunt reprezentate în diferite fonturi se vor afișa în același mod fără a modifica valoarea reală a caracterului, dar sunt încă caractere distincte.