同事報案，某上古神獸古老 ASP VBScript 移至 Windows 2012R2 x64 主機後執行出誤，深入追查，問題出在執行 ASC() 解析中文字元一律傳回 63 (?)。
首先聲明，ASC() 並不支援 Unicode，理應改用 ASCW() （參考：1 2），但舊程式汰換在即，能運行就不想投資時間修改重測。程式原本在 Windows 2003 x86 執行正常，一開始以為是 Windows 版本較新造成 VBScript ASC() 行為改變，寫了一小段檢測程式在本機 Windows 10 測試，一樣是新版 Windows，執行結果卻與問題主機不同：
WScript.Echo ASC("黑")WScript.Echo ASCB("黑")WScript.Echo ASCW("黑")陸續找了 Win 8.1、Win 10、Win 2008R2、Win 2012R2，中文英文都有，發現所有主機的執行結果都跟舊主機一致，唯一傳回 63 的只有出問題的 Win 2012R2。
相同作業系統卻有不同結果，問題又可反覆重現，只要找出正常主機跟問題主機的環境差異，就能找出答案。
最後，關鍵在意想不到的地方！
問題主機的國別格式被設成「Match Windows display language」，由於是英文版，啟用中的國別設定是 English(United States)，而其他測試正常的主機格式設定都是台灣。而將原本正常的英文版 Windows 2012R2 格式改成 United States，也能重現 ASC(中文字元) 傳回 63 的現象。實驗如下：
這也太奧妙了，我一直以為格式只影響的是日期、時間、數字的格式偏好，語系編碼應該是看 System Locale 才對（如下圖所示，安裝時早已設好 Chinese (Traditional, Taiwan) ），萬萬沒想到 VBScript 的 ASC() 傳回值竟會受日期、數字格式設定影響！
問題在調整國別格式設定後排除，但留下一個疑點。問題主機為 Web Farm，事後檢查多台主機的格式都被改成 Match Windows display language，眾人都有印象當初已調整成台灣，有什麼原因造成整批主機設定異動，原因成謎。