爲什麼qUnit的assert.equal認爲這兩個字符串在IE中不同？

Question

我正在使用另一位開發人員編寫的一些qUnit測試，並且在理解爲什麼IE中的特定測試失敗時遇到了一些麻煩。

有一個函數可以將許多不同格式的字符串日期轉換爲UTC日期，並且它似乎正常工作。不過，我在IE中測試它時遇到了一些問題。

爲了測試它，我將函數的返回值（這是一個數字而不是標準的格式化日期），從它創建一個新的日期，然後使用JavaScript的toLocaleString（）函數來獲取一個字符串，我可以比較我創建的另一個字符串。下面是一個測試的例子;減去對函數的調用，我用我從它得到的輸出替換了對函數的調用。

var expectedResult = "11/11/2000 12:56:00"; 
var actualResult = new Date(973947360000).toLocaleString(): 
assert.equal(expectedResult, actualResult); 

這種失敗，但我不明白爲什麼，我沒有使用deepEqual（）和類型相同反正（我已經調試和檢查）。我認爲這可能歸結爲IE的編碼，但我不確定1，如何確定是這種情況，2，繞過它/有效地測試它。值得注意的是，這項測試在FF和Chrome中通過的情況良好，但Chrome在該日期的末尾添加了「PM」。

任何幫助將不勝感激。

下面是IE的輸出快照。

qUnit output difference

Answer 1

看到，因爲沒有其他人與一個解釋，我要請選擇我的解決方法，因爲答案挺身而出。

看起來Internet Explorer中的.toLocaleString（）對兩個日期之間的空間進行編碼的方式與JavaScript初始化的字符串不同。使用下面的代碼替換.toLocaleString（）空間並允許有效評估這兩個值的相等性。

.replace(/[^ -~]/g, ''); 

正如我只需要知道所顯示的日期具有相同的值作爲輸入的日期，這是可以接受的。