未来的谷歌用户(或者不一定是谷歌用户):
以上提到的所有解决方案都非常好,然而,在像这样的情况下使用RegExp可能是非常糟糕的事情。
因此,您可以使用一些提议的选项,甚至编写一些原始但有用的东西,比如:
const strToNum = str => {
let regx = /(\d{1,3})(\d{3}(?:,|$))/;
let currStr;
do {
currStr = (currStr || str.split(`.`)[0])
.replace( regx, `$1,$2`)
} while (currStr.match(regx))
return ( str.split(`.`)[1] ) ?
currStr.concat(`.`, str.split(`.`)[1]) :
currStr;
};
strToNum(`123`)
strToNum(`123456`)
strToNum(`-1234567.0987`)
这里使用的正则表达式相当简单,循环将恰好执行足够次数来完成任务。
您可以进行更好的优化,“DRYify”代码等等。
然而,
(-1234567.0987).toLocaleString()
在大多数情况下,.toLocaleString() 方法是更好的选择。重点不在于执行速度或跨浏览器兼容性。
当您想向用户显示结果数字时,在您的网站或应用程序中使用 .toLocaleString() 方法能够让您与用户说同样的语言(无论他/她的语言是什么)。
根据ECMAScript文档,该方法于1999年推出,我认为其原因是希望互联网能够将全世界人民连接起来,因此需要一些“国际化”工具。
今天,互联网确实将我们所有人连接在一起,因此重要的是记住世界比我们想象中的要复杂得多,(几乎)我们所有人都在互联网上。
显然,考虑到人们的多样性,不可能为每个人保证完美的用户体验,因为我们讲不同的语言,看重不同的东西等等。正因如此,尝试尽可能地本地化事物就更加重要了。
因此,考虑到有一些特定的标准用于表示日期、时间、数字等,我们有一个工具可以以最终用户喜欢的格式显示这些内容,那么不使用该工具(尤其是在想向用户显示这些数据的情况下)是不合适的,甚至有点不负责任。
对我来说,在这种情况下使用正则表达式代替 .toLocaleString(),听起来有点像用 JavaScript 创建时钟应用程序,并以一种仅显示布拉格时间的方式进行硬编码(这对不住不住在布拉格生活的人来说是相当无用的),即使默认行为是
new Date();
按照最终用户的时钟返回数据。
Number.prototype.toLocaleString
在Safari浏览器中仍然不起作用。它只是返回数字本身,而没有错误抛出。由于这个问题,今天我感到非常无语... #goodworkApple - aendra