Normalización Unicode para nombres de archivos y texto copiado de pdf:s

Tengo dos problemas que parecen relacionados. Al copiar texto o nombres de archivo que contienen diéresis o, por ejemplo, å ä ö, parece que OS X no puede manejar los caracteres de forma sensata. Aparentemente, este es un problema bien conocido. Por ejemplo:

Aquí hay un ejemplo del resultado habitual al copiar texto de un nombre de archivo o desde dentro de un pdf en Vista previa y pegarlo en un editor. La primera línea es el resultado, la otra está corregida.

ejemplo de copia

La diferencia es claramente visible, ya que la fuente actual (Courier Prime) no es compatible con la primera versión.

¿Hay alguna forma de arreglar esto? Alternativamente, ¿hay algún servicio OS X disponible para "limpiar" el texto o normalizarlo de la manera correcta?

No entiendo qué tiene que ver la normalización con su problema, que parece un problema de sustitución de fuentes.
PD El motivo de la sustitución de la fuente puede ser que Courier Prime es una fuente un tanto limitada y carece de signos diacríticos combinados. La copia que descargué no parece tener ninguno. Eso significaría que no puede manejar ningún carácter acentuado descompuesto y se requiere el formulario C de normalización. Creo que la mejor solución puede ser usar una fuente Unicode más completa. Todos ellos normalmente incluyen la combinación de signos diacríticos hasta donde yo sé.

Respuestas (1)

HFS+ requiere que los nombres de archivo estén en forma descompuesta (LETRA A MINÚSCULA LATINA + DIÉRESIS COMBINADA) en lugar de forma compuesta (LETRA A MINÚSCULA LATINA CON DIÉRESIS). Puede usar iconv para convertir texto a forma compuesta:

$ echo -n ä | xxd -p
c3a4
$ touch ä
$ ls | tr -d '\n' | xxd -p
61cc88
$ ls | tr -d '\n' | iconv -f utf-8-mac -t utf-8 | xxd -p
c3a4

HFS+ no utiliza NFD (forma normal descompuesta). Desde http://developer.apple.com/library/mac/#qa/qa1173/_index.html :

Importante: Los términos utilizados en estas preguntas y respuestas, precompuestos y descompuestos, corresponden aproximadamente a las formas normales C y D de Unicode, respectivamente. Sin embargo, la mayoría de los formatos de volumen no siguen la especificación exacta para estas formas normales. Por ejemplo, HFS Plus (Mac OS Extended) utiliza una variante de Normal Form D en la que U+2000 a U+2FFF, U+F900 a U+FAFF y U+2F800 a U+2FAFF no se descomponen (esto evita problemas con conversiones de ida y vuelta de antiguas codificaciones de texto de Mac).

Algo como esto también podría funcionar:

python -c 'import unicodedata as ud; print ud.normalize("NFC", u"\N{LATIN SMALL LETTER A}\N{COMBINING DIAERESIS}")'