5


2

私はTRichEditとTLMDRichEditを使用して編集されたRTFを多用するDelphi 2009でアプリケーションに取り組んでいます。 これらのRTFコントロールに日本語のテキストを入力したユーザーは、Windows XPとVistaの両方で、Eastern Language Supportがインストールされた状態で、コンテンツをリロードするときに日本語のテキストが曖昧に表示されるという断続的なレポートを提出しています。

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

在庫がパートナーシップを変える 在庫回転率の

(日本語のテキストが誤って壊れている場合は申し訳ありません。私は話したり読んだりしません)。

ただし、ごく頻繁に、テキストの日本語部分だけがぎこちなくなります。次に例を示します。

?]??????????????????????????????????????????????? - ?????? (マーケットセクター、見込み客の優先順位と一緒に販売する知識)

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

-Dは………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………? 「………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………」

しかし、そこにはまだかなりの数の「ジャンク」文字があり、それらは日本語の文字として正しく認識されていません。 生のRTFを見ると、次のようになるでしょう。

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

明らかに、Unicode文字は正しくレンダリングされますが、例えば\ '82 \' 82文字の組は別のものになりますか? 私の推測では、それは実際にはある種のダブルバイト文字を表しています。これは、何らかの不思議な理由から、1つのUnicode文字ではなく2つの別々の文字としてエンコードされていました。

Eastern Languagesを含むRTFを使用して確実に再表示するための一般的な(比較的)絶対確実な方法はありますか?

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

  • フォント名「?l?r?o?S?V?b?N;」を置き換えました。 "\ '82 \ '6c \ '82 \ '72 \ '82 \ '82 \ '82 \ '83 \ '53 \ '83 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e;を含む

  • 「\ froman \ fprq1 \ fcharset0」を「\ fnil \ fprq1 \ fcharset128」に置き換えてフォント名を更新

  • 「\ froman \ fprq1 \ fcharset238」を「\ fnil \ fprq1 \ fcharset128」に置き換えてフォント名を更新

  • 「\ froman \ fprq1」を「\ fnil \ fprq1 \ fcharset128」に置き換えてフォント名を更新

  • フォント名を置き換えます "with" \ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ ' 4e;」

更新:フォント名だけを更新しても効果はありません。 ロケールは大きな問題のようです。 私は、日本語RTFの表示を読者が扱うものに変換する方法を議論しているサイトをいくつか見たことがありますが、解決策がまだ見つかっていません。例えば、http://bbs.wankuma.com/index.cgi? mode = al2

2 Answer


1


RTFでフォント名を変更すると、おそらく状況が悪化すると私は思います。 RTFで指定されたフォントがUnicodeフォントではない場合、そのフォントでレンダリングされる予定の文字は、UnicodeではなくShift-JISとしてエンコードされます。 そして、テキスト中の他の文字もそうです。 したがって、すべてをUnicodeとして扱う、またはUnicodeテキストを追加すると、破損が発生します。 インポートするRTFがShift-JISまたはUnicodeのどちらでエンコードされているのか、および実行しているマシン(したがってD2009のデフォルト入力フォーマット)が日本語であるのかどうかを確認する必要があります。 日本では、テキストファイルにUnicode BOMがない場合、通常はShift-JISになります(ただし必ずしもそうとは限りません)。


1


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

私がしたことは、ASCII 127上のすべての文字を、それに相当する特別なUnicodeポイントに交換する変換ルーチンを介して、RTFテキスト全体を実行することでした。 だから私は\ uc1 \ u181のようなものを得るだろうか? 特殊文字の場合は(マイクロ)。 私がそうしたとき、Wordは問題なくファイルを開くことができました。 皮肉なことに、それは\ uc1 \ uxxxを再エンコードしましたか? RTFのエスケープした同等の機能に戻ります。

文字列としてのプライベート関数ConvertRtfToUnicode(文字列としてのByVal値)

Charとしてのディム()= value.ToCharArray()Charとしてのディムcsとしてのディムsb新しいSystem.Text.StringBuilder()としてのディムコード整数としてのディムコード

整数の場合= 0整数= 0の場合ch =長さ1の場合c = ch(i)code = Microsoft.VisualBasic.AscW(c)code <= 127の場合それから 'あなたの典型的なASCIIコードの1つであれば置き換える必要はありません付録(c)その他MR:基本的な考えはここから来ましたhttp://www.eggheadcafe.com/conversation.aspx?messageid=33935981

sb.ToString()を返します。

終了機能

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