IE 的 toLocaleString 结果中有奇怪的字符 [英] IE's toLocaleString has strange characters in results

问题描述

我在日期的 toLocaleString 中遇到了一个非常奇怪的事情，这显然是 IE 特定的.

I've run into a super strange thing that apparently is IE-specific in toLocaleString on dates.

在 IE 控制台窗口中:

In the IE console window:

new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
"‎8‎/‎28‎/‎2014‎ ‎1‎:‎51‎:‎09‎ ‎PM"

现在，将该字符串作为字符串手动输入，并将其与方法返回的内容进行比较:

Now, type out that string manually as a string and compare it to what the method returned:

"8/28/2014 1:51:09 PM" === new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
false

有谁知道为什么会在 IE 中发生这种情况?这在 Chrome 中不会发生.

Does anyone have any idea why this is occurring in IE? This doesn't occur in Chrome.

更新:更多示例:

new Date("8/28/2014 1:51:09 PM")
[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)[date] Thu Aug 28 2014 13:51:09 GMT-0700 (Pacific Daylight Time)

new Date(new Date("2014-08-28T20:51:09.9190106Z").toLocaleString())
[date] Invalid Date[date] Invalid Date

推荐答案

首先，一点背景知识:IE11 实现了 ECMA-402 ECMAScript 国际化 API，重新定义了 Date.prototype.toLocaleString(以及作为 toLocaleDateString 和 toLocaleTimeString) 作为对 Intl.DateTimeFormat 上的 format 的调用.因此，d.toLocaleString() 等价于

First, a bit of background: IE11 implemented the ECMA-402 ECMAScript Internationalization API that redefined Date.prototype.toLocaleString (as well as toLocaleDateString and toLocaleTimeString) as calls to format on Intl.DateTimeFormat. As such, d.toLocaleString() is equivalent to

Intl.DateTimeFormat(undefined, {
  year: 'numeric',
  month: 'numeric',
  day: 'numeric',
  hour: 'numeric',
  minute: 'numeric',
  second: 'numeric'
}).format(d)

您可能认为这是非常明确的，但浏览器在它们支持的格式和组成格式的字符方面有很大的余地.这是设计使然 - 对于地球上的所有语言环境和语言，指定这将是非常繁重的并且很难保持最新状态.出于这个原因，您不能期望能够跨浏览器比较 toLocaleString 的结果，甚至不能期望同一浏览器在不同版本之间继续给出相同的结果.随着底层语言环境数据的变化(可能是因为本地自定义发生了变化，或者有更多数据可用，或者添加了更好的格式)，从该 API 返回的格式也将发生变化.

You might think that this is pretty explicit but browsers are allowed a large amount of leeway with what formats they support and what characters compose the format. This is by design - with all the locales and languages around the planet, specifying this would be quite burdensome and very difficult to keep up-to-date. For this reason you cannot expect to be able to compare the results of toLocaleString across browsers or even expect the same browser to continue giving the same result from release to release. As the underlying locale data changes (perhaps because local custom has changed, or more data is available, or better formats are added), so too will the format that is returned from this API.

由此得出的结论是，您应该尽量不要依赖于将 toLocaleString API 的输出与应用程序中的某些静态值进行比较.此外，给定一个日期 d，Date.parse(d.toLocaleString()) 有时可能会起作用，但其他情况则取决于语言环境，因此最好也避免这种情况.

The takeaway from this is that you should try not to rely on comparing the output of the toLocaleString APIs with some static value in your application. Further, given a date d, Date.parse(d.toLocaleString()) may work sometimes but not others depending on locale, so it's best to avoid this as well.

话虽如此，en-US 相对稳定，而且大多数浏览器(目前)都同意这种基本格式是什么.但是，IE 会在日期周围插入双向控制字符.这是设计使然，因此当与其他文本连接时，输出文本将正确流动.这在混合 LTR 和 RTL 内容时尤为重要，例如将格式化的 RTL 日期与 LTR 文本连接起来.

With that said, en-US is relatively stable and for the most part browsers do (for now) agree on what that basic format is. However, IE inserts bidirectional control characters around the date. This is by design so the output text will flow properly when concatenated with other text. This is especially important when mixing LTR and RTL content such as concatenating a formatted RTL date with LTR text.

这篇关于IE 的 toLocaleString 结果中有奇怪的字符的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！