Две кодировки, используемые в строке RTF, не будут отображаться правильно в RichTextBox? - PullRequest
0 голосов
/ 30 января 2009

Я пытаюсь проанализировать некоторые RTF, которые я получаю с сервера. Для большей части текста, который я получаю, это работает отлично (и использование элемента управления RichTextBox сделает эту работу), однако некоторые RTF, кажется, содержат дополнительное «кодирование», а некоторые символы испорчены.

Исходная строка выглядит следующим образом (и содержит некоторые символы, используемые на польском языке):

ąćęłńóśźż

Строка RTF с шестнадцатеричными символами, которая отправляется обратно, выглядит следующим образом

{\lang1045\langfe1045\f16383 {\'b9\'e6\'ea\'b3{\f7 \'a8\'bd\'a8\'ae}\'9c\'9f\'bf}}

У меня проблемы с декодированием символов ñó ​​ в возвращаемой строке, кажется, что они представлены двумя шестнадцатеричными значениями каждое, тогда как остальная часть строки представлена ​​(как и ожидалось) одиночными шестнадцатеричными значениями.

Использование элемента управления RichTextBox для "разбора" RTF приводит к искажению текста (эти два символа отображаются в виде четырех разных нежелательных символов).

Если бы я сам закодировал обычную строку в шестнадцатеричное с использованием ожидаемой кодовой страницы (1250, Latin 2, кодовая страница ANSI для lcid 1045), я бы получил следующее:

\'B9\'E6\'EA\'B3\'F1\'F3\'9C\'9F\'BF

Я заблудился относительно того, как правильно декодировать {\ f7 \ 'a8 \' bd \ 'a8 \' ae} часть возвращаемой строки, которая должна соответствовать ñó ​​.

Обратите внимание, что в заголовке RTF нет определения шрифта для \ f7 , и строка выглядит нормально при просмотре непосредственно на сервере, что означает, что символы (если они повреждены) повреждены где-то в преобразовании перед отправкой.

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

Я просматривал спецификации RTF, но не могу найти подсказки относительно этого типа комбинации кодировок.

1 Ответ

1 голос
/ 31 января 2009

Я не знаю, почему это происходит, но кодировка выглядит как GBK (или что-то достаточно похожее).

Возможно, сервер пытается выполнить какое-то "умное" сопоставление, чтобы найти символы, или кодировка символов по умолчанию сервера - GBK или около того, и эти символы (и только те) также встречаются в GBK, поэтому он предпочитает это.

Я узнал об этом, добавив поврежденные шестнадцатеричные коды (A8 BD A8 AE) в виде байтов в простой HTML-файл, чтобы я мог просмотреть кодировки моего браузера и посмотреть, совпадает ли что-либо:

<html><body>¨½¨®</body></html>

К моему удивлению, мой браузер сразу обнаружил "ñó".

...