Как хранить данные юникода в формате, который не поддерживает utf-8

Хорошо, вот еще один вопрос о кодировке символов, демонстрирующий мое невежество во всем, что связано с Unicode.

Я читаю данные из файлов Microsoft Excel .xls и сохраняю их в шейп-файлах ESRI .shp. В версиях Excel > 5.0 текст в файлах Excel сохраняется в формате Unicode. Однако Unicode (и, в частности, UTF-8 поддержка шейп-файлов непоследовательна и, следовательно, Я думаю, что мне вообще не следует его использовать.Однако шейп-файлы поддерживают кодовые страницы старой школы.

Что лучше всего делать в ситуации, когда необходимо преобразовать строку Unicode в строку неизвестной, но определенной кодовой страницы?

Насколько я понимаю, строка Unicode может включать символы из нескольких «кодовых страниц». Поэтому я предполагаю, что я должен каким-то образом оценить «лучшую» кодовую страницу для использования, а затем преобразовать все неподдерживаемые символы в их ближайшее приближение в этой кодовой странице (или ужасную ?). Это обычный подход?

Я определенно могу использовать больше, чем просто системную кодовую страницу. Поскольку файлы .shp используют файлы .dbf для хранения данных своих атрибутов, должны поддерживаться по крайней мере все кодовые страницы, указанные в формате .dbf (см. описание формата xBase). Поддерживаемые кодовые страницы: DOS USA, DOS Multilingual, Windows ANSI, Standard Macintosh, EE MS-DOS, Nordic MS-DOS, Russian MS-DOS, Icelandic MS-DOS, Kamenicky (Czech) MS-DOS, Mazovia (Polish) MS-DOS, Greek MS-DOS (437G), Turkish MS-DOS, Russian Macintosh, Eastern European Macintosh, Greek Macintosh, Windows EE, Russian Windows, Turkish Windows, Greek Windows

Кроме того, некоторые приложения поддерживают использование файла *.cpg, в котором указываются дополнительные кодовые страницы (хотя я понимаю, что поддержка utf-8 и, подозреваю, многих других кодовых страниц ограничена).

Поскольку я пытаюсь разработать инструмент общего назначения, я ничего не могу сказать о содержании Unicode в файлах .xls.


unicode character-encoding dbf language-agnostic
person fmark    schedule 03.07.2010    source источник
comment
Многие приложения могут правильно отображать только файлы, закодированные с использованием системной кодовой страницы. Если это так для вашего целевого приложения, то у вас нет большой гибкости в оценке лучшей кодовой страницы, вместо этого она определяется целевой операционной средой.   -  person Todd Owen    schedule 03.07.2010
comment
Обновленный вопрос, чтобы быть более конкретным.   -  person fmark    schedule 03.07.2010

Ответы (2)


arrow_upward
1
arrow_downward

Что лучше всего делать в ситуации, когда необходимо преобразовать строку Unicode в строку неизвестной, но определенной кодовой страницы?

Зависит от формата файла. Если он поддерживает «управляющие последовательности» Unicode, такие как € в XML или \u20AC в JSON, используйте их, и вы не потеряете никакой информации. Если нет, то нужен другой подход.

Поэтому я предполагаю, что я должен каким-то образом оценить «лучшую» кодовую страницу для использования,

Как правило, в системе, отличной от Unicode, вы должны преобразовывать символы в любую кодировку по умолчанию, а не в произвольную кодовую страницу.

Изменить. Таким образом, у вас есть выбор кодовых страниц:

01h     DOS USA                      code page 437
6Ah     Greek MS-DOS (437G)          code page 737
02h     DOS Multilingual             code page 850
64h     EE MS-DOS                    code page 852
6Bh     Turkish MS-DOS               code page 857
67h     Icelandic MS-DOS             code page 861
65h     Nordic MS-DOS                code page 865
66h     Russian MS-DOS               code page 866
C8h     Windows EE                   code page 1250
C9h     Russian Windows              code page 1251
03h     Windows ANSI                 code page 1252
CBh     Greek Windows                code page 1253
CAh     Turkish Windows              code page 1254
04h     Standard Macintosh           code page 10000
98h     Greek Macintosh              code page 10006
96h     Russian Macintosh            code page 10007
68h     Kamenicky (Czech) MS-DOS
69h     Mazovia (Polish) MS-DOS
97h     Eastern European Macintosh

Для выбора кодовой страницы я бы рекомендовал:

  1. Проверьте, являются ли ваши данные простым ASCII. Если да, то не имеет значения, какую кодовую страницу вы выберете.
  2. Если нет, попробуйте найти кодовую страницу, которая может точно представлять ваши данные (или, если вы не можете, ту, которая сводит к минимуму непредставимые символы). Сначала попробуйте кодовую страницу 1252, а затем другие кодовые страницы 125x. Не беспокойтесь о кодовых страницах DOS, если у вас нет символов для рисования прямоугольников.

а затем преобразовать все неподдерживаемые символы в их ближайшее приближение в этой кодовой странице (или ужасный?). Это обычный подход?

Это подход, который мы используем на работе, когда нам нужно преобразовать файл UTF-8 в windows-1252 или в EBCDIC. Я использовал Unidecode, чтобы помочь сгенерировать «наиболее близкие приближения».

Однако мы заменяем только буквы и цифры, а не знаки препинания. Замена «» на «» нарушит некоторые форматы файлов.

person dan04    schedule 03.07.2010

arrow_upward
1
arrow_downward

На каком языке ваш текст? Если символы в основном ASCII, вероятно, лучше всего написать исходный текст в кодировке UTF-8 как таковой. Программа, не поддерживающая UTF-8, по-прежнему будет правильно читать текст ASCII и отображать искаженный ASCII для неизвестных символов.

person casablanca    schedule 03.07.2010
comment
Я не знаю, на каком языке это будет, заранее. Я обновил вопрос, чтобы отразить это. - person fmark; 03.07.2010