Come visualizzare correttamente i caratteri RTF giapponesi

Question

Sto lavorando a un'applicazione in Delphi 2009 che fa un uso intensivo di RTF, modificato con TRichEdit e TLMDRichEdit. Gli utenti che hanno inserito il testo giapponese in questi controlli RTF hanno inviato rapporti intermittenti sul testo giapponese visualizzato come incomprensibile quando si ricaricano i contenuti, sia su Win XP che su Vista, con Eastern Language Support installato.

Tipicamente, l'inglese e il giapponese sono misti e vengono principalmente visualizzati senza problemi, ad esempio:

Inventory turns partnerships.  在庫回転率の

(mi scuso se il testo giapponese non è corretto correttamente - non parlo né leggo la lingua).

Molto spesso, tuttavia, solo la parte giapponese del testo sarà incomprensibile, ad esempio:

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

Dall'estesa ricerca online, sembra che il problema sia dovuto ai caratteri salvati come parte dell'RTF. I caratteri presenti nella versione giapponese di Windows non corrispondono necessariamente a una versione inglese americana. È possibile sostituire a livello di codice i caratteri nel file RTF che produce un risultato quasi accettabile, ad esempio

-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 'di "spazzatura" personaggi che non sono correttamente riconosciuti come caratteri giapponesi. Guardando il RTF grezzo vedrai quanto segue:

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

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

Esiste un modo generico (relativamente) infallibile per utilizzare RTF contenenti le lingue orientali e visualizzarle nuovamente in modo affidabile?

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

    
• Sostituito il nome del carattere "? l? r? o? S? V? b? N; " con " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e; "
• Nomi dei font aggiornati sostituendo " \ froman \ fprq1 \ fcharset0 " con " \ fnil \ fprq1 \ fcharset128 "
• Nomi dei font aggiornati sostituendo " \ froman \ fprq1 \ fcharset238 " con " \ fnil \ fprq1 \ fcharset128 "
• Nomi dei font aggiornati sostituendo " \ froman \ fprq1 " con " \ fnil \ fprq1 \ fcharset128 "
• Sostituzione del nome del carattere " ?? ?????; " con " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e; "

Aggiornamento: l'aggiornamento dei nomi dei caratteri da soli non farà differenza. Il locale sembra essere il grosso problema. Ho visto alcuni siti discutere dei modi per convertire la visualizzazione del RTF giapponese in qualcosa che la maggior parte dei lettori potrebbe gestire, ma non ho ancora trovato una soluzione, vedi ad esempio: qui e qui .

Answer 1

La mia ipotesi è che cambiare i nomi dei caratteri nell'RTF abbia probabilmente peggiorato le cose. Se un carattere specificato in RTF non è un carattere Unicode, sicuramente i caratteri che devono essere renderizzati in quel carattere saranno codificati come Shift-JIS, non come Unicode. E poi anche gli altri personaggi nel testo. Quindi, trattando l'intera cosa come Unicode o aggiungendo il testo Unicode, causerai la corruzione che vedi. È necessario stabilire se RTF importato è codificato Shift-JIS o Unicode e anche se la macchina su cui si sta eseguendo (e quindi il formato di input predefinito D2009) è giapponese o no. In Giappone, se un file di testo non ha una distinta base Unicode, di solito sarebbe Shift-JIS (ma non sempre).

Answer 2

Stavo vedendo qualcosa di simile, ma non con i caratteri giapponesi. Solo caratteri speciali come micro (come nei microlitri) e apice. Il problema era che, sebbene la stringa RTF che stavo inviando all'utente da una pagina Web ASP.NET fosse corretta (ho potuto vedere il flusso RTF codificato usando Fiddler2), quando MS Word ha effettivamente aperto l'RTF, ha aggiunto un sacco di garbage escape codici come quello che vedo nel tuo esempio.

Quello che ho fatto è stato quello di eseguire l'intero testo RTF attraverso una routine di conversione che ha scambiato tutti i caratteri su ascii 127 con il loro speciale punto unicode equivalente. 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. Ironia della sorte, ha ricodificato la \ uc1 \ uxxx? tornando ai loro equivalenti di escape 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 ciò possa aiutare il tuo problema, ma funziona per me.