Поиск или сравнение в кластере графем по-корейски

Question

В моей текущей реализации UISearchBarController я использую [NSString compare:] внутри метода делегата filterContentForSearchText:scope:, чтобы возвращать релевантные объекты на основе их свойства name в результаты UITableView, когда вы начинаете печатать.

Пока что это прекрасно работает на английском и корейском языках, но я хотел бы иметь возможность выполнять поиск в определенных символьных кластерах NSString. Это применимо только для нескольких языков, одним из которых является корейский.

На английском языке compare: возвращает новые результаты после каждой введенной вами буквы, но на корейском языке результаты генерируются после завершения распознавания кластера графем. Я хотел бы иметь возможность искать в своем имени свойства корейских объектов через отдельные элементы, которые составляют слог.

Может кто-нибудь пролить свет на то, как к этому подойти? Я уверен, что это как-то связано с поиском символов UTF16 вручную или с использованием класса более низкого уровня.

Ура!

Вот конкретный пример, который просто не работает:

`NSString *string1 = @"이"; 
`NSString *string2 = @"ㅣ";
NSRange resultRange = [[string1 decomposedStringWithCanonicalMapping] rangeOfString:    [string2 decomposedStringWithCanonicalMapping] options:(NSLiteralSearch)];

Результат всегда NSNotFound, с decomposedStringWithCanonicalMapping или без него.

Есть идеи?

Answer 1

Я не эксперт, но я думаю, что вы вряд ли найдете чистое решение для того, что вы хотите. Кажется, нет никакой связи между значением Unicode корейского символа и графемами, из которых оно состоит.

например. «이» - это \ uc774, а «ㅣ» - это \ u3163. С точки зрения NSString, это просто два разных персонажа, которые не имеют конкретного отношения друг к другу.

Я подозреваю, что вам придется найти или создать явное сопоставление между символами и их графемами, а затем написать собственную функцию поиска, которая проверяет это сопоставление.

Эта очень длинная страница на юникоде корейском может помочь вам, если это произойдет. В нем есть таблица всех символов, которая предполагает некоторую структурированную связь между порядком нумерации символов и их компонентами.

Answer 2

Если вы используете compare:options с NSLiteralString, он должен сравнивать символ за символом, то есть кодовые точки Unicode, независимо от графемы. Поведение по умолчанию compare: - не использовать опции. Вы можете использовать - decomposedStringWithCanonicalMapping для получения байтов Unicode входной строки, но я не уверен, как это будет взаимодействовать с compare:.