Предварительная композиция и декомпозиция Unicode с Delphi

Question

Запись в Википедии для Subversion содержит параграф о проблемах с различными способами кодирования Unicode:

Хотя Subversion сохраняет имена файлов как Unicode, он не указывает, является ли предварительная композиция или декомпозицияиспользуется для определенных акцентированных символов (таких как é).Таким образом, файлы, добавленные в клиенты SVN, работающие в некоторых операционных системах (например, OS X), используют кодировку декомпозиции, в то время как клиенты, работающие в других операционных системах (например, Linux), используют кодирование предварительной компоновки, вследствие чего эти акцентированные символы отображаются некорректнолокальный клиент SVN не использует ту же кодировку, что и клиент, используемый для добавления файлов

Хотя это описывает конкретную проблему с реализациями клиента Subversion, я не уверен, может ли лежащая в основе проблема компоновки Unicode такжепоявляются с обычными приложениями Delphi.Я предполагаю, что проблема может возникнуть только в том случае, если приложения Delphi могут использовать оба способа кодирования Unicode (возможно, в Delphi XE2).Если да, что могут сделать разработчики на Delphi, чтобы избежать этого?

Answer 1

Существует небольшая проблема с отображением в том, что многие шрифты, используемые в Windows, не будут отображать разложенную форму идеальным способом, используя объединенный глиф для буквы и диакритического знака.Вместо этого он возвращается к отрисовке буквы, а затем к наложению автономной диакритической метки сверху, что обычно приводит к менее визуально привлекательной, потенциально односторонней графеме.

Однако это не проблема ошибки Subversion, на которую ссылается викиговорит о.На самом деле вполне нормально проверять имена файлов в SVN, которые содержат составные или разложенные последовательности символов;SVN не знает и не заботится о композиции, он просто использует кодовые точки Unicode как есть.Пока файловая система бэкэнда оставляет имена файлов в том же состоянии, в котором они были вставлены, все в порядке.

В Windows и Linux обе файловые системы одинаково слепы по составу.Mac OS X, к сожалению, нет.Как файловые системы HFS +, так и UFS выполняют «нормализацию» для декомпозированной формы перед сохранением входящего имени файла, поэтому возвращаемое имя файла не обязательно будет той же последовательностью кодированных точек Unicode, которые вы вводите.

Именно это [IMO: безумное] поведение, которое смущает SVN - и многие другие программы - при работе на OS X. Это особенно вероятно, чтобы откусить, потому что Apple случайно выбрала декомпозированный (NFD) в качестве формы нормализации, в то время как большая часть остального мира использует(NFC) символов.

(И это даже не настоящий NFD, а несовместимый вариант только для Apple. Радость.)

Лучший способ справиться с этим, если вы можете, этоникогда не полагаться на точное имя файла, под которым что-то хранится.Если вы когда-либо читаете файл только с заданным именем, это нормально, так как он будет нормализован для соответствия файловой системе в то время.Но если вы читаете список каталогов и пытаетесь сопоставить имена файлов, которые вы там найдете, с тем, что, как вы ожидали, будет именем файла - что и делает Subversion - вы получите несоответствия.

имя файла точно совпадает, вам нужно будет определить, что вы работаете в OS X, и вручную нормализовать как имя файла, так и строку, до некоторой нормальной формы (NFC или NFD) перед выполнением сравнения.Вы не должны делать это в других ОС, которые обрабатывают две формы как разные.

Answer 2

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

Проблема не в отображении, IMO, это сравнение, либо на равенство (котороетерпит неудачу, если оба используют различную кодировку) или лексически, то есть для сортировки.Вот почему нужно нормализовать кодировку, как говорит Дэвид.Таким образом, нет больше безобразий.

Answer 3

Та же проблема может возникнуть в любом приложении, которое имеет дело с текстом. Как избежать этого, зависит от того, какие операции выполняет приложение, а в вопросе отсутствуют конкретные детали. В основном я думаю, что вы решите такие проблемы, нормализуя текст. Это включает использование единственного предпочтительного представления всякий раз, когда вы сталкиваетесь с неоднозначностью кодирования.