Переход на Unicode для приложения, которое обрабатывает текстовые файлы
Мое приложение Win32 Delphi анализирует текстовые файлы, созданные другими приложениями, которые не поддерживают Unicode. Таким образом, моим приложениям нужно читать и писать строки ANSI, но я хотел бы обеспечить более локализованный пользовательский интерфейс с помощью Unicode в GUI. Приложение выполняет довольно тяжелый посимвольный анализ строки в объектах, происходящих из TList.
При переходе на Unicode GUI при переходе с Delphi 2006 на Delphi 2009 я должен планировать:
- перейти полностью Unicode в моем приложении, за исключением ANISSTRING файл ввода-вывода?
- инкапсулировать код, который обрабатывает анстиструны (то есть продолжает обрабатывать их как ансистрины внутри) из приложения Unicode.
Я понимаю, что для действительно подробного ответа потребуется значительный объем моего кода - я просто спрашиваю о впечатлениях от тех, кто сделал этот переход, и которым все еще приходится работать с простыми текстовыми файлами. Где разместить барьер между ansistrings и Unicode?
РЕДАКТИРОВАТЬ: если #1, какие-либо предложения для отображения строк Unicode для вывода ANISTRING? Я предполагаю, что преобразование входных строк будет автоматическим с помощью tstringlist.loadfromfile (например).
4 ответа
Нет такой вещи как вывод AnsiString - каждый текстовый файл имеет кодировку символов. В тот момент, когда ваши файлы содержат символы вне диапазона ASCII, вы должны подумать о кодировке, поскольку даже загрузка этих файлов в разных странах приведет к разным результатам - если только вы не используете кодировку Unicode.
Если вы загружаете текстовый файл, вам нужно знать, какая у него кодировка. Для форматов, таких как xml или html, эта информация является частью текста, для Unicode есть спецификация, хотя это не является строго обязательным для файлов в кодировке UTF-8.
Преобразование приложения в Delphi 2009 - это возможность подумать о кодировании текстовых файлов и исправить ошибки прошлого. Файлы данных приложения часто имеют более длительный срок службы, чем сами приложения, поэтому стоит задуматься о том, как сделать их ориентированными на будущее и универсальными. Я бы предложил использовать UTF-8 в качестве кодировки текстового файла для всех новых приложений, поэтому перенос приложения на разные платформы прост. UTF-8 - лучшая кодировка для обмена данными, а для символов в диапазоне ASCII или ISO8859-1 он также создает файлы намного меньшего размера, чем даже UTF-16 или UTF-32.
Если ваши файлы данных содержат только символы ASCII, то вы все настроены, так как они также являются действительными файлами в кодировке UTF-8. Если ваши файлы данных имеют кодировку ISO8859-1 (или любую другую фиксированную кодировку), используйте соответствующее преобразование, загружая их в списки строк и сохраняя их обратно. Если вы заранее не знаете, какую кодировку они будут иметь, спросите пользователя при загрузке или укажите настройку приложения для кодировки по умолчанию.
Используйте строки Unicode для внутреннего использования. В зависимости от объема данных, которые вам нужно обработать, вы можете использовать строки в кодировке UTF-8.
Я предлагаю перейти на полный Unicode, если это стоит усилий и требований. И хранение файлового ввода-вывода ANSI отделено от остальных. Но это сильно зависит от вашего приложения.
Ты говоришь:
"Приложение выполняет довольно тяжелый посимвольный анализ строки в объектах, происходящих из TList".
Поскольку Windows работает с Юникодом изначально, анализ символов может выполняться быстрее, если вы загрузите текстовый файл изнутри как Юникод.
С другой стороны, если это большой файл, вы также обнаружите, что он занимает в два раза больше памяти.
Для получения дополнительной информации об этом см. Статью Яна Гойварта: "Преимущества скорости при использовании собственного строкового типа Win32"
Так что это компромисс, который вы должны решить.
Если вы собираетесь использовать вход Unicode из графического интерфейса, какова будет стратегия преобразования его в вывод ASCII? (Это предположение, поскольку вы упоминаете о том, что пишете обратно текст Ansi, предположительно для тех приложений, не основанных на Unicode, которые вы не собираетесь переписывать, и предположительно не имеете исходного кода.) Я бы предложил остаться с AnsiString в приложении. пока эти другие приложения не поддерживают Unicode. Если основная задача вашего приложения - анализ файлов не-Unicode-типа, то зачем переходить на Unicode? Если основная задача вашего приложения заключается в улучшении графического интерфейса с поддержкой Unicode, тогда переходите на Unicode. Я не верю, что представлено достаточно информации, чтобы решить правильный выбор.
Если нет шансов, что непросто переводимые символы будут записаны обратно для этих приложений, отличных от Unicode, то вероятным вариантом будет предложение для UTF-8. Однако, если есть шанс, то как приложения, не поддерживающие Юникод, будут обрабатывать многобайтовые символы? Как вы собираетесь преобразовать (предположительно) базовый набор символов ASCII?