Une API (ou unicode ?) pour les caractères japonais

Question

Bonjour à tous, Je développe en vb 4.0 pro. Oui je sais, je devrais migrer, mais je ne m'y fais pas... J'ai besoin d'afficher les caractères japonais, chinois et arabes dans des controls. Il y a quelques années, un ami dont j'ai perdu la trace, le faisait mais je ne sais pas si c'était avec une API window ou en utilisant l'Unicode UTF-8 (???). J'ai beau chercher et fouiller sur le net, je ne trouve pas. De toutes façons, j'aurais certainement beaucoup de mal à m'en servir... Quelqu'un pourrait-il m'aider ? J'ai trouvé ces document et code, en c++ semble-t-il, (illisible pour moi...) qui me parait, si j'ai compris, donner un début de commencement à... [Le doc] "J'ai une chaîne de caractères multi-octets contenant un mélange de japonais et en caractères latins. J'essaie de copier des parties de cette chaîne à un emplacement de mémoire distincts. Comme c'est une chaîne de caractères multi-octets, certains des personnages utilise un octet et d'autres personnages utilise deux. Lorsque des pièces de la copie de la chaîne, je ne dois pas copier "la moitié des caractères japonais". Pour être en mesure de le faire correctement, j'ai besoin d'être en mesure de déterminer où les caractères multi-octets chaîne commence et se termine. Par exemple, si la chaîne contient 3 caractères qui exige [2] byte [2 octets] [1] octet, il faut que je copie, soit 2, 4 ou 5 octets à l'emplacement d'autres et non pas 3, car si je copie 3 I va copier seulement la moitié du deuxième caractère. Pour savoir où les caractères multi-octets chaîne commence et se termine, je suis en train d'utiliser la fonction API Windows CharNext et CharNextExA mais sans succès. Quand je utiliser ces fonctions, ils naviguer dans ma chaîne d'un octet à la fois, plutôt que d'un caractère à la fois. Selon MSDN, CharNext est censé à la fonction CharNext récupère un pointeur vers le caractère suivant dans une chaîne.. Voici un code pour illustrer ce problème: #include #include #include #include /* string consisting of six "asian" characters */ wchar_t wcsString[] = L"\u9580\u961c\u9640\u963f\u963b\u9644"; int main() { // Convert the asian string from wide char to multi-byte. LPSTR mbString = new char[1000]; WideCharToMultiByte( CP_UTF8, 0, wcsString, -1, mbString, 100, NULL, NULL); // Count the number of characters in the string. int characterCount = 0; LPSTR currentCharacter = mbString; while (*currentCharacter) { characterCount++; currentCharacter = CharNextExA(CP_UTF8, currentCharacter, 0); } } (S'il vous plaît ne pas tenir compte des fuites de mémoire et l'échec à faire une vérification d'erreur.) Or, dans l'exemple ci-dessus, je m'attends à ce que characterCount devient 6, puisque c'est le nombre de caractères dans la chaîne de l'Asie. Mais au lieu, devient characterCount 18 parce que mbstring contient 18 caractères: é–€é˜œé™€é˜¿é˜»é™„ Je ne comprends pas comment il est censé fonctionner. Comment est CharNext censé savoir si «e-€ é" dans la chaîne est une version codée d'un caractère japonais, ou en fait les caractères é - € et E? Quelques notes: ■ J'ai lu Joels blog post sur ce que chaque développeur a besoin de savoir sur Unicode. J'ai peut-être mal compris quelque chose de bien. ■ Si tout ce que je voulais faire était de compter les caractères, je pouvais compter les caractères dans la chaîne d'Asie directement. Gardez à l'esprit que mon but réel est la copie des pièces de la chaîne de caractères multi-octets dans un répertoire distinct. L'autre endroit ne supporte que les caractères multi-octets, pas WideChar. ■ Si je convertir le contenu de mbstring Retour à la gamme char à l'aide MultiByteToWideChar, j'obtiens la bonne chaîne (门阜陀阿阻附), ce qui indique qu'il n'y a rien de mal à mbstring. EDIT: Apparemment, les fonctions CharNext ne supporte pas UTF-8, mais Microsoft a oublié de document. Je jetai / copiedpasted ainsi mon propre routine, que je n'utilise pas et qui doit être amélioré. Je devine que c'est facile crashable. LPSTR CharMoveNext(LPSTR szString) { if (szString 0 || *szString 0) return 0; if ( (szString[0] & 0x80) == 0x00) return szString + 1; else if ( (szString[0] & 0xE0) == 0xC0) return szString + 2; else if ( (szString[0] & 0xF0) == 0xE0) return szString + 3; else if ( (szString[0] & 0xF8) == 0xF0) return szString + 4; else return szString +1; } doc Qu'en pensez-vous ? Cordialement, Whombat. Prédire l'avenir est particulièrement aléatoire, surtout lorsqu'il s'agit du futur.

cs_Jack · Answer

Salut

Les caractères 'étrangers' doivent être codés sur 2 octets.
En fait, le problème réside souvent dans l'affichage de ces caractères, les composants VB6 (et à fortiori VB4), ne sont pas UniCode et ne permettent pas l'affichage de ces caractères.
Les composants de Office (MSForms2) le sont, mais sont sous licence.

&#38463 est la même chose que u963F (équivalent hexadécimal) - 2 octets

Voir <ce lien> ainsi que les codes du site une fois que tu auras cherché "unicode" parmi les sources (sauf .Net)

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

whombat · Answer

Merci Jack pour votre réponse.

J'essaie d'avoir le lien mais ça bloque...

Question subsidiaire : et quid des caractères grecs, cyrilliques et nordiques ? 

Cordialement,

Whombat.

Prédire l'avenir est particulièrement aléatoire, 
surtout lorsqu'il s'agit du futur.

cs_Jack · Answer

Va sur <ce lien> et recherche ce texte "Five ways to display UTF-8 without unicode controls" pour trouver la source en question.

Il n'y a pas une technique par langue, heureusement; toutes sont affichables selon un système de code associé aux caractères.

Une API (ou unicode ?) pour les caractères japonais

3 réponses

Votre réponse

Discussions similaires