Вы можете использовать localizedCompare или localizedCaseInsensitiveCompare для решения проблемы сортировки хирагана-катакана, но не проблему кандзи.
Вы сравниваете это с приложением «Контакты»: к сожалению, «Контакты» на самом деле фиксируют то, что вы вводите фонетически , сохраняя фуригану в отдельном phoneticFamilyName (например, Танака как タ ナ カ), тогда как финальное кандзи (например, , 田中) хранится в familyName, например. Это происходит потому, что после того, как входные данные переведены в кандзи, все показания отображаются в одной последовательности юникода. Например. независимо от того, вводите ли вы 中 через チ ュ ウ или な か (в зависимости от того, в каком слове вы его вводите), полученный в результате символ 中 по-прежнему будет просто unicode 0x4e2d. Вам нужно сохранить фонетическое правописание в отдельном поле, если вы хотите знать, как вы попали к этому персонажу.
Суть в том, чтобы попросить алгоритм сортировки выяснить, какая фуригана для некоторой случайной последовательности кандзи является нетривиальной проблемой, потому что у нее нет способа узнать, какой на йоми или Кун Йоми или Нанори применяется для любого данного кандзи. Вот почему приложение «Контакты» хранит это в отдельном поле. Есть CFStringTransform преобразований между кана и ромадзи, но не для кандзи.
Конечно, теоретически представляется возможным выполнить некоторую обработку естественного языка и / или разбор словаря строки, но это кажется мне достаточно сложным в вычислительном отношении и, вероятно, не практичным, чтобы попытаться сделать это как раз вовремя в процедуре сортировки. Я бы предложил хранить фуригану в отдельном поле, как это делает фреймворк Contacts.