2009-05-01 28 views
5

我工作的德爾福2009年,這使得RTF的大量使用的應用程序,使用TRichEdit和TLMDRichEdit編輯。誰進入這些RTF控件日本文字用戶已經提交有關日本的文本間歇報告重裝安裝的內容,無論是在Win XP和Vista,與東方語言支持時顯示爲亂碼。如何正確地顯示日本RTF字體

通常,英語和日語的混合沒有問題大多顯示,例如:

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字符。

是否有一個通用的,(相對)萬無一失採取RTF包含東方語言和可靠地再次顯示它的方式?

爲了完整性起見,我更新RTF字體表以如下方式:

  • 替換的字體名稱 「L R■解讀V B n的;???????」用 「\ '82 \ '6C \ '82 \ '72 \ '82 \' 1207 \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \'4E;」
  • 通過更換更新的字體名稱 「\弗羅曼\ fprq1 \ fcharset0」 與 「\ fnil \ fprq1 \ fcharset128」
  • 更新的字體替換名 「\弗羅曼\ fprq1 \ fcharset238」 與 「\ fnil \ fprq1 \ fcharset128」
  • 將「\ froman \ fprq1」替換爲「\ fnil \ fprq1 \ fcharset128」更新的字體名稱
  • 替換字體名稱「?? ?????;」用 「\ '82 \ '6C \ '82 \ '72 \ '82 \' 1207 \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \'4E;」

更新:更新單獨的字體名稱不會有所作爲。現場似乎是一個大問題。我看到了幾個網站討論圍繞日本RTF的顯示轉換的東西大多數讀者會處理的方式,但我還沒有找到一個解決辦法,例如參見: herehere

+0

如果涉及多個RTF庫,則從/到RTF的不同轉換是潛在的原因。如果RTF編寫器發出讀者不理解的代碼,那麼一切都是可能的。 – mjn 2017-06-02 18:48:16

+0

當在Windows 10上用寫字板打開時,字體名稱'82l''82r''82o''83S''83V''83b''83N顯示爲'MS PGothic'。用LibreOffice打開或用寫字板Win 7,它顯示爲「MS Pゴシック」。 – mjn 2017-06-02 18:52:43

+0

請注意,字體名稱?l?r?o?S?V?b?N;在你的提問中似乎已經是腐敗了,我想在文件的前一個狀態中它是'82''82''83''83''83b''83 N. – mjn 2017-06-02 18:53:58

回答

1

我的猜測是,更改RTF中的字體名稱可能使事情變得更糟。如果在RTF中指定的字體不是Unicode字體,那麼肯定應該以該字體呈現的字符將被編碼爲Shift-JIS,而不是Unicode。然後文本中的其他字符也會如此。因此,將整個事物視爲Unicode,或附加Unicode文本,都會導致您看到的損壞。您需要確定您導入的RTF是否編碼爲Shift-JIS或Unicode,以及您正在運行的機器(因此D2009默認輸入格式)是否爲日文。在日本,如果文本文件沒有Unicode BOM,它通常是Shift-JIS(但不總是)。

1

我看到類似的東西,但沒有與日文字體。只有特殊字符如微(如微升)和上標。問題是即使我從ASP.NET網頁發送給用戶的RTF字符串是正確的(我可以看到使用Fiddler2編碼的RTF流),但是當MS Word實際打開RTF時,它添加了一堆垃圾轉義代碼就像我在你的示例中看到的一樣。

我所做的就是通過轉換例程來運行整個RTF文本,該例程將ascii 127上的所有字符換成其特殊的unicode點等價物。所以我會得到像\ 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 

不知道這是否會幫助你的問題,但它對我有用。