> On Mar 11, 2022, at 12:17 PM, Gabriel Zachmann via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > > Well, SSIA. > In more detail, I've got two strings: > > file_basename = @"Morgendämmerung (1)" > info_item = @"Morgendämmerung" > > This code > > NSString * prefix = [ info_item commonPrefixWithString: file_basename > options: NSCaseInsensitiveSearch ]; > unsigned int prefix_len = (unsigned int) [prefix length]; > > yields prefix_len = 15 > as it should. > > The problem arises with this line of code: > > NSRange space_in_filename = [file_basename rangeOfString: @" " options: > NSDiacriticInsensitiveSearch|NSCaseInsensitiveSearch|NSWidthInsensitiveSearch]; > > which yields space_in_filename.location = 16 ! > > This thwarts the rest of the code, which, in this case, would expect > space_in_filename.location = 15. > > Needless to say that with strings that do not contain Umlauts, the call of > rangeOfString:options: works as expected, i.e., in the above example > space_in_filename.location is as expected (i.e., first character has > location=0). > > I have also tried localizedStandardRangeOfString, with the same effect. > > Any ideas what I can do?
It’s hard to tell from the above snippet, but I suspect your strings are different in normalization. Specifically, I suspect that file_basename uses two Unicode codepoints for the ä, and info_item uses only one. As an experiment, try running both strings through -precomposedStringWithCanonicalMapping before doing your comparisons. This method returns a new precomposed string—it doesn’t alter the receiver. Matt _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
