2009-09-19 7 views
0

J'importe des fichiers au format codepage 1252 vers une base de données SQL Server 2008.Conversion de l'application de codage VB6 en C#

Certaines données contiennent une virgule qui n'est pas la virgule traditionnelle (keycode 44) mais 8218.

La colonne contenant cette valeur est cryptée via un algorithme de VB6. Lorsque j'implémente le même algorithme en C#, j'obtiens la valeur 130 qui ne correspondra donc pas 8218.

Qu'est-ce qui me manque? Je pensais que je partagerais la solution .... Dieu merci pour Reflector. C'était aussi simple que ça ...

+1

Est-ce que le codage ou le cryptage VB6? –

+2

Quoi qu'il en soit, donnez plus d'informations sur cet algorithme, car il n'est pas responsable. –

+0

... et un exemple (vidage hexadécimal) des données avant. (Citer le code VB6 est probablement le meilleur moyen de montrer l'algorithme.) – Richard

Répondre

2

Comme toujours, l'essentiel est de séparer chaque bit du processus, et de vérifier les chaînes à chaque étape.

Donc, d'abord écrire un programme qui lit juste le fichier et vide les détails des chaînes, en termes de valeurs Unicode. J'ai un code sur mon strings page qui aidera avec ceci. Lorsque vous lisez le fichier, spécifiez le codage explicitement.

Ensuite, écrivez un programme séparé avec des littéraux codés en dur (en utilisant \uxxxx si nécessaire) pour télécharger dans la base de données. Ensuite, examinez les chaînes de la base de données aussi précisément que possible. Je m'attendrais à ce que le bit de téléchargement fonctionne, tant que la base de données possède les paramètres appropriés.

Il y a un peu plus sur ce processus général sur ma page "debugging unicode problems".

0

Après joué un peu, je suis venu avec ceci:

/// <summary> 
/// Some charcodes produced by unicode character handling 
/// does not map correctly to codepage 1252. This function 
/// translates every char to codepage 1252, unless the char 
/// takes more than one byte. Then it gets encoded using Unicode. 
/// </summary> 
/// <param name="chars"></param> 
/// <returns></returns> 
private string GetStringAfterFixingEncoding(IEnumerable<char> chars) 
{ 
    var result = new StringBuilder(); 

    foreach (var c in chars) 
    { 
     var unicodeBytesForChar = Encoding.Unicode.GetBytes(new[] { c }); 

     if (unicodeBytesForChar.Length > 1 && unicodeBytesForChar[1] != 0) 
      result.Append(Encoding.Unicode.GetChars(unicodeBytesForChar)[0]); 
     else 
      result.Append(_encoding.GetChars(unicodeBytesForChar)[0]); 
    } 

    return result.ToString(); 
} 
3

130 est la porte-fenêtre 1252 encodage pour le caractère U+201A (décimal 8218), "Single Low-9 Guillemet". Si vous le décodez correctement, le résultat char aura la valeur numérique 8218 car .NET utilise UTF-16 ("Unicode") en interne. Il semble que vous ayez décodé la séquence Windows-1252 octets comme ISO-8859-1, qui mappe 0x82 (décimal 130) à un caractère de contrôle avec la valeur numérique 130. Si c'est le cas, la véritable solution à votre problème est pour revenir en arrière et changer la partie qui décode mal en premier lieu.

+0

Oui, mais je ne possède pas ces données et même si j'ai une copie des données, j'ai l'obligation de les laisser dans leur état d'origine. // D – Daniel