Accented Characters in Tags: iTunes vs FLAC, etc.

[magister]

(11-04-2015 12:53)qblack Wrote:  Thanks for pointing me in the right direction and showing me that I was, indeed, "doing something wrong"

You actually aren't doing anything wrong. Software that is Unicode-compliant should handle all accented characters gracefully, whether they are created by using combining marks or with the precomposed combinations. (In this case "gracefully" means not treating the two as different.) Unicode was originally designed to use combining characters exclusively. For reasons I won't go into here, it took a very long time for support for combining characters to become widely implemented, and even now, 20-odd years later, there are still some glitches. But either method should work.

[simoncn]

(12-04-2015 03:33)magister Wrote:  You actually aren't doing anything wrong. Software that is Unicode-compliant should handle all accented characters gracefully, whether they are created by using combining marks or with the precomposed combinations. (In this case "gracefully" means not treating the two as different.) Unicode was originally designed to use combining characters exclusively. For reasons I won't go into here, it took a very long time for support for combining characters to become widely implemented, and even now, 20-odd years later, there are still some glitches. But either method should work.

Thanks for this information. I am investigating the possibility of adding code to MinimServer to convert all tag values into a "normalized" Unicode format. This appears to be the recommended way for applications to solve this problem.

[qblack]

magister:
Thanks for the reply and apologies for just noticing it.

Since Simon showed me the existence of the decomposed forms for UTF-8 strings, I've been reading up on UTF-8 and precomposed vs decomposed forms myself. Now that I understand that the Mac's HFS+ file system uses the decomposed form for extended characters, I realise my "problem" was expected behaviour.

Because I run Mavericks (and Yosemite) on my Macs, I have been able to modify my Applescripts very simply to convert from decomposed to precomposed.

The one line of code required uses Cocoa's NSString's precomposedStringWithCanonicalMapping method. Simples!

Simon:
I endorse your investigation and hope it's as simple for you!

Thanks, all, for the education!

[simoncn]

(23-04-2015 12:49)qblack Wrote:  magister:
Thanks for the reply and apologies for just noticing it.

Since Simon showed me the existence of the decomposed forms for UTF-8 strings, I've been reading up on UTF-8 and precomposed vs decomposed forms myself. Now that I understand that the Mac's HFS+ file system uses the decomposed form for extended characters, I realise my "problem" was expected behaviour.

Because I run Mavericks (and Yosemite) on my Macs, I have been able to modify my Applescripts very simply to convert from decomposed to precomposed.

The one line of code required uses Cocoa's NSString's precomposedStringWithCanonicalMapping method. Simples!

Simon:
I endorse your investigation and hope it's as simple for you!

Thanks, all, for the education!

This change will be in the next MinimServer update. I have tested the performance impact and it doesn't appear to be significant.

[simoncn]

(27-07-2015 12:12)simoncn Wrote:  This change will be in the next MinimServer update. I have tested the performance impact and it doesn't appear to be significant.

This change is now available in MinimServer update 67.