2009-05-01 21 views
5

Sto lavorando a un'applicazione in Delphi 2009 che fa un uso pesante di RTF, modificato usando TRichEdit e TLMDRichEdit. Gli utenti che hanno inserito il testo giapponese in questi controlli RTF hanno inviato report intermittenti sul testo giapponese visualizzato senza senso durante il ricaricamento del contenuto, sia su Windows XP che Vista, con il supporto per la lingua orientale installato.Come visualizzare correttamente i caratteri RTF giapponesi

Tipicamente, inglese e giapponese è misto e è in gran parte visualizzati senza un problema, ad esempio:

Inventory turns partnerships. 在庫回転率の 

(le mie scuse se il testo giapponese è rotto in modo errato - non parlo o leggere la lingua).

Molto spesso però, solo la parte giapponese del testo sarà senza senso, per esempio:

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

Da vasta ricerca on-line, sembra che il problema è il risultato dei font salvati come parte di l'RTF. I caratteri presenti nella versione in lingua giapponese di Windows non sono necessariamente gli stessi di una versione inglese negli Stati Uniti. E 'possibile sostituire a livello di codice i caratteri nel file RTF che produce un risultato quasi accettabile, vale a dire

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

Tuttavia, ci sono ancora un bel po' caratteri "spazzatura" in là che non sono riconosciuti correttamente come caratteri giapponesi. Guardando il RTF grezzo vedrete il seguente:

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

Chiaramente, i caratteri Unicode sono resi in modo corretto, ma per esempio la \ '82 \ '82 coppia di caratteri dovrebbe essere qualcosa d'altro? La mia ipotesi è che in realtà rappresenti un carattere a doppio byte di qualche tipo, che era per qualche misterioso motivo codificato come due caratteri separati piuttosto che un singolo carattere Unicode.

Esiste un modo generico (relativamente) infallibile per prendere RTF contenente lingue orientali e visualizzarlo in modo affidabile?

Per completezza, ho aggiornato la tabella di caratteri RTF nel modo seguente:

  • sostituito il nome del font "l r o S V b N;???????" con "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e;"
  • Aggiornato nomi dei caratteri, sostituendo "\ Froman \ fprq1 \ fcharset0" con "\ fnil \ fprq1 \ fcharset128"
  • Aggiornato nomi dei caratteri, sostituendo "\ Froman \ fprq1 \ fcharset238" con "\ fnil \ fprq1 \ fcharset128"
  • Aggiornato nomi dei caratteri, sostituendo "\ Froman \ fprq1" con "\ fnil \ fprq1 \ fcharset128"
  • sostituzione nome del font "?? ?????;" con "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e;"

Aggiornamento: Aggiornamento nomi dei font da solo non fanno la differenza. Il locale sembra essere il grosso problema. Ho visto alcuni siti che discutono su come convertire la visualizzazione di RTF giapponese in qualcosa che la maggior parte dei lettori gestirà, ma non ho ancora trovato una soluzione, per esempio: here e here.

+0

Se è coinvolta più di una libreria RTF, le diverse traduzioni da/verso RTF rappresentano un potenziale motivo. Se lo scrittore RTF emette un codice che il lettore non capisce, tutto è possibile. – mjn

+0

Nome font \ '82l \' 82r \ '82o \' 83S \ '83V \' 83b \ '83N è mostrato come '' MS PGothic'' quando aperto con Wordpad su Windows 10. Quando aperto con LibreOffice o con Wordpad su Win 7, è mostrato come ''MS P ゴ シ ッ ク''. – mjn

+0

Si noti che il nome del carattere? L? R? O? S? V? B? N; nella tua domanda sembra essere già corrotto, suppongo che sia \ 82l \ 82r \ '82o \' 83S \ '83V \' 83b \ '83N in uno stato precedente del documento. – mjn

risposta

1

La mia ipotesi è che la modifica dei nomi di carattere nell'RTF abbia probabilmente peggiorato le cose. Se un font specificato in RTF non è un font Unicode, sicuramente i caratteri che devono essere renderizzati in quel font saranno codificati come Shift-JIS, non come Unicode. E così saranno gli altri personaggi nel testo. Quindi trattare l'intero oggetto come Unicode, o accodare il testo Unicode, causerà la corruzione che vedi. È necessario stabilire se l'RTF importato è codificato da Shift-JIS o Unicode e anche se la macchina su cui si sta eseguendo (e quindi il formato di input predefinito di D2009) è giapponese o meno. In Giappone, se un file di testo non ha BOM Unicode, di solito è Shift-JIS (ma non sempre).

+1

Ulteriori indagini hanno dimostrato che cambiare il font non è una buona idea. In particolare, la modifica del set di caratteri specificato è un no-no, poiché \ fcharset0 è ANSI e \ fcharset128 è Shift-JIS. Almeno sulla superficie, sembra che scambiare tra diversi tipi di carattere con diversi set di caratteri consentirebbe di codificare correttamente ciò che l'utente ha inserito. Sfortunatamente, non spiega ancora perché il controllo RTF non sia in grado di capire la visualizzazione corretta. – Ryan

1

Stavo vedendo qualcosa di simile, ma non con caratteri giapponesi. Solo personaggi speciali come micro (come in microlitri) e apici. Il problema era che anche se la stringa RTF che stavo mandando all'utente da una pagina Web ASP.NET era corretta (potevo vedere il flusso RTF codificato usando Fiddler2), quando MS Word in realtà apriva l'RTF, aggiungeva un sacco di escape codici come quello che vedo nel tuo campione.

Quello che ho fatto è stato eseguire l'intero testo RTF attraverso una routine di conversione che ha scambiato tutti i caratteri su ASCII 127 con il loro equivalente punto unicode speciale. Quindi vorrei ottenere qualcosa come \ uc1 \ u181? (micro) per i caratteri speciali. Quando l'ho fatto, Word è stato in grado di aprire il file senza problemi. Ironicamente, ha ricodificato il \ uc1 \ uxxx? torna ai loro equivalenti evitati da 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 

Non sono sicuro che questo aiuterà il problema, ma funziona per me.

+0

Grazie per il codice di esempio! Ho provato inizialmente qualcosa di simile, ma non ha fatto alcuna differenza in quanto il flusso di caratteri RTF stesso non conteneva alcun Unicode. Questa è comunque una funzione estremamente utile da tenere in giro. – Ryan

Problemi correlati