IE的toLocaleString在结果中有奇怪的字符

Joh*_*ner 16 javascript internet-explorer

我遇到了一个超级奇怪的事情,显然是特定于IE的toLocaleString日期.

在IE控制台窗口中:

new Date("2014-08-28T20:51:09.9190106Z").toLocaleString();
"?8?/?28?/?2014? ?1?:?51?:?09? ?PM"
Run Code Online (Sandbox Code Playgroud)

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

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

有谁知道为什么在IE中发生这种情况?这不会发生在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
Run Code Online (Sandbox Code Playgroud)

小智 14

首先,一点背景:IE11实现了ECMA-402 ECMAScript国际化API,重新定义Date.prototype.toLocaleString(以及toLocaleDateStringtoLocaleTimeString)作为对formaton的调用Intl.DateTimeFormat.因此,d.toLocaleString()相当于

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

您可能认为这是非常明确的,但浏览器允许使用它们支持的格式和构成格式的字符的大量余地.这是设计 - 使用地球上的所有语言环境和语言,指定这将是非常繁重的,并且很难保持最新.出于这个原因,您不能指望能够比较toLocaleString不同浏览器的结果,甚至希望相同的浏览器能够从发布到发布继续提供相同的结果.随着底层语言环境数据的更改(可能是因为本地自定义已更改,或者有更多数据可用,或者添加了更好的格式),从此API返回的格式也是如此.

从中可以看出,您应该尽量不依赖于将toLocaleStringAPI 的输出与应用程序中的某些静态值进行比较.此外,给定一个日期d,Date.parse(d.toLocaleString())有时可能会工作,但根据区域设置,可能不工作,所以最好也避免这种情况.

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


小智 10

使用

Str.replace(/[^ -~]/g,'')
Run Code Online (Sandbox Code Playgroud)

这将删除不需要的特殊字符.

  • 这还不错,但 März 现在是 Mrz,在德国是有效的月份名称 (3认同)

Joh*_*ner 7

事实证明你看不到它们,但是IE的Date.toLocaleString显然包含了从左到右的标记(U + 200E):

8<200E>/<200E>21<200E>/2014<200E> <200E> 9<200E>:<200E>16<200E>:<200E>:18<200E> <200E>AM
Run Code Online (Sandbox Code Playgroud)

真棒.我想是时候向IE提交一个bug了吗?