Re: File name issue with German umlauts
Re: File name issue with German umlauts
- Subject: Re: File name issue with German umlauts
- From: Clark Cox <email@hidden>
- Date: Fri, 17 Dec 2010 23:29:03 -0800
On Fri, Dec 17, 2010 at 12:08 PM, Lee Ann Rucker <email@hidden> 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@hidden<mailto:email@hidden>> 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@hidden
_______________________________________________
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