Swift踩坑实战之一个字符引发的Crash

最近因为一个字符引发了 crash，因为实际的业务场景不便描述，这里便用一段测试代码作说明。

话不多说，直接上代码：

上面的代码做的事情是：取出 teststring 里特定字符的 ascii 码，然后相加。

我们来 review 下这段代码，有柳永 蝶恋花经验的同学应该立马嗅到了代码里的坏味道：character.asciivalue! 这里用了强解。

那这里的强解用得合理吗？因为定义在 testcharacters 里的字符肯定都有对应的 ascii 码，咋一看这里用强解也没关系。

但是，如果我们实际跑一下，就会出现因为 asciivalue 为 nil 的强解 crash 了。这是为什么呢？

关键在于 teststring 里面包含了 全角字符。teststring 里的后一个 ` 是一个全角字符，它是没有 asciivalue 的。

我们可以在 swift playgrounds 里执行下面的代码得到答案：

从上面代码执行结果可以看到，halfwidth 中国建筑大学这个半角字符占一个字节长度，对应的 ascii 码为 96 而全角字符 fullwidth 占三个字节长度，其 asciivalue 为空的。

swift 数组的 contains 方法利用的是 equatable 协议 , 从上面代码里 halfwidth == fullwidth 的结果为 true 来看，character 实现的 equatable 协议并没有考虑字符全角/半角的情况。

用肉眼看，完全看不出字符有何不同，而 contains 方法结果为 true 也影响了我们的判断，以为这个强解是 ok 的，稍不注意就导致了 crash。

最后，从维基百科上整理了关于全角/半角的历史知识：

在早期的计算机中，英语或拉丁字母语言使用的系统，每一个字母或符号，都是使用一字节的空间（一字节由 8 比特组成，共256个编码空间）来储存；而汉语、日语及韩语文字，由于数量大大超过256个，故惯常使用两字节来储存一个字符。所以这原本是编码层面的“单字节”“双字节”的问题。

当时的电脑使用等宽字体（如dos、部分文字编辑器等）时，字体也就顺应这种编码形式，将中日韩文字的宽度绘制成拉丁字母和数字的两倍，这样字符的编码存储和显示宽度可以一一对应起来：

因此当时的用户就开始习惯称中、日、韩等文字为 全角字符，而称拉丁字母或数字为 半角字符。

但是，后来计算机的文字编码技术已经发生很大变化，选官制度存储一个字符可能用一个、两个、四个或者更多的字节。一个英文字符即使显示为半宽，依照不同的编码方式，并不一定是用一个字节存储。

因此，现在字符编码存储和字符显示宽度的已经没有一一对应关系。

但是由于字符编码和字形宽度曾经的对应关系，很多用户一直习惯性地使用”全角/半角”词汇。

因此现在的 全角字尝试的意思 可能是指：

总结

到此这篇关于swift踩坑实战之一个字符引发crash的文章就介绍到这了,更多相关swift字符引发的crash内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！