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
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
(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.)
Cocoa-dev mailing list (Cocoafirstname.lastname@example.org)
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