IE11中的ToLocaleDateString（）更改

一尘不染

IE11中的ToLocaleDateString（）更改

javascript

在IE 11中，ToLocaleDateString（）获得了有趣的结果。返回的字符串在浏览器中看起来不错，例如“ 1/28/2014 11:00:46
AM”，但是如果我将该值复制并粘贴到纯文本编辑器中，它看起来像这样：“？1？/？ 28？/？2014？11？：？00？：？46？？AM”。

有趣的是，如果我将文本粘贴到Microsoft产品中，看起来还不错…问题是，如果您尝试以编程方式使用该值来创建日期，则该日期无效。您可以通过在IE11中打开一个控制台并使用ToLocaleDateString（）创建一个新日期，然后尝试使用生成的字符串以javascript或您选择的语言创建一个新日期来测试这一点（我我在这里使用ASP.NET
…）。

我是在做错什么，还是应该以其他方式与javascript日期进行交互？我如何摆脱那些时髦的符号？

编辑：
由于下面的评论，我能够弄清楚未显示的字符是什么，它们是从左到右的标记。根据我将编辑器粘贴的值和编辑器设置为使用的编码，文本将以不同的方式显示：有时带有“？”，有时没有。

阅读 589

2020-04-25

共1个答案

一尘不染

问题是，如果您尝试以编程方式使用该值来创建日期，则该日期无效。

…

我是在做错什么，还是应该以其他方式与javascript日期进行交互？

是的，您做错了。您不应该使用旨在格式化某些内容以实现特定于区域设置的人类显示的功能，并且不要期望输出是机器可解析的。任何的输出的toLocaleString，toLocaleDateString或toLocaleTimeString仅仅是用来人类可读显示。（正如Bergi在评论中澄清的，toString它也用于人类展示，但是ECMA§15.9.4.2表示应该往返）

您可能会获得LTR标记，因为您的显示语言环境是RTL。除此之外，请考虑语言环境将始终影响输出。也许您的语言环境使用dd / mm / yyyy格式而不是mm
/ dd / yyyy格式。或者您的语言环境要求使用亚洲或阿拉伯字符。在确定显示格式时，所有这些都是考虑因素，但从不适合机器解析。

还应考虑ECMAScript规范没有为这些方法的输出定义任何特定的格式规则，并且不同的浏览器将产生不同的结果。

如果意图不是要显示给用户，则应改用以下功能之一：

toISOString 将为您提供ISO8601 / RFC3339格式的时间戳
toGMTString或toUTCString将为您提供RFC822 / RFC1123格式的时间戳
getTime 将为您提供整数毫秒级的Unix时间戳

以上所有都将返回基于UTC的值。如果你想在本地时间，你可以建立自己的字符串与各种存取功能（getFullYear，getMonth，等…），或者你可以使用库如moment.js：

这使用moment.js返回ISO8601格式的本地时间+与日期的偏移量：

moment(theDate).format()   // ex:  "2014-08-14T13:32:21-07:00"

2020-04-25