Alastair Houghton <mailto:alast...@alastairs-place.net>
22 September 2016 at 14:31

This is rather a hairy problem, actually. You don’t know that the filesystem is actually HFS+. The filename in question could refer to a file on an NTFS volume, or (in future) an APFS volume. It could also be a network filesystem, which could be mounted on a system running a completely different operating system with unknown character encoding behaviour; typically UNIX behaviour, for instance, is to completely ignore the filename encoding problem and treat filenames as a string of bytes (thus you are free to interpret them as UTF-8 if you so wish, but the filesystem will regard U+00E9 as different from U+0065 U+0301, even though the two names will display the same on screen).
True, it could be another file system. Another wrinkle!
Additionally, the version specified in HFS+ was based on a particular version of the Unicode standard (I forget which), but importantly *not* the current version, which is what the NSString APIs will use.

Perhaps we should start by understanding the context of your question. Is there a specific reason you want to match the filesystem behaviour precisely?
OK, the situation is that the user provides a name, which comes in through a standard text field in a dialog. That name is used as a key for a dictionary which gives a collection of information about that item. It is also used to create a file, hence it becomes a file name (with an appropriate extension). A complication is that the document is stored as a bundle, and the name is used as a file name for a file in the Resources directory and referenced in the info.plist file.

When reading the document from disk, I need to match up the file name with the appropriate entry in the info.plist. Currently that works as long as I don't hit the normalisation issue. If I get a precomposed character given to me, then the file name becomes the decomposed version, and I've lost the mapping.

The most obvious solution is to create the file and then see what I get back, and use that for the key. However, saving the whole bundle can be an expensive operation, so I wouldn't want to do it lightly. Then I might get the issue of different file systems, though it's less likely to be an issue, or at least it's less likely that a user would save it to two different file systems.

I could perhaps create a scratch file with the given name, but that runs into the possibility of different file systems. Still, if there's no better option, I can work with that.

Oh, and if it makes any difference, I'm supporting back to OS X 10.8 currently.

John
--
John Brownie
In Finland on furlough from SIL Papua New Guinea
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to