Cómo mostrar correctamente las fuentes RTF japonesas

Question

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

Típicamente, Inglés y japonés se mezcla y se muestra sobre todo sin ningún problema, por ejemplo:

Inventory turns partnerships. 在庫回転率の 

(mis disculpas si el texto en japonés se rompe de forma incorrecta - no hablo o leer el idioma).

Muy embargo con frecuencia, sólo la parte japonesa del texto será un galimatías, por ejemplo:

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

De extensa búsqueda en línea, parece que el problema es como resultado de las fuentes guardadas como parte de el 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 EE. UU. 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 un buen número de caracteres "basura" de allí que no son reconocidos correctamente como caracteres japoneses. En cuanto a la RTF prima que va a ver lo siguiente:

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

Claramente, los caracteres Unicode se procesan correctamente, pero por ejemplo el \ '82 \ '82 par de caracteres deben ser otra cosa? Supongo que en realidad representa un carácter de doble byte de algún tipo, que fue por alguna razón misteriosa codificada como dos caracteres separados en lugar de un único carácter Unicode.

¿Existe una manera genérica (relativamente) infalible de tomar RTF que contenga idiomas orientales y volver a mostrarlo de manera confiable?

Por el bien exhaustividad, actualiza la tabla de fuentes RTF de la siguiente manera:

• reemplazado 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;"
• Actualizado nombres de fuentes mediante la sustitución de "\ froman \ fprq1 \ fcharset0" con "\ fnil \ fprq1 \ fcharset128"
• Actualizado nombres de fuentes mediante la sustitución de "\ froman \ fprq1 \ fcharset238" con "\ fnil \ fprq1 \ fcharset128"
• Actualizado nombres de fuentes mediante la sustitución de "\ froman \ fprq1" con "\ fnil \ fprq1 \ fcharset128"
• sustitución de nombre de la fuente "?? ?????;" con "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e;"

Actualizar: Actualización de nombres de fuentes solamente no hacen la diferencia. La ubicación parece ser el gran problema. He visto algunos sitios discutiendo formas de convertir la pantalla del RTF japonés a algo que la mayoría de los lectores manejarían, pero todavía no he encontrado una solución, ver por ejemplo: here y here.

Answer 1

Supongo que cambiar los nombres de las fuentes en el RTF probablemente haya empeorado las cosas. Si una fuente especificada en el RTF no es una fuente Unicode, entonces seguramente los caracteres que se renderizarán en esa fuente se codificarán como Shift-JIS, no como Unicode. Y luego también lo harán los otros personajes en el texto. Así que tratar todo el asunto como Unicode, o al agregar texto Unicode, causará la corrupción que ve. Debe establecer si el RTF que importa está codificado 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 D2009) es japonés o no. En Japón, si un archivo de texto no tiene una lista de materiales Unicode, por lo general 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 RTF codificada usando Fiddler2), cuando MS Word realmente abrió el RTF, agregó un montón 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 en ascii 127 a su equivalente de punto unicode especial. ¿Entonces obtendría algo como \ uc1 \ u181? (micro) para los personajes especiales. Cuando lo hice, Word no pudo abrir el archivo. Irónicamente, ¿volvió a codificar el \ uc1 \ uxxx? de vuelta a sus equivalentes escapados 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 

No estoy seguro si eso ayudará con su problema, pero me funciona.