最新版Chrome中Javascript的toLocaleTimeString()函数返回ASCII码226而不是空格

Question

我们使用Javascript函数toLocaleTimeString（）来解析日期/时间。最新版本的Chrome突然在秒数和上午/下午部分之间返回ASCII 226，但Edge没有任何问题，旧版本的Chrome也没有问题。110+版本有此问题，而109或更早版本则没有。

例如，如果返回的最后几个字符是：

00 AM

其ASCII转换为：

48 48 226 128 175

那个226以前是32（空格）。

还有其他人也看到这种现象吗？

- user1488803

---

这个特么的改变让我们在生产力上损失了成千上万的美元。多么无聊愚蠢的改变啊。我看到Mozilla开发者在Bugzilla上的讨论说：“它只会影响使用天真解析的烂代码。” 不，我只是对时间字符串进行清理并将其传递给数据库，现在数据库却说：“（耸肩）我不知道这个时间字符串是什么。” 他们混淆了格式化显示和所有其他目的的格式化。我已经通过在处理之前用普通空格替换这个窄的不间断空格字符来解决了这个问题。 - CSX321

我刚刚注意到 Chrome 110.0.5481.178 的分隔符是 32（空格）。 - Norio Yamamoto

Answer 1

这显然是由于这个V8 CL引起的。

以下是此ChangeLog的摘要：

[intl]增强日期解析器以接受Unicode SPACE

这是为了准备ICU72的着陆而需要的。 允许在日期字符串中使用U+202F，这是toLocaleString("en-US")将与ICU72一起生成的。

因此，这是有意为之，以支持ICU-72的下一个版本。因此我们可以假设其他浏览器也会跟进。

[更新]

由于此更改导致太多的Web兼容性问题，Chrome已针对此ICU-72更改修补了其Intl实现，并将这些U+202F字符转换回U+2000字符。显然，Firefox甚至在此之前就已经这样做了。

- Kaiido

---

有趣的是：我的浏览器刚刚更新了，又加入了一个ASCII空格。版本号为110.0.5481.97。 - user1488803

@user1488803确实，他们实际上已经修补了他们的Intl实现，以反对ICU-72（Firefox也做了同样的事）。 - Kaiido

Answer 2

我认为这是一个不间断空格。 不间断空格
由于它也出现在Edge110上，我认为它是从Chromium派生而来的。

const event = new Date('August 19, 1975 23:15:30 GMT+00:00');
const localTime = event.toLocaleTimeString('en-US');
console.log(localTime);
console.log(localTime.indexOf(" "))
console.log(localTime.indexOf("\u{202F}"))
for (let i = 0; i < localTime.length; i++){
  console.log(localTime.charCodeAt(i));
}

- Norio Yamamoto