Precomposition Unicode y Descomposition con Delphi

La input de Wikipedia para Subversion contiene un párrafo sobre problemas con diferentes forms de encoding Unicode:

Si bien Subversion almacena nombres de files como Unicode, no especifica si se usa la descomposition o descomposition previa para ciertos caracteres acentuados (como é). Por lo tanto, los files agregados en clientes SVN que se ejecutan en algunos sistemas operativos (como OS X) usan encoding de descomposition, mientras que los clientes que se ejecutan en otros sistemas operativos (como Linux) usan encoding precomposition, con la consecuencia de que esos caracteres acentuados no se muestran correctamente si el cliente local SVN no está utilizando la misma encoding que el cliente utilizado para agregar los files

Si bien esto describe un problema específico con las implementaciones de cliente de Subversion, no estoy seguro si el problema subyacente de composition Unicode también podría aparecer con las aplicaciones regulares de Delphi. Supongo que el problema solo puede popup si las aplicaciones Delphi pueden usar ambas forms de encoding Unicode (tal vez en Delphi XE2). En caso afirmativo, ¿qué podrían hacer los desarrolladores de Delphi para evitarlo?

Hay un problema menor de visualización en que muchas fonts utilizadas en Windows no representarán la forma descompuesta de la manera ideal, utilizando el glifo combinado tanto para la letra como para el diacrítico. En su lugar, vuelve a representar la letra y a superponer la marca diacrítica independiente en la parte superior, lo que generalmente da como resultado un grafema potencialmente visualmente less atractivo y potencialmente ladeado.

Sin embargo, ese no es el problema al que hace reference la falla de Subversion del wiki. En realidad, es completamente correcto verificar los nombres de files en SVN que contienen secuencias de caracteres compuestas o descompuestas; SVN no conoce ni se preocupa por la composition, solo utiliza los puntos de código Unicode tal como están. Siempre que el sistema de files de background deje los nombres de los files en el mismo estado en que se colocaron, todo está bien.

Windows y Linux tienen filesystems que son igualmente ciegos a la composition. Mac OS X, desafortunadamente, no. Los filesystems HFS + y UFS realizan la "normalización" en forma descompuesta antes de almacenar un nombre de file entrante, por lo que el nombre de file que obtenga no será necesariamente la misma secuencia de puntos de código Unicode que haya introducido.

Es este comportamiento [IMO: insano] el que confunde SVN y muchos otros progtwigs cuando se ejecuta en OS X. Es particularmente probable que pique porque Apple eligió descompuesto (NFD) como su forma de normalización, mientras que la mayoría del rest de el mundo usa caracteres compuestos (NFC).

(Y ni siquiera es real NFD, sino una variante incompatible solo de Apple. Joy.)

La mejor forma de lidiar con esto es, si puedes, nunca depender del nombre exacto en el que está almacenado algo. Si solo lee un file de un nombre determinado, está bien, ya que se normalizará para que coincida con el sistema de files en ese momento. Pero si está leyendo una list de directorys y tratando de hacer coincidir los nombres de file que encuentra allí con lo que esperaba que fuera el nombre del file, que es lo que Subversion está haciendo, obtendrá discrepancias.

Para hacer una coincidencia de nombre de file de manera confiable, debe detectar que se está ejecutando en OS X y normalizar manualmente tanto el nombre de file como la cadena a alguna forma normal (NFC o NFD) antes de hacer la comparación. No debería hacer esto en otros SO que tratan las dos forms como diferentes.

AFAICT, ambas codificaciones deben producir los mismos resultados cuando se muestran, y ambas son Unicode válidas, por lo que no veo el problema allí. Una rutina de visualización debería ser capaz de manejar ambos si se encuentra descomposition. Un punto de código é debería mostrarse tal como está, mientras que debería mostrarse como é en el modo de descomposition.

El problema no es mostrar, IMO, es comparación, ya sea por igualdad (que falla si ambos usan una encoding diferente) o léxica, es decir, por sorting. Es por eso que uno debe normalizar a una encoding, como dice David. De esa forma ya no hay abmiguidades.

El mismo problema podría popup en cualquier aplicación que trate con text. Cómo evitarlo depende de las operaciones que realiza la aplicación y la pregunta carece de detalles específicos. Sobre todo, creo que resolverías esos problemas normalizando el text. Esto implica el uso de una única representación preferida cada vez que encuentre ambigüedad de la encoding.