On Fri, Dec 17, 2010 at 12:08 PM, Lee Ann Rucker <[email protected]> wrote:
>
> On Dec 17, 2010, at 12:27 AM, Stephen J. Butler wrote:
>
> On Fri, Dec 17, 2010 at 2:17 AM, Ulf Dunkel
> <[email protected]<mailto:[email protected]>> wrote:
> Hi Stephen.
>
> My issue:
> When I search for an existing folder named "äöütest", it isn't found,
> until
> I enter the search string not via keyboard to a search field in my app,
> but
> copy it from the folder name in the Finder and paste it to the search
> field
> in my app.
>
> Some code here would help figure out what is wrong.
>
> Well, it's not really *my* app, so I cannot provide code right now. :-)
>
> The quick and dirty: in Unicode there is more than one way to
> represent "ä". You can represent it as "ä" or "a" followed by a
> special 'character' umlaut. There might be more, I'm not that much of
> an expert. Which form you use is call the normal form:
>
> http://en.wikipedia.org/wiki/Unicode_equivalence
>
> The OS X filesystem API's expect only one (IIRC Normal-D).
It's *almost* NFD; there are some characters that didn't exist when
HFS+ was created that aren't decomposed, where they would be if it
were actually NFD; however, as you note, the *actual* normalization
done is irrelevant.
> If you use
> all the proper APIs and modern conventions you won't have a problem.
>
> This is not actually true. We ran into issues where NSDocument fileURL
> returned a
> differently composited URL to what it was given in
> openDocumentWithContentsOfURL:
>
Your problem is actually the opposite; you're taking what comes *out*
of the filesystem APIs, and comparing them; Whereas the previous
poster was talking about strings going *into* the filesystem APIs. In
your example, there is no need to use "-localizedCompare:",
"-compare:" will do just fine (it already does the proper canonical
comparison, whereas "-localizedCompare:" has the potential for
returning different results depending on the user's locale).
> We were opening the files by dragging onto the app from the Finder, so there
> was no other
> string manipulation happening.
>
> We do this to check whether two URLs really refer to the same file (you can
> also hit issues when using NSString path manipulation to build paths and then
> turn them into URLs):
>
> /*
> * [NSURL isEqualTo:] fails when a path has a trailing slash and
> * an otherwise matching one doesn't. Standardize the path first
> * and use localizedCompare in case the characters were composited
> differently.
> */
> if ([[[self path] stringByStandardizingPath]
> localizedCompare:[[inURL path] stringByStandardizingPath]] ==
> NSOrderedSame) {
> return YES;
> }
> return NO;
--
Clark S. Cox III
[email protected]
_______________________________________________
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]
