Re: Using a string as filepath
Re: Using a string as filepath
- Subject: Re: Using a string as filepath
- From: "Michael Ash" <email@hidden>
- Date: Thu, 27 Nov 2008 00:11:49 -0500
On Wed, Nov 26, 2008 at 7:09 PM, Knut Lorenzen <email@hidden> 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@hidden)
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 email@hidden