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
