2013-02-25 81 views
4

所以这是一个问题。核心数据保存后的字符串长度变化

我有一个字符串

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

的NSString方法长度返回16

保存在核心数据串之后(后端 - 源码)

的NSString方法长度返回17,但在视觉上串留相同

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

明显的方法isEqualToString:r E打开NO

花费在实验了很多时间后,我很fugure指出,问题是这封信:

й 

删除这封信解决问题。

但它让我疯狂,为什么这样的事情发生?

这里解决方法的作品,但不符合我:

  1. stringByReplacingPercentEscapesUsingEncoding: - 需要字符串转换权和数据库查询后
  2. 音译整串 - 有点儿本事

这里解决方法dosnt工作:

  1. stringWithUTF8String
  2. Converting escaped UTF8 characters back to their original form

请帮我明白是怎么回事用绳子后保存在核心数据。

而我有更优雅的解决方案吗?

+0

这可能是[unicode normalization](http://unicode.org/reports/tr15/)相关问题。试试把你的coredata字符串与'[yourOriginalString decomposedStringWithCanonicalMapping]'进行比较,看看是否可行......(我已经测试过它,并且在你的例子中调用字符串时它会返回17的长度) – Alladinian 2013-02-25 08:57:39

+0

谢谢!这真的很奏效,但我甚至没有听说过经典映射。你能添加一个答案吗?我标记它是多么正确的答案。 – Wert1go 2013-02-25 09:17:46

+0

如果您确实需要保留包含组成字符的原始字符串,则必须将其存储为NSData:'[myString dataUsingEncoding:NSUTF16StringEncoding]' – 2013-02-25 09:39:45

回答

3

该问题可能与unicode normalization有关。因此,Coredata似乎存储了字符串分解(所以й计数为2 - 一个字母和一个重音),这就是为什么你得到长度的差异。如果你尝试比较一下Coredata返回前分解原始的字符串,它应该工作:现在

[yourOriginalString decomposedStringWithCanonicalMapping] 

,这背后的原因是超出了我的专业领域。我经常使用coredata来管理我的模型,并曾多次使用希腊/俄罗斯字符串工作,并且从未遇到过这样的问题。如果任何人都可以在这方面做出扩展,并阐明一些看法,我也会对这个问题非常感兴趣。

+0

数据库通常会执行这些规范分解以增强排序和搜索性能。当数据库知道内部表示总是被分解时,测试的相等性只是一个按位比较。 – 2013-02-25 09:35:33

+0

@NikolaiRuhe这是有道理的,但不应该'NSString'的比较方法自动处理? – Alladinian 2013-02-25 09:40:34

+0

他们这样做,但性能增益来自没有NSString的地方:数据库的内部排序,索引和搜索都需要快速比较字符串。增强的性能是知道您不需要更复杂的组合字符感知算法的结果。 – 2013-02-25 09:44:32