为什么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, ''); 

正如我只需要知道所显示的日期具有相同的值作为输入的日期，这是可以接受的。