Thanks a lot for your insights!
(I'm cc'ing the mailinglist, just in case someone else later stumbles across
this.)
Best, G.
> On 14. Mar 2022, at 14:57, Aandi Inston wrote:
>
> This is largely from memory, so details might be wrong.
> Normalisation is an insufficiently known thing to
This is largely from memory, so details might be wrong.
Normalisation is an insufficiently known thing to consider when working
with Unicode. (We all know that Unicode is a list of code points
(integers).
Here are some Unicode points for this discussion:
U+0065 "e" Latin Small Letter E
U+00E9
>
> It’s hard to tell from the above snippet, but I suspect your strings are
> different in normalization.
I suspected that, too, but I have no expertise in normalization.
> Specifically, I suspect that file_basename uses two Unicode codepoints for
> the ä, and info_item uses only one.
>
> As
Perhaps worth noting that the docs for commonPrefixWithString:options: cover
cases like this:
> Discussion
> The returned string is based on the characters of the receiver. For example,
> if the receiver is “Ma¨dchen” and aString is “Mädchenschule”, the string
> returned is “Ma¨dchen”, not
NSRange is 0-based, so the 16th character is index 15. Also you might want to
use -localizedStandardRangeOfString: instead...
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business”
> On Mar 11, 2022, at 9:10 AM, Jack Brindle via Cocoa-dev
> wrote:
>
> I just
> On Mar 11, 2022, at 12:17 PM, Gabriel Zachmann via Cocoa-dev
> 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:
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
