On 22 Sep 2016, at 12:46, John Brownie <john_brow...@sil.org> wrote:
> 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.

My recommendation would be as follows:

1. If possible, don’t base the filename on the user’s input.  Instead, generate 
your own filename (one option might be to use a UUID) and then store a 
dictionary mapping the user’s input to the filename somewhere in your bundle.  
This avoids any problems with filename encoding completely.  You will still 
have to worry about normalising the user’s input, but that’s then just a matter 
of choosing a normalisation.

2. If you must base the filename on user input, do so by stripping out 
non-ASCII characters and replacing them with e.g. ‘_’s.  You’ll also need to 
make sure that the result is unique, otherwise a user might specify two names 
that both map to the same ASCIIfied name.  You’ll still want to store the 
dictionary mapping the user’s input.

The benefit of the second approach is that your bundle is more easily 
understood by a human being.  The downside is that it’s more complicated to 

Both will work, whatever the filesystem is, as they don’t rely on filesystem 
encoding behaviour.

(You might also then ponder whether you want things to be case-sensitive or 
not; the above will be.  Making it not case-sensitive is a little tricky in 
that just converting to upper or lower case doesn’t *quite* work; the correct 
approach would be to use CFStringFold() to case-fold the string, *after* 
normalising, before using it as a dictionary key.)

Kind regards,




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:

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

Reply via email to