On Fri, Dec 17, 2010 at 12:08 PM, Lee Ann Rucker <lruc...@vmware.com> wrote: > > On Dec 17, 2010, at 12:27 AM, Stephen J. Butler wrote: > > On Fri, Dec 17, 2010 at 2:17 AM, Ulf Dunkel > <dun...@calamus.net<mailto:dun...@calamus.net>> 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 clarkc...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com