Puis-je récupérer des caractères internationaux stockés par erreur dans un champ varchar?
https://stackoverflow.com/questions/241868
-
04-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Mon client possède une ancienne base de données MS SQL 2000 qui utilise des champs varchar (50) pour stocker les noms. Il a essayé d'utiliser cette base de données pour capturer certaines données (via un formulaire Web). Certains remplisseurs de formulaires proviennent d’autres pays et les champs de varchar sont devenus fous lorsque certains d’entre eux ont entré leur nom. Est-il possible de récupérer les données en quelque sorte? Peut-être en devinant sur quoi le personnage devrait être basé sur ce qu’il a résolu en ASCII / varchar et le pays d’origine de la personne? Certaines des données:
Nom / Pays / Prénom ou Nom?
JiÅ ™ Ã / CZE / F
Torbjörn / FIN / F
Huszár / HUN / L
Jürgen / DEU / F
Müller / CHE / L
Bumbálková / CZE / L
Doležal / CZE / L
Loïc / DEU / L
Au fait, le formulaire Web a spécifié ce type de contenu:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
La solution
Travailler à partir du 5ème exemple.
& # 195; est ascii # 195 (C3). & # 188; est ascii # 188 (BC).
Je suppose que M & # 195; Ller est censé être M & l.
S'il s'agit du format UTF-8, basé sur http://en.wikipedia.org/wiki/UTF-8#Description
Nous avons C3 BC = 1100 0011 1011 1100
Application du mappage UTF-8:
(110) 00011 (10) 11 1100
0000 0000 1111 1100
00FC, qui correspond à Unicode & # 252;
U + 00FC (voir http://en.wikipedia.org/wiki/Latin_characters_in_Unicode)
Il me semble que vous pouvez résoudre ce problème par programmation.
Maintenant, résolvons le premier exemple:
Ji & # 229; & # 8482; & # 227; était en réalité Ji & # 197; & # 8482; & # 195; & # 173; (Le dernier caractère n'est pas affiché).
Ignorer le Ji, ce qui est correct,
C5 99 c3 AD
(110) 0 0101 (10) 01 1001 (110) 0 0011 (10) 10 1101
0159 00ED
& # 345; & # 237;
Le nom est donc: Ji & # 345; & # 237 ;. Wikipedia dit que le r spécial est tchèque et que le i. De plus, si je google Ji & # 345; & # 237; ( http: // www .google.com / search? q = Ji% C5% 99% C3% AD & ie; = utf-8 & amp; oe = utf-8 ) Je reçois beaucoup de résultats. Nous sommes sur un gagnant ici.
Le deuxième exemple, Torbj & # 182; rn, correspond bien à Torbj & # 246; rn, ce qui semble convaincant.
IMHO il n'y a pas grand besoin de vérification humaine de ceux-ci, ils semblent juste fonctionner.
Autres conseils
La poste russe l'a fait. Quelqu'un a-t-il sauvegardé l'image avant qu'elle ne disparaisse?
Vous devez fondamentalement passer par libiconv pour le convertir en UTF8.
La liste complète des jeux de caractères appropriés dépendra de votre application, mais vous pouvez en déduire certaines suppositions en fonction du code de pays. Commencez par cette page sur WikiPedia .
Avertissement: vous aurez besoin d'un humain pour vérifier chaque conversion.
Suite aux commentaires de Richard: si la page Web contenant le formulaire spécifie un jeu de caractères (par exemple, iso-8859-1 == unicode) & amp; codage (par exemple, utf-8), un navigateur conforme aux normes doit soumettre les données de formulaire à l’aide de ce jeu de caractères et de ce codage. Si vos pages Web spécifient unicode, vous ne devriez pas avoir à gérer des pages de code Microsoft aléatoires dans les données, elles devraient toutes être unicode.
