Вопрос

Я работаю над приложением в Delphi 2009, в котором интенсивно используется RTF, редактируемый с помощью TRichEdit и TLMDRichEdit.Пользователи, вводившие текст на японском языке в эти элементы управления RTF, периодически отправляли отчеты о том, что японский текст отображается как тарабарщина при перезагрузке контента как в Win XP, так и в Vista с установленной поддержкой восточного языка.

Обычно английский и японский смешаны и в большинстве случаев отображаются без проблем, например:

Inventory turns partnerships.  在庫回転率の

(приношу извинения, если текст на японском языке неправильно написан — я не говорю и не читаю на этом языке).

Однако довольно часто только японская часть текста будет тарабарщиной, например:

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

Из обширного поиска в Интернете выяснилось, что проблема связана со шрифтами, сохраненными как часть RTF.Шрифты, присутствующие в японской версии Windows, не обязательно совпадают с английской версией в США.Можно программно заменить шрифты в RTF-файле, что дает почти приемлемый результат, т.е.

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

Однако там все еще есть довольно много «мусорных» символов, которые неправильно распознаются как японские символы.Посмотрев на необработанный RTF, вы увидите следующее:

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

Очевидно, что символы Юникода отображаются правильно, но, например, пара символов \'82\'82 должна быть чем-то другим?Я предполагаю, что на самом деле он представляет собой какой-то двухбайтовый символ, который по какой-то загадочной причине был закодирован как два отдельных символа, а не как один символ Юникода.

Существует ли общий (относительно) надежный способ взять RTF, содержащий восточные языки, и снова надежно отобразить его?

Для полноты картины я обновил таблицу шрифтов RTF следующим образом:

  • Заменил имя шрифта "? L? R? O? S? V? B? N;" с " '82 '6c '82 '72 '82 ' 6f '83 '53 '83 '56 '83 '62 '83 '4e;"
  • Обновлены имена шрифтов путем замены «\froman\fprq1\fcharset0» на «\fnil\fprq1\fcharset128».
  • Обновлены имена шрифтов путем замены «\froman\fprq1\fcharset238» на «\fnil\fprq1\fcharset128».
  • Обновлены имена шрифтов путем замены «\froman\fprq1» на «\fnil\fprq1\fcharset128».
  • Замена имени шрифта "????????;" с "\'82\'6c\'82\'72\'82\'6f\'83\'53\'83\'56\'83\'62\'83\' 4е;»

Обновлять:Одно лишь обновление названий шрифтов не будет иметь никакого значения.Локаль кажется большой проблемой.Я видел несколько сайтов, на которых обсуждались способы преобразования отображения японского RTF в то, с чем справится большинство читателей, но я еще не нашел решения, см., например:здесь и здесь.

Это было полезно?

Решение

Я предполагаю, что изменение названий шрифтов в RTF, вероятно, ухудшило ситуацию.Если шрифт, указанный в RTF, не является шрифтом Unicode, то символы, которые должны отображаться в этом шрифте, будут закодированы как Shift-JIS, а не как Unicode.А затем и другие персонажи текста.Таким образом, обработка всего этого как Unicode или добавление текста в Unicode приведет к повреждению, которое вы видите.Вам необходимо установить, кодируется ли импортируемый вами RTF Shift-JIS или Unicode, а также является ли компьютер, на котором вы работаете (и, следовательно, формат ввода по умолчанию D2009), японским или нет.В Японии, если текстовый файл не имеет спецификации Unicode, это обычно будет Shift-JIS (но не всегда).

Другие советы

Я видел нечто подобное, но не с японскими шрифтами.Только специальные символы, такие как микро (как в микролитрах) и надстрочные индексы.Проблема заключалась в том, что, хотя строка RTF, которую я отправлял пользователю с веб-страницы ASP.NET, была правильной (я мог видеть закодированный поток RTF с помощью Fiddler2), когда MS Word фактически открывал RTF, он добавлял кучу экранирования мусора. коды, подобные тем, что я вижу в вашем образце.

Что я сделал, так это прогнал весь текст RTF через процедуру преобразования, которая заменила все символы ascii 127 на их специальный эквивалент точки Юникода.Итак, я получу что-то вроде \uc1\u181?(микро) для специальных символов.Когда я это сделал, Word смог без проблем открыть файл.По иронии судьбы, он перекодировал \uc1\uxx?обратно к их экранированным эквивалентам 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

Не уверен, что это поможет вашей проблеме, но у меня это работает.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top