Comment convertir un flux d'octets en un autre encodage?

J'essaie de convertir un flux d'octets avec la fonction WinAPI MultiByteToWideChar().Comment convertir un flux d'octets en un autre encodage?

Documentation dit fonction échoue avec ERROR_NO_UNICODE_TRANSLATION sur des chaînes incomplètes (pas d'octet de fin de chaîne codée multi-octets). Comment puis-je empêcher cette erreur? La seule façon qui vient à l'esprit est de ne pas convertir le dernier caractère multi-octets du tampon d'entrée (en utilisant IsDBCSLeadByteEx() pour le localiser).

Y at-il de meilleures solutions pour convertir un flux d'octets?

Source

2010-08-07 Basilevs

Quelles pages de code utilisez-vous? Sous quelle forme recevez-vous les données? J'espère du début à la fin et non l'inverse. – Oleg

Le code devrait fonctionner avec toutes les pages de codes supportées par les plateformes Windows. Je reçois les données en codage multi-octets ou mono-octet et je souhaite le traiter en interne sous forme large, en le convertissant en codage spécifique aux paramètres régionaux en sortie (après traitement). – Basilevs

Il me semble que vous pouvez simplement utiliser CharNextExA pour passer à la position suivante dans le flux d'entrée. Dans la façon dont vous pouvez obtenir quelques caractères et convertir ensemble dans la chaîne UNICODE à l'égard de MultiByteToWideChar. Une fois que vous avez le fragment de texte UNICODE, vous pouvez le convertir dans une autre page de code en utilisant WideCharToMultiByte.

MISE À JOUR: Je suis sûr que le processus de réception du flux des données d'entrée est beaucoup plus lentement que le décodage des données en ce qui concerne des CharNextExA, MultiByteToWideChar et WideCharToMultiByte. Par exemple, si vous utilisez un tampon sur la pile comme WCHAR szBuffer[4096] et TCHAR szDestBuffer[4096] alors vous serez en mesure de décoder 1K de données d'entrée très rapidement. Donc, je suppose que le temps total de travail de votre programme sera presque indenté de l'utilisation de ces trois fonctions.

De plus, je ne suis pas sûr que vous avez une alternative. Je ne connais aucun moyen fiable pour commencer le décodage du texte soit depuis le début de la fin du texte. Probablement d'autres personnes ont une autre idée ...

Source

2010-10-19 16:46:25 Oleg

J'ai besoin d'une approche plus efficace - les blocs de données sont très gros et je ne veux pas appeler la fonction pour chaque symbole. Y a-t-il un moyen de réduire un nombre d'appels? – Basilevs

Il me semble qu'une autre façon est impossible si vous voulez supporter toutes les pages de codes supportées par les plateformes Windows. Dans la documentation de 'IsDBCSLeadByteEx' vous pouvez lire: « . Les valeurs d'octets de plomb sont spécifiques à chaque DBCS distinctes Certaines valeurs d'octets peuvent apparaître dans une seule page de code à la fois comme l'octet de plomb et piste d'un caractère DBCS Ainsi, IsDBCSLeadByteEx ne peut indiquer. une valeur potentielle d'octet de plomb. ". L'analyse séquentielle des données avec «CharNextExA» semble donc être le seul moyen sûr. Vérifiez simplement si vous allez remplir les changements de performance de l'utilisation de 'CharNextExA'. C'est rapide. 'CharPrevExA' est lent – Oleg

Analyse une queue de 10 octets à la fin du tampon de 10000 octets avec CharPrevExA() plus lent que le traitement du tampon entier avec CharNextExA()? CharPrevExA fonctionnera-t-il correctement avec un milieu de caractère comme argument lpCurrentChar? – Basilevs

Comment convertir un flux d'octets en un autre encodage?

Répondre

Questions connexes