0

サーバーから返されたRTFを解析しようとしています。ほとんどのテキストでは、これで問題なく動作します (RichTextBox コントロールを使用するとうまくいきます) が、一部の RTF には追加の「エンコード」が含まれているようで、一部の文字が破損しています。

元の文字列は次のとおりです (ポーランド語で使用される文字の一部が含まれています)。

ąćęłńóśźż

送り返される 16 進数でエンコードされた文字を含む RTF 文字列は次のようになります。

{\lang1045\langfe1045\f16383 {\'b9\'e6\'ea\'b3{\f7 \'a8\'bd\'a8\'ae}\'9c\'9f\'bf}}

返された文字列のńó文字のデコードに問題があります。文字列はそれぞれ 2 つの 16 進数値で表されているようですが、残りの文字列は (予想どおり) 1 つの 16 進数値で表されています。

RichTextBox コントロールを使用して RTF を "解析" すると、テキストが破損します (問題の 2 つの文字が 4 つの不要な文字として表示されます)。

予想されるコードページ (1250、Latin 2、lcid 1045 の ANSI コードページ) を使用してプレーン文字列を自分で 16 進数にエンコードすると、次のようになります。

\'B9\'E6\'EA\'B3\'F1\'F3\'9C\'9F\'BF

ńóに対応する返された文字列の{\f7 \'a8\'bd\'a8\'ae}部分を正しくデコードする方法がわかりません。

RTF ヘッダーには\f7のフォント定義がなく、サーバー上で直接表示すると文字列が正常に見えることに注意してください。これは、送信前の変換のどこかで文字 (文字が壊れている場合) が壊れていることを意味します。

問題がサーバー側にあるかどうかはわかりませんが (私はそれを制御できないため)、サーバーは多くの翻訳作業に使用されるため、返された文字列は問題ないと思います。

私は RTF 仕様を調べてきましたが、このタイプのエンコーディングの組み合わせに関するヒントを見つけることができません。

4

1 に答える 1

1

原因はわかりませんが、エンコーディングはGBK (または十分に類似したもの) のようです。

おそらく、サーバーは文字を見つけるために「巧妙な」マッチングを実行しようとするか、サーバーのデフォルトの文字エンコーディングが GBK 程度であり、それらの文字 (およびそれらのみ) も GBK で発生するため、それを優先します。

問題のある 16 進コード ( A8 BD A8 AE) を単純な HTML ファイルにバイトとして追加することで発見したので、ブラウザのエンコーディングを調べて、何かが一致するかどうかを確認できました。

<html><body>¨½¨®</body></html>

驚いたことに、私のブラウザはすぐに "ńó" を表示しました。

于 2009-01-30T23:58:33.407 に答える