資訊內容
一把雙刃劍：Scratch數據類型的隱式轉換
這個積木在數據類型不同的情況下的執行邏輯做了一個簡單匯總，并總結了一些規律。事實上，Scratch是一門弱數據類型的語言，不同于強類型語言在遇到函數引數類型和實際調用類型不匹配的情況經常會直接出錯或者編譯失敗，弱數據類型的語言會進行隱式轉換，有時會產生難以意料的結果。本文將在前篇《從數據類型到計算思維》的基礎上對Scratch數據類型隱式轉換問題進行補充、完善。
01
在前篇《從數據類型到計算思維》中，通過幾個簡單的測試，總結了幾條積木在不同數據類型情況下執行邏輯的規律。
源碼佐證：
_setCostume (target, requestedCostume, optZeroIndex) {if (typeof requestedCostume === 'number') {// Numbers should be treated as costume indices, alwaystarget.setCostume(optZeroIndex ? requestedCostume : requestedCostume - 1);} else {// Strings should be treated as costume names, where possibleconst costumeIndex = target.getCostumeIndexByName(requestedCostume.toString());數字類型的參數被當做造型編號來執行，字符類型的參數被當做造型名稱來執行（前提是有對應的造型名稱時）
if (costumeIndex !== -1) {target.setCostume(costumeIndex);} else if (requestedCostume === 'next costume') {target.setCostume(target.currentCostume + 1);} else if (requestedCostume === 'previous costume') {target.setCostume(target.currentCostume - 1);// Try to cast the string to a number (and treat it as a costume index)// Pure whitespace should not be treated as a number// Note: isNaN will cast the string to a number before checking if it's NaN} else if (!(isNaN(requestedCostume) || Cast.isWhiteSpace(requestedCostume))) {target.setCostume(optZeroIndex ? Number(requestedCostume) : Number(requestedCostume) - 1);}字符類型的參數會被優先“嘗試”轉換為數字類型，并作為造型編號執行。
只是諸多會對數據類型進行自動轉換的積木之一，也是在使用時最容易出BUG、最具代表性的積木。幾乎所有積木都會對數據類型進行自動轉換，有的甚至對輸入的數據類型做了限制，如，無法直接在
積木中輸入字符。
，可以通過給變量賦值“previous
costume”而實現“上一個造型”的效果。還有在《Scratch3.0的十宗罪》中提到的在Sc3.0中訪問列表末項、隨機項的方法。
本身是允許輸入數字類型的。但是通過變量賦值、或是在中文輸入法下拼寫完整單詞直接敲入，可以強行輸入字符類型的關鍵詞，如“all”、“any”、“last”、“random”，實現直接訪問指定項的效果。
if
(typeof index !== 'number') {if (index === 'all') {return acceptAll
? Cast.LIST_ALL : Cast.LIST_INVALID;}if (index === 'last') {if
(length > 0) {return length;}return Cast.LIST_INVALID;} else if
(index === 'random' || index === 'any') {if (length > 0) {return
1 + Math.floor(Math.random() * length);}return
Cast.LIST_INVALID;}}02
轉數字類型失敗
然而并不是所有積木都“幸運”地擁有關鍵詞的。那些沒有關鍵詞的、或者是參數不等于關鍵詞的，Scratch會如何處理呢？ static toNumber (value) {// If value is already a number we don't need to coerce it with// Number().if (typeof value === 'number') {// Scratch treats NaN as 0, when needed as a number.// E.g., 0 + NaN -> 0.if (Number.isNaN(value)) {return 0;}return value;無法被轉換為數字類型的參數（即NaN），將會被轉換為0。有無數多的BUG都是因為這個原因而產生的，比如角色沒有移動到預期位置，卻總是在舞臺中央停滯不前。
很有可能就是這兩個變量中的參數被轉為0了。這個例子更多的會發生在訪問列表的特定項時，索引越界，返回空字符，空字符被轉換為0，像這樣
。列表的問題足以新開一篇文章來探討，在此就不費過多筆墨了。03
布爾值的規則
其實這個小節的主題才是筆者動筆寫這篇文章的主要動機。它來源于一位群友的問題。一個非常經典的問題。
比較運算符的連續嵌套使用
初學者會這樣寫腳本的原因是將數學中的習慣帶到編程里來了（別問筆者是怎么知道的，問就是筆者也犯過相同的錯誤。。）乍一看好像沒有什么問題。但是要知道，程序是一步一步執行的，像這樣嵌套關系的積木，也是先執行上層的，再執行下層的（相當于數學中的括號）。3＞2的結果是true（不打引號以區分字符類型），再比較true和1的大小。到這一步，不論接下去的結果如何，都應該能發現，和數學中連續比較的的3＞2＞1不一樣，這么寫是錯的，是肯定無法得到預期結果的。本著 Scratch 格物堂的“格物”精神，繼續往下看。true和1怎么比大??？這還不簡單嗎？《Scratch 3.0的大小比較是如何進行的》一文中已經說得很清楚了，字符類型的數據在參與比較運算時，比較的是ASCII碼或者說是Unicode碼。而數字0的十進制編號是48，A是65，a是97。就算Scratch不區分大小寫，二十六個字母怎么的也是排在數字后面，字母是肯定大于數字的，“true”>1肯定是true。
“true”>1
看似沒毛病
但是一運行整個腳本。。。
于是開始倒推哪個環節出了問題。
用《Debug in Scratch —— Part 1》中提到的“氣泡輸出法”進行排查：
曾經引以為傲的“氣泡輸出法”
說“true”
還是沒問題
細心的讀者可能會發現，上文中的true，是什么時候被打上引號的？true在參與比較運算時，真的是“true”嗎？我們想當然地以為true被轉換成了字符類型。但是不是字符類型還能是什么？NaN，難道被轉成了0嗎？0>1的確是false沒錯，好像說通了。但是換幾個用例再次進行測試，發現結果又不太一樣。篇幅有限，不再進行引導。直接上測試印證猜測
測試1：
布爾類型（true）參數參與算術運算（+空字符）
測試2：
布爾類型（false）參數參與算術運算（+空字符）
這兩個小測試足以證明，
true被轉換為數字類型時，會被轉換為1；false在被轉換為數字類型時，會被轉換為0.
在上文中的比較運算符的連續嵌套使用示例中，第二次其實是在比較1>1，結果自然是false了。至于為什么“氣泡輸出法”會失效，這是因為
這類積木會將參數轉換為字符類型。
04
實例
也許使用布爾值參與比較運算的確實用價值不高，一般在案例實戰中不會這么用，僅僅需要了解其原因即可。但是筆者的的確確見過一種使用布爾值參與算術運算，巧妙利用數據類型隱式轉換這個特點的案例。下面和讀者朋友們分享一下。一起盜竊案，有4名嫌疑人。這4人只有一名小偷。已知，這4名嫌疑人中，有且僅有1人在說謊。
首先用腳本把4個嫌疑人的供詞用邏輯表達式表示出來：
1號：“不是我?！?
2號：“小偷是3號?！?
3號：“小偷是4號?！?
4號：“3號在說謊”
接著根據條件“4個嫌疑人中有且僅有1人在說謊”，可以推導出結論：以上4個邏輯表達式中，有3個是成立的，有1個是不成立的。再結合上文中get的新技能：布爾值在被轉換為數字類型時，true會被轉換為1，false會被轉換為0，不難得出以下結論：
4名嫌疑人中，有且僅有1人在說謊
最后要做的就只有一件事了：遍歷，從小偷=1開始，逐個驗證即可。篇幅有限，具體步驟就沒必要再細說了。
案例來源：《Scratch趣味編程進階》?作者：謝聲濤
05
總結
如果用哲學中的矛盾觀來分析數據類型的隱式轉換這個問題的話，積木本身的種類、本身的參數類型是主要矛盾，居于主導地位，它決定數據將會被轉換成什么類型；而參數的數據類型則是次要矛盾，位居從屬地位。如果積木本身的參數類型與實際參數類型不匹配，則會優先嘗試將其轉化為本身的參數類型，同時兼顧地“考慮”一下參數本身的“想法”，看看它是否“愿意”被轉換為那種類型，若“不愿意”，則另做打算（比如轉成0或者再比如的復雜轉化邏輯）。Scratch數據類型的隱式轉換這個問題，筆者秉持辯證的觀點來看待。首先這樣無疑對新手來說無疑是十分友好的，易上手。否則動不動地給你報個錯，如果對Scratch的數據類型不夠了解的話，幾乎解決不了。那么現有的教學知識體系中又要多一塊龐大卻又對邏輯思維能力的提升不大且極為枯燥的內容了，這絕對是在“勸退”初學者。另一個優點就是，只要你的想象力足夠豐富，就能利用這個特點做出精妙的案例（前提是你要清楚地知道自己在做什么）。
但是隱式轉換帶來的負面影響也同樣地明顯。相比強類型的語言，Scratch在數據類型這方面來說顯得不夠嚴謹。其次，和其他弱類型語言一樣，隱式轉換總是被打上“它們的存在將導致錯誤的發生”的標簽。一如上文中的3>2>1。Scratch數據類型隱式轉換所造成的BUG數不勝數，細分下去種類繁多。并且就像他的名字一樣，十分隱蔽，極難排查，即使像上文中那樣運用一般的debug方法，也很有可能會因為再次發生隱式轉換而失效。
聲明：本文章由網友投稿作為教育分享用途，如有侵權原作者可通過郵件及時和我們聯系刪除
相關資訊
