let testCharacters: Set<Character> = ["!", "\"", "$", "%", "&", "'", "+", ",", "<", "=", ">", "@", "[", "]", "`", "{", "}"]
let testString = "@`Hello World?!"
var result: UInt8 = 0
for character in testString {
    if testCharacters.contains(character) {
	result += character.asciiValue!
    }
}

上面的代碼做的事情是：取出 testString 里特定字符的 ASCII 碼，然后相加。

我們來 Review 下這段代碼，有經(jīng)驗的同學(xué)應(yīng)該立馬嗅到了代碼里的壞味道：character.asciiValue! 這里用了強解。

那這里的強解用得合理嗎？因為定義在 testCharacters 里的字符肯定都有對應(yīng)的 ASCII 碼，咋一看這里用強解也沒關(guān)系。

但是，如果我們實際跑一下，就會出現(xiàn)因為 asciiValue 為 nil 的強解 Crash 了。這是為什么呢？

關(guān)鍵在于 testString 里面包含了全角字符。testString 里的后一個 ? 是一個全角字符，它是沒有 asciiValue 的。

我們可以在 Swift Playgrounds 里執(zhí)行下面的代碼得到答案：

let halfWidth = "`"
halfWidth.lengthOfBytes(using: .utf8) // 1
halfWidth.first!.isASCII // true
halfWidth.first!.asciiValue // 96

let fullWidth = "?"
fullWidth.lengthOfBytes(using: .utf8) // 3
fullWidth.first!.isASCII // false
fullWidth.first!.asciiValue // nil
// Character 實現(xiàn) Equatable 協(xié)議，判斷出兩個值是相等的。
halfWidth == fullWidth // true

從上面代碼執(zhí)行結(jié)果可以看到，halfWidth 這個半角字符占一個字節(jié)長度，對應(yīng)的 ASCII 碼為 96 而全角字符 fullWidth 占三個字節(jié)長度，其 asciiValue 為空的。

Swift 數(shù)組的 contains 方法利用的是 Equatable 協(xié)議 , 從上面代碼里 halfWidth == fullWidth 的結(jié)果為 true 來看，Character 實現(xiàn)的 Equatable 協(xié)議并沒有考慮字符全角/半角的情況。

用肉眼看，完全看不出字符有何不同，而 contains 方法結(jié)果為 true 也影響了我們的判斷，以為這個強解是 OK 的，稍不注意就導(dǎo)致了 Crash。

最后，從維基百科上整理了關(guān)于全角/半角的歷史知識：

在早期的計算機中，英語或拉丁字母語言使用的系統(tǒng)，每一個字母或符號，都是使用一字節(jié)的空間（一字節(jié)由 8 比特組成，共256個編碼空間）來儲存；而漢語、日語及韓語文字，由于數(shù)量大大超過256個，故慣常使用兩字節(jié)來儲存一個字符。所以這原本是編碼層面的“單字節(jié)”“雙字節(jié)”的問題。

當(dāng)時的電腦使用等寬字體（如DOS、部分文字編輯器等）時，字體也就順應(yīng)這種編碼形式，將中日韓文字的寬度繪制成拉丁字母和數(shù)字的兩倍，這樣字符的編碼存儲和顯示寬度可以一一對應(yīng)起來：