On Wed, Nov 26, 2008 at 7:09 PM, Knut Lorenzen <[EMAIL PROTECTED]> wrote: > Dear list, > > I would like to name a file according to an user defined entry. However, the > user's name entry might be illegal as a filepath, containing illegal > characters for a pathname like "." or "-" as 1st character, "/", ":", etc. > > I've looked into the Cocoa docs for NSString and NSFileManager to no avail. > > Is there a recommended way to "clean" an NSString in order to get a valid > filepath? One could simply replace all suspicious characters with an > underscore (or something else), but that is not very elegant and feels like > fighting the framework.
There really isn't, because it's a pretty hard problem. The trouble is that legal characters depend mostly on the filesystem you're writing to, and can vary widely. HFS+, for example, places no limits on legal characters in filenames beyond what the POSIX interface imposes on it, whereas FAT32 has a whole bunch of illegal characters. To make things worse, there's no way to query a filesystem and ask it what characters it doesn't like (as far as I know). Worse yet, you can't even reliably query a filesystem and find out what kind of filesystem it actually *is*. Local filesystems can be queried, but if you're connecting to a remote server via AFP, NFS, WebDav, or what have you, the restrictions depend entirely on what the remote end is running. Add in the fact that there are not only character restrictions but length restrictions (which are also all different) and you have a fine mess. Here's an approach I've taken in the past: 1) First, replace all instances of "/" with something else that's reasonable, because "/" is never a legal filename character on any filesystem. ":" is a good choice, because a ":" in a filename will be rendered as a "/" in most GUI settings. This assumes you're using the POSIX interfaces, or you're using something that uses them, like anything that writes files in Cocoa. 2) Try to write the file. If it works, you're done. 3) If the above failed, truncate the name to a reasonable length, such as 255 bytes. This is sort of tricky. Some filesystems care about the number of unichars, some care about the number of bytes in the UTF-8 representation, and some probably care about weird things I don't know about. Be careful when truncating to not chop up surrogate pairs (if doing a unichar-based chop) or UTF-8 code runs (if doing a byte-based chop). 4) Test again. 5) If that test failed, fall back to a simple known-working name. Obviously you can insert more steps as you desire. Depending on how much time you want to spend on this, it may be worthwhile stripping out all characters disallowed by FAT32 and any other commonly-used filesystems as an additional step, and it may be worthwhile trying an even shorter truncation after step 4. But you see the general idea, which is basically that the only way to know if a name will work is to try it. I'm pretty sure there's no better way to go, although as usual, I would very much like for someone to prove me wrong here. Mike _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
