Cómo mostrar correctamente las fuentes japonesas RTF

Question

Estoy trabajando en una aplicación en Delphi 2009 que hace un uso intensivo de RTF, editada con TRichEdit y TLMDRichEdit. Los usuarios que ingresaron el texto en japonés en estos controles RTF han estado enviando informes intermitentes sobre el texto en japonés que se muestra como una tontería cuando se vuelve a cargar el contenido, tanto en Win XP como en Vista, con la compatibilidad con Eastern Language instalado.

Por lo general, el inglés y el japonés se mezclan y se muestran principalmente sin problemas, por ejemplo:

Inventory turns partnerships.  在庫回転率の

(pido disculpas si el texto en japonés está roto incorrectamente, no hablo ni leo el idioma).

Sin embargo, con bastante frecuencia, solo la parte japonesa del texto será incomprensible, por ejemplo:

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

A partir de una extensa búsqueda en línea, parece que el problema se debe a las fuentes guardadas como parte del RTF. Las fuentes presentes en la versión en japonés de Windows no son necesariamente las mismas que las versiones en inglés de Estados Unidos. Es posible reemplazar mediante programación las fuentes en el archivo RTF que produce un resultado casi aceptable, es decir,

-D‚‚ｽƒIƒyƒŒ[ƒVƒ・“‚ﾆƒƒWƒXƒeƒBƒbƒN‚ﾌƒpƒtƒH[ƒ}ƒ“ƒX‚-˜‰v‚ﾉŒ‹‚ﾑ‚ﾂ‚ｯ‚ﾈ‚｢‚±ﾆ‚ﾍ?A‘‚｢‚ﾉ-ｳ‘ﾊ‚ﾅ‚ ‚驕B‚ｻ‚‚ﾍAl“ｾ‚ｵ‚ｽ・‘P‚ﾌˆﾛ‚ƒƒXƒN‚ﾉ‚ｳ‚‚ｷB

Sin embargo, todavía hay bastantes " basura " Los caracteres allí que no se reconocen correctamente como caracteres japoneses. Mirando el RTF en bruto verá lo siguiente:

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

Claramente, los caracteres Unicode se representan correctamente, pero, por ejemplo, ¿el par de caracteres \ '82 \ '82 debería ser otra cosa? Supongo que en realidad representa un carácter de doble byte de algún tipo, que por alguna razón misteriosa se codificó como dos caracteres separados en lugar de un solo carácter Unicode.

¿Existe una forma genérica (relativamente) infalible de tomar RTF que contenga Eastern Languages ??y mostrarlo de nuevo de manera confiable?

Para completar, actualicé la tabla de fuentes RTF de la siguiente manera:

    
• Reemplazó el nombre de la fuente "? l? r? o? S? V? b? N; " con " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e; "
• Nombres de fuente actualizados al reemplazar " \ froman \ fprq1 \ fcharset0 " con " \ fnil \ fprq1 \ fcharset128 "
• Se actualizaron los nombres de las fuentes al reemplazar " \ froman \ fprq1 \ fcharset238 " con " \ fnil \ fprq1 \ fcharset128 "
• Nombres de fuente actualizados al reemplazar " \ froman \ fprq1 " con " \ fnil \ fprq1 \ fcharset128 "
• Reemplazando el nombre de la fuente " ?? ?????; " con " \ '82 \' 6c \ '82 \ '72 \ '82 \ '6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \' 4e; "

Actualización: la actualización de los nombres de las fuentes solo no hará una diferencia. El local parece ser el gran problema. He visto algunos sitios en los que se analiza cómo convertir la pantalla del RTF japonés en algo que la mayoría de los lectores manejaría, pero aún no he encontrado una solución, vea por ejemplo aquí y aquí .

Answer 1

Mi conjetura es que cambiar los nombres de las fuentes en el RTF probablemente ha empeorado las cosas. Si una fuente especificada en el RTF no es una fuente Unicode, seguramente los caracteres que se deben representar en esa fuente se codificarán como Shift-JIS, no como Unicode. Y entonces también lo harán los otros personajes en el texto. Por lo tanto, tratar todo el asunto como Unicode, o agregar texto Unicode, causará la corrupción que se ve. Debe establecer si el RTF que importa está codificado como Shift-JIS o Unicode, y también si la máquina en la que está ejecutando (y, por lo tanto, el formato de entrada predeterminado de D2009) es japonés o no. En Japón, si un archivo de texto no tiene una lista de materiales de Unicode, normalmente sería Shift-JIS (pero no siempre).

Answer 2

Estaba viendo algo similar, pero no con fuentes japonesas. Solo caracteres especiales como micro (como en microlitros) y superíndices. El problema era que aunque la cadena RTF que estaba enviando al usuario desde una página web ASP.NET era correcta (podía ver la secuencia codificada de RTF con Fiddler2), cuando MS Word realmente abrió el RTF, agregó un montón de escape de basura Códigos como lo que veo en tu muestra.

Lo que hice fue ejecutar todo el texto RTF a través de una rutina de conversión que cambió todos los caracteres sobre ascii 127 a su equivalente de punto de Unicode especial. ¿Entonces obtendría algo como \ uc1 \ u181? (micro) para los caracteres especiales. Cuando hice eso, Word fue capaz de abrir el archivo sin ningún problema. Irónicamente, ¿recodificó el \ uc1 \ uxxx? De vuelta a sus equivalentes de RTF escapados.

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

No estoy seguro de si eso ayudará con tu problema, pero está funcionando para mí.