Wie man richtig japanische RTF Schriftarten angezeigt

Question

ich auf einer Anwendung in Delphi 2009 arbeitet, die starke Nutzung von RTF macht, bearbeiten TRichEdit und TLMDRichEdit verwenden. Benutzer, die japanischen Text in diesen RTF Kontrollen eingegeben wurden Einreichung intermittierenden Berichte über den japanischen Text als Kauderwelsch angezeigt wird, wenn der Inhalt neu zu laden, sowohl auf Windows XP und Vista, mit Eastern Sprachunterstützung installiert.

Normalerweise, Englisch und Japanisch wird gemischt und wird meist ohne ein Problem angezeigt, zum Beispiel:

Inventory turns partnerships.  在庫回転率の

(ich entschuldige mich, wenn die japanischen Text falsch gebrochen - ich spreche nicht oder lesen Sie die Sprache).

Ganz jedoch häufig nur der japanische Teil des Textes wird Kauderwelsch sein, zum Beispiel:

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

Von umfangreicher Online-Suche, scheint es, dass das Problem ist, als Ergebnis der gespeicherten Schriftart als Teil der RTF. Fonts, die auf dem japanischen Sprachversion von Windows ist nicht unbedingt das gleiche wie eine US-Version. Es ist möglich, programmatisch die Schriftarten in der RTF-Datei zu ersetzen, die ein fast akzeptables Ergebnis ergibt, d.

-D‚‚ｽƒIƒyƒŒ[ƒVƒ・“‚ﾆƒƒWƒXƒeƒBƒbƒN‚ﾌƒpƒtƒH[ƒ}ƒ“ƒX‚-˜‰v‚ﾉŒ‹‚ﾑ‚ﾂ‚ｯ‚ﾈ‚｢‚±ﾆ‚ﾍ?A‘‚｢‚ﾉ-ｳ‘ﾊ‚ﾅ‚ ‚驕B‚ｻ‚‚ﾍAl“ｾ‚ｵ‚ｽ・‘P‚ﾌˆﾛ‚ƒƒXƒN‚ﾉ‚ｳ‚‚ｷB

Allerdings gibt es immer noch einige „Junk“ Zeichen dort in der als japanische Zeichen nicht richtig erkannt werden. Mit Blick auf die rohen RTF Sie werden sehen, wie folgt vor:

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

Selbstverständlich werden die Unicode-Zeichen korrekt dargestellt, aber zum Beispiel des \ '82 \ '82 Zeichenpaar sollte etwas anderes sein? Meine Vermutung ist, dass es tatsächlich ein Double-Byte-Zeichen irgendeiner Art darstellt, die aus unerfindlichen Gründen als zwei getrennte Zeichen eher als ein einzelnes Unicode-Zeichen codiert wurde.

Gibt es einen generischen, (relativ) narrensicheren Weg RTF zu nehmen Eastern Sprachen enthält, und es zuverlässig Anzeige wieder?

Der Vollständigkeit halber habe ich die RTF-Schriftart-Tabelle in der folgenden Art und Weise aktualisiert:

    
• ersetzt den Namen der Schriftart "l r o S V b N;??????" mit "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6F \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e;"
• Aktualisiert Font-Namen durch Ersetzen "\ froman \ fprq1 \ fcharset0" mit "\ fnil \ fprq1 \ fcharset128"
• Aktualisiert Font-Namen durch Ersetzen "\ froman \ fprq1 \ fcharset238" mit "\ fnil \ fprq1 \ fcharset128"
• Aktualisiert Font-Namen durch Ersetzen "\ froman \ fprq1" mit "\ fnil \ fprq1 \ fcharset128"
• Ersetzen Schriftname "?? ?????;" mit "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6F \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e;"

Update: Aktualisieren von Font-Namen allein nicht einen Unterschied machen. Das Gebietsschema scheint das große Problem zu sein. Ich habe ein paar Website gesehen Möglichkeiten, um die Umwandlung die Anzeige von japanischer RTF zu etwas, die meisten Leser würden behandeln zu diskutieren, aber ich habe keine Lösung noch, siehe zum Beispiel gefunden: hier und hier .

Answer 1

Meine Vermutung ist, dass in der RTF-Font-Namen zu ändern wahrscheinlich alles noch schlimmer gemacht hat. Wenn eine Schriftart in den RTF angegebenen keine Unicode-Schriftart ist, dann sicher die Zeichen aufgrund in dieser Schrift dargestellt werden als Shift-JIS kodiert wird, nicht als Unicode. Und dann so werden die anderen Zeichen im Text. So behandelt die ganze Sache als Unicode oder Unicode-Text angehängt, bewirkt, dass die Korruption Sie sehen. Sie müssen feststellen, ob RTF Import verschlüsselte Shift-JIS oder Unicode, und auch, ob die Maschine, die Sie auf ausgeführt werden (und damit D2009 Standardeingabeformat) ist Japanisch oder nicht. In Japan, wäre es in der Regel, wenn eine Textdatei keine Unicode BOM hat sein Shift-JIS (aber nicht immer).

Answer 2

ich sah etwas Ähnliches, aber nicht mit japanischen Schriften. Nur Sonderzeichen wie Mikro (wie in & mgr; l) und Indizes. Das Problem war, dass, obwohl der RTF-String wurde ich von einer ASP.NET-Webseite an den Benutzer zu senden korrekt war (ich konnte den codierten RTF-Stream unter Verwendung von Fiddler2 sehen), wenn MS Word tatsächlich die RTF geöffnet, fügte sie einen Haufen Müll Flucht Codes wie das, was ich in der Probe zu sehen.

Was ich tat, war den gesamten RTF-Text durch eine Konvertierungsroutine auszuführen, die alle Zeichen über ascii 127 ihren speziellen Unicode-Punkt gleichwertig getauscht. So würde ich so etwas wie \ uc1 \ U181 bekommen? (Mikro) für die Sonderzeichen. Als ich das tat, war Wort der Lage, die Datei kein Problem zu öffnen. Ironischerweise neu codiert die \ uc1 \ Uxxx? zurück in ihre RTF-Äquivalente entkommen.

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

Nicht sicher, ob das Ihr Problem helfen, aber es funktioniert für mich.