核心數據保存後的字符串長度變化

我有一個字符串

Белый Клык-0.fb2

的NSString方法長度返回16

保存在覈心數據串之後（後端 - 源碼）

的NSString方法長度返回17，但在視覺上串留相同

Белый Клык-0.fb2

明顯的方法isEqualToString：r E打開NO

花費在實驗了很多時間後，我很fugure指出，問題是這封信：

й

刪除這封信解決問題。

但它讓我瘋狂，爲什麼這樣的事情發生？

這裏解決方法的作品，但不符合我：

stringByReplacingPercentEscapesUsingEncoding： - 需要字符串轉換權和數據庫查詢後
音譯整串 - 有點兒本事

這裏解決方法dosnt工作：

stringWithUTF8String
Converting escaped UTF8 characters back to their original form

請幫我明白是怎麼回事用繩子後保存在覈心數據。

而我有更優雅的解決方案嗎？

來源

2013-02-25 Wert1go

這可能是[unicode normalization]（http://unicode.org/reports/tr15/）相關問題。試試把你的coredata字符串與'[yourOriginalString decomposedStringWithCanonicalMapping]'進行比較，看看是否可行......（我已經測試過它，並且在你的例子中調用字符串時它會返回17的長度） – Alladinian 2013-02-25 08:57:39

謝謝！這真的很奏效，但我甚至沒有聽說過經典映射。你能添加一個答案嗎？我標記它是多麼正確的答案。 – Wert1go 2013-02-25 09:17:46

如果您確實需要保留包含組成字符的原始字符串，則必須將其存儲爲NSData：'[myString dataUsingEncoding：NSUTF16StringEncoding]' – 2013-02-25 09:39:45

該問題可能與unicode normalization有關。因此，Coredata似乎存儲了字符串分解（所以й計數爲2 - 一個字母和一個重音），這就是爲什麼你得到長度的差異。如果你嘗試比較一下Coredata返回前分解原始的字符串，它應該工作：現在

[yourOriginalString decomposedStringWithCanonicalMapping]

，這背後的原因是超出了我的專業領域。我經常使用coredata來管理我的模型，並曾多次使用希臘/俄羅斯字符串工作，並且從未遇到過這樣的問題。如果任何人都可以在這方面做出擴展，並闡明一些看法，我也會對這個問題非常感興趣。

來源

2013-02-25 09:26:35 Alladinian

數據庫通常會執行這些規範分解以增強排序和搜索性能。當數據庫知道內部表示總是被分解時，測試的相等性只是一個按位比較。 – 2013-02-25 09:35:33

@NikolaiRuhe這是有道理的，但不應該'NSString'的比較方法自動處理？ – Alladinian 2013-02-25 09:40:34

他們這樣做，但性能增益來自沒有NSString的地方：數據庫的內部排序，索引和搜索都需要快速比較字符串。增強的性能是知道您不需要更復雜的組合字符感知算法的結果。 – 2013-02-25 09:44:32

核心數據保存後的字符串長度變化

回答

相關問題