4

SubversionのWikipediaエントリには、Unicodeエンコーディングのさまざまな方法に関する問題に関する段落が含まれています。

Subversionはファイル名をUnicodeとして保存しますが、特定のアクセント付き文字（éなど）に事前合成または分解を使用するかどうかは指定しません。したがって、一部のオペレーティングシステム（OS Xなど）で実行されているSVNクライアントに追加されたファイルは分解エンコーディングを使用しますが、他のオペレーティングシステム（Linuxなど）で実行されているクライアントはプリコンポジションエンコーディングを使用します。ローカルSVNクライアントは、ファイルの追加に使用されたクライアントと同じエンコーディングを使用していません

これはSubversionクライアントの実装に関する特定の問題を説明していますが、根本的なUnicode構成の問題が通常のDelphiアプリケーションでも発生する可能性があるかどうかはわかりません。この問題は、Delphiアプリケーションが両方のUnicodeエンコーディング方法（おそらくDelphi XE2）を使用できる場合にのみ発生する可能性があると思います。はいの場合、Delphi開発者はそれを回避するために何ができるでしょうか？

4

3 に答える 3

6

There is a minor display issue in that many fonts used on Windows won't render the decomposed form in the ideal way, by using the combined glyph for both the letter and the diacritical. Instead it falls back to rendering the letter and than overlaying the standalone diacritical mark on top, which typically results in a less visually pleasing, potentially-lopsided grapheme.

However that is not the issue the Subversion bug referenced from wiki is talking about. It's actually completely fine to check in filenames to SVN that contain composed or decomposed character sequences; SVN neither knows nor cares about composition, it just uses the Unicode code points as-is. As long as the backend filesystem leaves filenames in the same state as they were put in, all is fine.

Windows and Linux both have filesystems that are equally blind to composition. Mac OS X, unfortunately, does not. Both HFS+ and UFS filesystems perform ‘normalisation’ to decomposed form before storing an incoming filename, so the filename you get back won't necessarily be the same sequence of Unicode code points you put in.

It is this [IMO: insane] behaviour that confuses SVN—and many other programs—when being run on OS X. It's particularly likely to bite because Apple happened to choose decomposed (NFD) as their normalisation form, whereas most of the rest of the world uses composed (NFC) characters.

(And it's not even real NFD, but an incompatible Apple-only variant. Joy.)

The best way to cope with this is, if you can, is never to rely on the exact filename something's stored under. If you only ever read a file from a given name, that's fine, as it'll be normalised to match the filesystem at the time. But if you're reading a directory listing and trying to match filenames you find in there to what you expected the filename to be—which is what Subversion is doing—you're going to get mismatches.

To do a filename match reliably you would have to detect that you're running on OS X, and manually normalise both the filename and the string to some normal form (NFC or NFD) before doing the comparison. You shouldn't do this on other OSes which treat the two forms as different.

于 2011-08-21T17:22:54.593 に答える
1

AFAICT、両方のエンコーディングは表示時に同じ結果を生成するはずであり、両方とも有効なUnicodeであるため、そこでの問題はあまりわかりません。の分解が発生した場合、表示ルーチンは両方を処理できる必要があります。コードポイントéはそのまま表示する必要がありますが、分解モードでe´のみ表示する必要があります。é

問題は表示ではありません、IMO、それは同等性（両方が異なるエンコーディングを使用する場合は失敗します）または字句的に、つまりソートのいずれかのための比較です。そのため、Davidが言うように、1つのエンコーディングに正規化する必要があります。そうすれば、もう異常はありません。

于 2011-08-21T15:02:57.840 に答える
0

The same problem could arise in any application that deals with text. How to avoid it depends on what operations the application is performing and the question lacks specific details. Mostly I think you'd solve such problems by normalizing the text. This involves using a single preferred representation whenever you encounter ambiguity of encoding.

于 2011-08-21T07:34:48.567 に答える