對於人來說，complex text就是壹個死記硬背的過程。而對於計算機來說，就變成壹個麻煩事兒。因為保存在存儲器上的文本，無法直接逐字符呈現給用戶看。舉例比如梵文中佛陀(buddha)壹詞，存儲的時候會逐字存儲為
?五個字符，但是如果直接這麽畫出來，誰都看不懂。 所以這就需要壹個complex text layout render engine，它的作用就是把存儲的complex text組合後畫出來，變成可以正常閱讀的形式。 比如Windows下的uniscribe，就是這麽個東西。
這個render engine依賴於兩個東西來工作。第壹是逐語言的規則。也就是說，藏文壹套規則，阿拉伯文壹套規則，印地語壹套規則，梵文壹套規則..... 所以包含了多少種語言的規則，就可以按規則對字符組合，畫出來多少種語言的文字來。第二是字體文件內部的合字規則(ligature)，OpenType和AAT字體支持ligature。
同樣的，Unicode標準提供了壹系列用於進行組合的字符，其中壹部分就是為了支持complex text的。比如上面看到的 就是天城體中的元音附記。
那麽繞回來，為什麽IOS6可能出問題。看上去就是它的complex text layout render engine的規則出問題了。上邊的字串中包含了3個Unicode組合字符。U+0310, U+0334, U+0337. 而不幸的是，這三個字符都不用於阿拉伯語。U+0310叫新月點，壹般用於轉寫天城文，孟加拉文等時標記在拉丁字符上的。U+0334是用於國際音標中標記鼻化元音的那個小波浪線，學法語的同學肯定很熟悉。 U+0337是短刪除線。 這幾個字符都不是用在阿拉伯語中的。
所以當IOS6的engine（原諒我，懶得敲那麽長了）在處理這壹串字符的時候，會根據字符的範圍，判定為阿拉伯字符，再根據字符出現的概率選擇壹種規則（這步可能沒有，但是因為很多語言使用阿拉伯字符，比如烏爾都語，所以這步其實有必要），假定為選擇了阿拉伯語規則。那麽規則裏發現找不到這三個組合字符，傷不起啊有木有！ 然後，掛了.......
從程序猿角度來說，沒有default fall through處理嘛，bug！