Question

Je travaille sur une application Delphi 2009 qui utilise beaucoup le format RTF, modifiée à l'aide de TRichEdit et TLMDRichEdit. Les utilisateurs ayant saisi du texte japonais dans ces contrôles RTF ont soumis des rapports intermittents sur le texte japonais affiché sous forme de charabia lors du rechargement du contenu, à la fois sous Win XP et Vista, avec la prise en charge de la langue orientale installée.

Généralement, l'anglais et le japonais sont mélangés et sont généralement affichés sans problème, par exemple:

Inventory turns partnerships.  在庫回転率の

(Toutes mes excuses si le texte japonais est mal brisé - je ne parle ni ne lis la langue).

Cependant, très souvent, seule la partie japonaise du texte sera du charabia, par exemple:

ŒÉñ?“]-¦Œüã‚Ì·•Ê‰?-vˆö‚ðŽû‰v‚ÉŒø‰?“I‚ÉŒ‹‚т‚¯‚é’mŽ¯‚ª‘÷Ý‚·‚é?(マーケットセクター、
見込み客の優  先順位と彼らに販売する知識)

Une recherche en ligne poussée semble indiquer que le problème provient des polices enregistrées dans le fichier RTF. Les polices présentes sur la version japonaise de Windows ne correspondent pas nécessairement à la version anglaise des États-Unis. Il est possible de remplacer par programme les polices du fichier RTF, ce qui donne un résultat presque acceptable, c’est-à-dire.

-D‚‚スƒIƒyƒŒ[ƒVƒ・“‚ニƒƒWƒXƒeƒBƒbƒN‚フƒpƒtƒH[ƒ}ƒ“ƒX‚-˜‰v‚ノŒ‹‚ム‚ツ‚ッ‚ネ‚「‚±ニ‚ヘ?A‘‚「‚ノ-ウ‘ハ‚ナ‚ ‚驕B‚サ‚‚ヘAl“セ‚オ‚ス・‘P‚フˆロ‚ƒƒXƒN‚ノ‚ウ‚‚キB

Cependant, il existe encore de nombreux "objets indésirables". les caractères qui ne sont pas correctement reconnus en tant que caractères japonais. En regardant le RTF brut, vous verrez ce qui suit:

-D\'82\'82\u65405?\'83I\'83y\'83\'8c[\'83V\'83\u12539?\ldblquote\'82\u65414?

Clairement, les caractères Unicode sont restitués correctement, mais par exemple la paire de caractères \ '82 \ '82 devrait être autre chose? Je suppose que cela représente en fait un caractère à deux octets, qui était, pour une raison mystérieuse, codée sous la forme de deux caractères distincts plutôt que d'un seul caractère Unicode.

Existe-t-il un moyen générique (relativement) infaillible de prendre RTF contenant des langues orientales et de l'afficher de nouveau de manière fiable?

Par souci d’exhaustivité, j’ai mis à jour le tableau de polices RTF de la manière suivante:

        
  • Remplacement du nom de police "? l? r? o? S? V? b? N;" avec '\' 82 '' 6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \' 62 \ '83 \' 4e; ''
  • Mise à jour des noms de polices en remplaçant " \ froman \ fprq1 \ fcharset0 " avec "\ fnil \ fprq1 \ fcharset128"
  • Mise à jour des noms de police en remplaçant " \ froman \ fprq1 \ fcharset238 " avec "\ fnil \ fprq1 \ fcharset128"
  • Mise à jour des noms de police en remplaçant " \ froman \ fprq1 " avec "\ fnil \ fprq1 \ fcharset128"
  • Remplacement du nom de la police " ?? ?????; " avec '\' 82 '' 6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \' 62 \ '83 \' 4e; ''

Mise à jour: la mise à jour des noms de police ne fera pas une différence. La localisation semble être le gros problème. J'ai vu quelques sites discuter de solutions pour convertir l'affichage du format RTF japonais en quelque chose que la plupart des lecteurs accepteraient, mais je n'ai pas encore trouvé de solution, voir par exemple: ici et ici .

Était-ce utile?

La solution

Je suppose que la modification des noms de police dans le format RTF a probablement aggravé la situation. Si une police spécifiée dans le format RTF n'est pas une police Unicode, alors les caractères devant être rendus dans cette police seront codés en tant que Shift-JIS, pas en tant que Unicode. Et puis, les autres caractères du texte le seront aussi. Donc, traiter le tout comme Unicode, ou ajouter du texte Unicode, causera la corruption que vous voyez. Vous devez déterminer si le format RTF que vous importez est codé Shift-JIS ou Unicode, ainsi que si la machine sur laquelle vous travaillez (et donc le format d'entrée par défaut D2009) est japonaise ou non. Au Japon, si un fichier texte ne contient pas de nomenclature Unicode, il s’agit en général de Shift-JIS (mais pas toujours).

Autres conseils

Je voyais quelque chose de similaire, mais pas avec les polices japonaises. Juste des caractères spéciaux comme les micro (comme dans les microlitres) et les exposants. Le problème était que, même si la chaîne RTF que je transmettais à l'utilisateur à partir d'une page Web ASP.NET était correcte (je pouvais voir le flux RTF codé à l'aide de Fiddler2), lorsque MS Word avait ouvert le fichier RTF, il avait ajouté un tas d'ordures. codes comme ce que je vois dans votre échantillon.

Ce que j’ai fait est de passer tout le texte RTF dans une routine de conversion qui permute tous les caractères de l’ascii 127 en leurs équivalents de points Unicode spéciaux. Donc, je voudrais obtenir quelque chose comme \ uc1 \ u181? (micro) pour les caractères spéciaux. Quand j'ai fait cela, Word était capable d'ouvrir le fichier sans problème. Ironiquement, il a recodé le \ uc1 \ uxxx? retour à leur équivalent RTF échappé.

Private Function ConvertRtfToUnicode(ByVal value As String) As String

    Dim ch As Char() = value.ToCharArray()
    Dim c As Char
    Dim sb As New System.Text.StringBuilder()
    Dim code As Integer

    For i As Integer = 0 To ch.Length - 1
        c = ch(i)
        code = Microsoft.VisualBasic.AscW(c)
        If code <= 127 Then
            'Don't need to replace if one of your typical ASCII codes
            sb.Append(c)
        Else
            'MR: Basic idea came from here http://www.eggheadcafe.com/conversation.aspx?messageid=33935981&threadid=33935972
            '  swaps the character for it's Unicode decimal code point equivalent
            sb.Append(String.Format("\uc1\u{0:d}?", code))
        End If
    Next

    Return sb.ToString()

End Function

Je ne sais pas si cela aidera votre problème, mais cela fonctionne pour moi.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top