Re: Renaming files?

FROM : Christoffer Lerno
DATE : Wed Dec 22 20:10:02 2004

On Dec 22, 2004, at 15:03, Jeremy Dronfield wrote:

> On 22 Dec 2004, at 9:56 am, Christoffer Lerno wrote:
>

>> You're right (as I said to Clark Cox) it turns out that the encoding
>> is different in the filenames when I get them back. Try taking
>> new00002.tiff, name it
>> “!”•¶ ^^ é @£##  {€} %\<> .gif by using movePath:toPath:handler: and
>> then compare the NSString you kept the new filename in with the
>> filenames gotten from  - (NSArray *)directoryContentsAtPath:(NSString
>> *)path
>>
>> It would seem that they have different encodings the filenames won't
>> match unless I use compare (isEqualToString doesn't work)
>>
>> I wonder if there is some way to take my NSString from the
>> NSTextField and convert that to the filesystem-encoding so they match
>> up with isEqualToString?

>
> The reason -isEqualToString: doesn't work is nothing to do with
> non-ASCII characters in general. It has to do specifically with
> composed character sequences. (Try doing the above example without the
> "é" and it should work.) -isEqualToString: performs a case-sensitive
> comparison - in other words, it does the same thing as
> compare:options: with NSLiteralSearch specified in options:. And from
> the documentation for NSLiteralSearch, "Differing literal sequences
> (such as composed character sequences) that would otherwise be
> considered equivalent are considered not to match."
>
> For filename/path comparisons of the kind you're doing, use a
> case-insensitive compare. There is another reason for this: the file
> system is case-insensitive. -isEqualToString: will tell you that
> "myImage.jpg", "MyImaGe.jpg" and "MYIMAGE.JPG" are all different,
> whereas the file system considers them identical.


I already make sure there is no other file with a similar name using
case-insensitive matching. The Clark Cox nailed down the problem with
the unicode representation, I'm sure the problem is the different
possible unicode representations.

>> Unfortunately most routines don't rely on compare...

>
> I'm not sure what you mean by this. Take the following example using
> my own file renaming application as a basis:


I'm (among other things) using the filename as a dictionary key. Since
the filenames are byte-wise different, isEqualToString: fails where a
compare: would succeed, which in turn makes it impossible for me to
retrieve the dictionary value unless I can make sure the dictionary key
and the key I use actually do satisfy isEqualToString:


/C