質問

私はDelphi 2009で、TRichEditとTLMDRichEditを使用して編集されたRTFを多用するアプリケーションに取り組んでいます。これらのRTFコントロールに日本語テキストを入力したユーザーは、Win XPとVistaの両方で、東部言語サポートがインストールされているコンテンツをリロードするときに、日本語テキストがちらつきとして表示されるという断続的なレポートを送信しています。

通常、英語と日本語は混在しており、ほとんど問題なく表示されます。例:

Inventory turns partnerships.  在庫回転率の

(日本語のテキストが間違って壊れている場合は謝罪-私は言語を話さないか、読んでいない)。

ただし、かなり頻繁に、テキストの日本語部分のみが意味不明になります。例:

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

広範なオンライン検索から、問題はRTFの一部として保存されたフォントの結果であると思われます。日本語版のWindowsに存在するフォントは、必ずしも米国英語版と同じではありません。 RTFファイル内のフォントをプログラムで置き換えることができます。これにより、ほぼ受け入れられる結果が得られます。つまり、

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

ただし、まだかなりの数の「ジャンク」があります。日本語の文字として正しく認識されていない文字。生のRTFを見ると、次のように表示されます。

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

明らかに、Unicode文字は正しくレンダリングされますが、たとえば、\ '82 \ '82の文字のペアは別のものにすべきでしょうか?私の推測では、実際にはある種のダブルバイト文字を表しているのですが、これは何らかの謎の理由で、単一のUnicode文字ではなく2つの別々の文字としてエンコードされたものです。

東部言語を含むRTFを取得し、確実に再表示する一般的で(比較的)確実な方法はありますか?

完全を期すために、RTFフォントテーブルを次のように更新しました。

        
  • フォント名を置き換えました"?l?r?o?S?V?b?N;" " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e;"
  • " \ froman \ fprq1 \ fcharset0"を置き換えることでフォント名を更新" \ fnil \ fprq1 \ fcharset128"
  • " \ froman \ fprq1 \ fcharset238"を置き換えることでフォント名を更新" \ fnil \ fprq1 \ fcharset128"
  • " \ froman \ fprq1"を置き換えてフォント名を更新" \ fnil \ fprq1 \ fcharset128"
  • フォント名の置き換え" ?? ?????;" " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e;"

更新:フォント名のみを更新しても違いはありません。ロケールが大きな問題のようです。日本語のRTFの表示をほとんどの読者が処理できるものに変換する方法を議論しているサイトを見たことがありますが、解決策はまだ見つかりません。たとえば、 こちらおよびこちら

役に立ちましたか?

解決

私の推測では、RTFのフォント名を変更すると事態が悪化する可能性があります。 RTFで指定されたフォントがUnicodeフォントではない場合、そのフォントでレンダリングされる予定の文字は、UnicodeではなくShift-JISでエンコードされます。そして、テキスト内の他の文字も同様です。そのため、全体をUnicodeとして扱うか、Unicodeテキストを追加すると、破損が発生します。インポートするRTFがエンコードされたShift-JISまたはUnicodeであるかどうか、また実行しているマシン(したがってD2009のデフォルトの入力形式)が日本語かどうかを確認する必要があります。日本では、テキストファイルにUnicode BOMがない場合、通常はShift-JISになります(常にではありません)。

他のヒント

似たようなものが見られましたが、日本語フォントでは見られませんでした。マイクロ(マイクロリットルなど)や上付き文字などの特殊文字。問題は、ASP.NET Webページからユーザーに送信したRTF文字列が正しいにもかかわらず(Fiddler2を使用してエンコードされたRTFストリームを見ることができた)、MS Wordが実際にRTFを開いたときに、大量のガベージエスケープが追加されたことでしたサンプルに表示されるようなコード。

私がやったのは、ASCII上のすべての文字を同等の特別なユニコードポイントに交換する変換ルーチンを通して、RTFテキスト全体を実行することでした。だから私は\ uc1 \ u181のようなものを手に入れるでしょうか? (マイクロ)特殊文字用。私がそれをしたとき、Wordはファイルを問題なく開くことができました。皮肉なことに、\ uc1 \ uxxxを再エンコードしましたか? RTFエスケープされた同等のものに戻ります。

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

それがあなたの問題に役立つかどうかはわかりませんが、それは私のために働いています。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top