Какую кодировку ожидает использование InstallShield записей таблицы строк из нелатинского алфавита?

Question

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

Это прекрасно работает для таких языков, как французский и немецкий. Но при тестировании программы установки на японском языке текст отображается в виде ряда квадратов. Это вряд ли будет проблемой со шрифтом, так как строки, поставляемые InstallShield, отображаются нормально; искажены только записи таблицы строк. Таким образом, проблема заключается в том, что строки имеют неправильную кодировку.

.ism в формате XML, с кодировкой UTF-8, поэтому я предположил, что строки должны быть также в кодировке UTF-8. Им действительно нужно использовать кодировку целевой платформы? Есть ли какие-либо опасения относительно целей, имеющих разные кодировки, то есть китайские системы, использующие одну GB-кодировку по сравнению с другой? Что здесь делать правильно?

Редактировать: Использование InstallShield 2009, поскольку, очевидно, есть разница между этим и 2010 годом.

Answer 1

В InstallShield 2009 и более ранних версиях кодировка - это кодировка base-64 двоичной строки в кодировке ANSI, специфичной для данного языка (например, CP932 для японского языка). В InstallShield 2010 и более поздних версиях он по-прежнему принимает это или использует UTF-8, в зависимости от других столбцов в этой таблице.

Answer 2

Спасибо (за его голос проголосовал), обращайтесь к Майклу Урману за то, что он указал нам правильное направление. Но это фактический работающий (с InstallShield 2009) алгоритм, перепроектированный коллегой:

1. Начинается с строки Unicode (многобайтовый символ)
2. Запишите длину как поле кодированной длины в ism-файле
3. Кодировать строку как UTF-16-little-endian
4. Base-64, использующий словарь uuencode, за исключением `(обратная галочка) вместо пробелов.
5. Записать результат в ism-файл, избегая XML-сущностей

Имейте в виду, что base-64ing с использованием словаря uuencode не совпадает с использованием алгоритма uuencode. Стандартный uuencode создает набор строк, разделенных новой строкой, включая верхний и нижний колонтитулы и одну или несколько строк данных, каждая из которых начинается с символа длины. Если вы реализуете это с помощью кодека uuencode, вам нужно будет удалить все это.

Answer 3

Я тоже пытаюсь это выяснить ...

Я встроил несколько проектов Installshield 12 (выпущенных до 2009 года) с записями таблицы строк, содержащих символы, находящиеся за пределами диапазона целевых символов base64.

Например, одна из японских строк: 4P! H &$ 9 !O '<<code>4! R &\ = !E & =``@ $ (80!C & L =0!P "00!G`&4`;@!T`)(PI##S,+DPR##\,.LP5S!^,%DP`C

После долгих поисков я наткнулся на кодировку Base85 , которая выглядит гораздо ближе к правдоподобности, но еще не подтвердила, что это решение.