NSString中 componentsSeparatedByString存在的陷阱[通俗易懂]-

NSString中 componentsSeparatedByString存在的陷阱[通俗易懂]这两天在对一个国外达人提供的IOS富文本库做一些封装和修改，在用这个库将文本转换成HTML的过程中发现一个奇怪的BUG，就是当文本中存在空行的时候，输出就肯定错误。在源代码中转了一下午都没找到原因，因为项目进度紧张所以把BUG提供给了库的作者。给作者发完邮件，又在源代码中找了一次，其中有一行代码很不起眼，我看了好几遍都没怀疑到这行代码，如下：NSArray *paragraphs=[p

这两天在对一个国外达人提供的IOS富文本库做一些封装和修改，在用这个库将文本转换成HTML的过程中发现一个奇怪的BUG，就是当文本中存在空行的时候，输出就肯定错误。在源代码中转了一下午都没找到原因，因为项目进度紧张所以把BUG提供给了库的作者。给作者发完邮件，又在源代码中找了一次，其中有一行代码很不起眼，我看了好几遍都没怀疑到这行代码，如下：

NSArray*paragraphs = [plainStringcomponentsSeparatedByString:@”\n”];

….

for(NSString*oneParagraphinparagraphs)

{

…

if (oneParagraph == [paragraphs lastObject] && !paragraphRange.length) //就是这一句

{

continue;

}

…

}

其实就是用NSString中的componentsSeparatedByString函数将文本以换行符分隔成一个数组，然后遍历数组，数组中每段文本当做一个<p>标签处理。这段代码如果凭肉眼看怎么都没问题，但如果单步调试的话就可以发现问题。关键就在于oneParagraph == [paragraphs lastObject]， 判断当前是否是数组中最后一个元素（地址比较）。用一个例子就可以发现这样判断是不可靠的。（注：该库作者第二天就给我回复了邮件，他还就这个Bug写了篇博客，下面的例子来源于此http://www.cocoanetics.com/2012/03/beware-of-nsstring-optimizations/)

例子：

NSString*text =@”one,,one,,one,”;

NSArray*components = [textcomponentsSeparatedByString:@”,”];

for(NSString*oneStringincomponents)

{

NSLog(@”‘%@’ = %@ %p”, oneString, [oneStringclass], oneString);

}

输出结果如下：

‘one’ = __NSCFString 0x176960

” = __NSCFConstantString 0x3eeea9d0

‘one’ = __NSCFString 0x177960

” = __NSCFConstantString 0x3eeea9d0

‘one’ = __NSCFString 0x177970

” = __NSCFConstantString 0x3eeea9d0

可以发现，几个空串的地址是一样的！如果用oneParagraph == [paragraphs lastObject]判断最后一个元素的话，第二和第三个空串都会被跳过去！！！

最后解决的办法就是用数组下标判断，i == [paragraphs count] – 1。 虽然不优雅，但可以保证不出错误。

编译器这么做肯定有它的道理，因为为所有空串分配单独内存也没多大必要，但这个陷阱会让很多人受到伤害。