Como exibir corretamente japonês RTF fontes

Question

Eu estou trabalhando em um aplicativo em Delphi 2009 que faz uso pesado de RTF, editado usando TRichEdit e TLMDRichEdit. Os usuários que entraram texto em japonês nesses controles RTF foram envio de relatórios intermitentes sobre o texto em japonês que está sendo exibido como rabiscos quando recarregar o conteúdo, tanto em Win XP e Vista, com suporte de idioma Oriental instalado.

Normalmente, Inglês e Japonês é misturado e é mais exibido sem um problema, por exemplo:

Inventory turns partnerships.  在庫回転率の

(minhas desculpas se o texto em japonês é dividido de forma incorreta - eu não falar ou ler a língua).

Muito freqüentemente no entanto, apenas a parte japonesa do texto será jargão, por exemplo:

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

De extensa pesquisa on-line, parece que o problema é como resultado das fontes salvas como parte do RTF. Fontes presentes na versão do Windows idioma japonês não é necessariamente o mesmo que uma versão US Inglês. É possível substituir programaticamente as fontes no arquivo RTF que produz um resultado quase aceitável, i.

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

No entanto, ainda há muito poucos caracteres "lixo" em lá que não são correctamente reconhecidos como caracteres japoneses. Olhando para o RTF matéria, você verá o seguinte:

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

Claramente, os caracteres Unicode são processados ??corretamente, mas por exemplo, o par de caracteres \ '82 \ '82 deve ser algo mais? Meu palpite é que ele realmente representa um caractere de byte duplo de algum tipo, que foi por alguma razão misteriosa codificado como dois caracteres separados em vez de um único caractere Unicode.

Existe um genérico, (relativamente) infalível maneira de levar RTF contendo Línguas Orientais e confiável exibi-lo novamente?

Para sermos mais completos, eu atualizei tabela de fonte RTF da seguinte maneira:

• Substituído o nome da fonte "?? L r o S V b N;?????" com "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e";
• Atualizado nomes de fontes, substituindo "\ froman \ fprq1 \ fcharset0" com "\ fnil \ fprq1 \ fcharset128"
• Atualizado nomes de fontes, substituindo "\ froman \ fprq1 \ fcharset238" com "\ fnil \ fprq1 \ fcharset128"
• nomes de fontes actualizada mediante a substituição "\ froman \ fprq1" com "\ fnil \ fprq1 \ fcharset128"
• Substituir nome da fonte "?? ?????"; com "\ '82 \ '6c \ '82 \ '72 \ '82 \' 6f \ '83 \ '53 \ '83 \ '56 \ '83 \ '62 \ '83 \ '4e";

Update: nomes de fontes Atualização sozinho não vai fazer a diferença. O local parece ser o grande problema. Tenho visto alguns local discutindo maneiras em torno convertendo a exibição de japonês RTF a algo mais leitor iria lidar, mas eu não encontrei uma solução ainda, ver, por exemplo: aqui e aqui .

Answer 1

Meu palpite é que a mudança de nomes de fontes no RTF provavelmente piorou as coisas. Se uma fonte especificada no RTF não é uma fonte Unicode, então certamente os caracteres devido a ser processado em que fonte será codificado como Shift-JIS, não como Unicode. E então assim será a outros caracteres no texto. Portanto, tratar a coisa toda como Unicode, ou anexar texto Unicode, fará com que a corrupção você vê. Você precisa estabelecer se RTF você importação é codificado Shift-JIS ou Unicode, e também se a máquina estiver funcionando com (e, portanto, D2009 formato de entrada padrão) é japonês ou não. No Japão, se um arquivo de texto não tem Unicode BOM que normalmente seria Shift-JIS (mas nem sempre).

Answer 2

eu estava vendo algo semelhante, mas não com fontes japonesas. Apenas caracteres especiais como micro (como em microlitros) e sobrescritos. O problema foi que, embora a cadeia de RTF eu estava enviando para o usuário de uma página ASP.NET foi correta (eu podia ver o fluxo de RTF codificados usando Fiddler2), quando o MS Word realmente abriu o RTF, acrescentou um monte de fuga de lixo códigos como o que vejo em sua amostra.

O que fiz foi para executar todo o texto RTF através de uma rotina de conversão que trocou todos os caracteres mais de ascii 127 ao seu ponto unicode especial equivalente. Assim, gostaria de obter algo como \ uc1 \ u181? (Micro) para os caracteres especiais. Quando eu fiz isso, Word foi capaz de abrir o arquivo sem nenhum problema. Ironicamente, ele re-codificado o \ uc1 \ uxxx? de volta à sua RTF escapou equivalentes.

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

Não tenho certeza se isso vai ajudar o seu problema, mas ele está trabalhando para mim.