Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
- Subject: Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
- From: Quincey Morris <email@hidden>
- Date: Mon, 07 May 2012 15:00:53 -0700
On May 7, 2012, at 13:35 , Martin Wierschin wrote:
> As Jens mentioned, that doesn't make any sense. What good is a localized comparison method if not for sorting a list for display? I suppose you could be implying that Cocoa's sorting methods aren't optimized to assume comparisons are transitive (or special cases problematic strings/comparisons), but that seems quite unlikely.
You're both sliding right over the specifics of what I said:
1. You cannot reasonably use 'localizedCaseInsensitiveCompare:' *alone* to sort and later insert strings into a list of strings that is "case insensitive" in the sense you originally seemed to mean. Specifically, you cannot determine an order for *different* strings that compare *equal* using this method alone (e.g. "a" and "A").
I never said nor intended to say that localized comparison methods *generally* are useless. Just this one, for this particular purpose. The correct method for this particular purpose seems to be 'compare: … options: NSCaseInsensitiveSearch | NSForcedOrderingSearch locale: nil'. Note that this is *not* a case-insensitive comparison -- "a" and "A" are *unequal* in this case.
Another possible alternative is 'localizedStandardCompare:', although there's no API contract here about what strings are equal.
This point has nothing to do with the language or character set used by the strings.
2. Case is a *language-dependent* concept. There's *no* answer to the question "Are these two strings equal ignoring case?" unless you know the language of *each* of the strings.
NSString has no comparison function that lets you specify the locale -- and hence language -- of each string separately. At best, the localized comparison methods let you specify the locale assumed for *both* strings.
This doesn't necessarily mean you can't case-insensitively sort a list of mixed-language strings. It does necessarily mean you can't case-insensitively sort a list of mixed-language strings *using NSString comparison methods only*.
The best you can do with NSString *only* is to assume that words like "laßt" are just mis-spelled English words (if your locale is us_EN). You can't then expect them to sort like they would in their actual language, though of course you can expect transitivity in the comparison methods.
3. You *did* demonstrate (and 2 other people confirmed) a case-insensitive transitivity failure for us_EN in 10.6.8. Markus found no transitivity failure for de_AT; I found no transitivity failure for us_EN in 10.7.3, though you reported you did; no one has reported a transitivity failure other than a case-insensitive comparison involving "ß".
There does seem to be a bug here, but the exact set of conditions isn't clear.
Maybe give 'localizedStandardCompare:' a try?
_______________________________________________
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