《【转+补充】深入研究js中的位运算及用法》

《【JS时间戳】获取时间戳的最快方式探究》

日常开发中一直没遇到过位运算导致精度丢失的问题，直到这天，搞10位时间戳取整的时候，终于被我撞上了。具体是个什么场景呢，我们来还原下案发现场：

可以看到输出的结果为：

得到的 t 是一个精确到微秒的时间戳。但是请求接口的时候需要的是一个10位（精确到秒）的时间戳，所以这里需要将它转换为10位，自然就是 ➗1000 即可，然后通过位运算来实现类似 Math.trunc 的取证效果，得到了我们要的10位时间戳。至此完美解决！那问题又是如何发生的呢？

按照上面的运算规律，如果我们要获取13位时间戳，是不是直接对 t>>0 就可以了呢？我们来看一下：

输出结果如下：

WTF!!!看到了咩！！！居然输出了一个负数！！！我们想要的结果应该是 1597113682985 才对啊！为什么会出现了负数呢！！！

由此，怪物出现啦！我们今天就来解读（xiang fu)一下它！

想到这里，我们一定就会怪是位运算的锅！那这个锅该怎么让位运算背起来呢！我们来研究一下！

首先我们知道，JS中没有真正的整型，数据都是以double(64bit)的标准格式存储的，这里就不再赘述了，要想搞透其中的原理，请打开 【传送门】

位运算是在数字底层（即表示数字的 32 个数位）进行运算的。由于位运算是低级的运算操作，所以速度往往也是最快的（相对其它运算如加减乘除来说），并且借助位运算有时我们还能实现更简单的程序逻辑,缺点是很不直观，许多场合不能够使用。

以下来源于w3shool:

ECMAScript 整数有两种类型，即有符号整数（允许用正数和负数）和无符号整数（只允许用正数）。 在 ECMAScript 中，所有整数字面量默认都是有符号整数 ，这意味着什么呢？

有符号整数使用 31 位表示整数的数值，用第 32 位表示整数的符号，0 表示正数，1 表示负数。数值范围从 -2147483648 到 2147483647 。

可以以两种不同的方式存储二进制形式的有符号整数，一种用于存储正数，一种用于存储负数。 正数是以真二进制形式存储的 ，前 31 位中的每一位都表示 2 的幂，从第 1 位（位 0）开始，表示 20，第 2 位（位 1）表示 21。没用到的位用 0 填充，即忽略不计。例如，下图展示的是数 18 的表示法。

那在js中二进制和十进制如何转换呢？如下

负数同样以二进制存储，但使用的格式是二进制补码。计算一个数值的二进制补码，需要经过下列3个步骤：

例如，要确定-18的二进制表示，首先必须得到18的二进制表示，如下所示：

0000 0000 0000 0000 0000 0000 0001 0010

接下来，计算二进制反码，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101

最后，在二进制反码上加 1，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101 +

0000000000000000000000000000 0001 =

1111 1111 1111 1111 1111 1111 1110 1110

因此，-18 的二进制就是 1111 1111 1111 1111 1111 1111 1110 1110

而其相反数18的二进制为 0000 0000 0000 0000 0000 0000 0001 0010

ECMAScript会尽力向我们隐藏所有这些信息，在以二进制字符串形式输出一个负数时，我们看到的只是这个负数绝对值的二进制码前面加上了一个负号

JavaScript 只有一种数字类型 ( Number )

我们将 1596596596.3742654.toString(2) 转为二进制字符串表示如下：

1011111001010100010000101110100.0101111111001111110111

但实际在内存中的存储如下：

说到这里就不得不简单提一下数字精度丢失的问题。上面也知道，JS中所有的数字都是用double方式进行存储的，所以必然会存在精度丢失问题。

以下转自文章： JavaScript数字精度丢失问题总结

此时只能模仿十进制进行四舍五入了，但是二进制只有 0 和 1 两个，于是变为 0 舍 1 入。这即是计算机中部分浮点数运算时出现误差，丢失精度的根本原因。

大整数的精度丢失和浮点数本质上是一样的，尾数位最大是 52 位，因此 JS 中能精准表示的最大整数是 Math.pow(2, 53) ，十进制即 9007199254740992

大于 9007199254740992 的可能会丢失精度：

9007199254740992 >>10000000000000...000 ``// 共计 53 个 0

9007199254740992 + 1 >>10000000000000...001 ``// 中间 52 个 0

9007199254740992 + 2 >>10000000000000...010 ``// 中间 51 个 0

实际上

9007199254740992 + 1 ``// 丢失

9007199254740992 + 2 ``// 未丢失

9007199254740992 + 3 ``// 丢失

9007199254740992 + 4 ``// 未丢失

以上，可以知道看似有穷的数字, 在计算机的二进制表示里却是无穷的，由于存储位数限制因此存在“舍去”，精度丢失就发生了。

想了解更深入的分析可以看这篇论文（你品！你细品！）： What Every Computer Scientist Should Know About Floating-Point Arithmetic

关于精度和范围的内容可查看 【JS的数值精度和数值范围】

通过前面的知识补充，我们已经知道：

这也就是为什么对于整数部位为10位的时间戳，通过位运算可以进行取整（因为目前时间戳159xxxxxxx<2147483647），不存在时间戳超过范围的问题。但是对于13位时间戳，如 1596615447123>2147483647 ，此时再通过位运算操作的时候就会导致异常，如：

这主要是因为在进行位运算之前，JS会先将64bit的浮点数 1596615447015.01 转为32bit的有符号整型后进行运算的，这个转换过程如下：

为了验证上述过程，我们再举一个例子： 1590015447015.123 >>0 = 877547495

将将将将！没错的吧！所以JS的这个坑还真是。。。 让人Orz

这不就是无符号右移嘛,当时第一感觉是是为了取绝对值，后来发现并不是，尝试了多次之后，发现情况有点诡异啊，我们使用 chrome 调试工具运行一下 js 中的无符号右移 0 位。

不仅是 null 无符号右移会变成 0 ， js 中的其他非数值做此运算都会变成 0 。

接下来我们来看看为什么会这样（事实上不仅仅只是无符号右移是这样）。要理解这个问题需要先明白什么是位运算以及为什么需要位运算，然后搞明白 js 中的位运算有什么特别之处。

敬请期待

（这一部分我是拿 java、go 与 js 做对比的。）

这在 java、go、c 中都是不被允许的

细心的人已经发现，基本类型里并没有浮点型。

事实上在 js 中的 Number 类型是不区分 int、long、float、double 类型的（ go 的用户们就呵呵一笑了，来来来，我们的浮点型就能王炸你）。回正题，不区分整型、浮点型那怎么存储呢，为了不丢失精度， js 中的 Number 类型实际上一个基于 IEEE 754 标准的双精度64位浮点数（ java 的同学就把它当成 double 看）。看到这我想很多人应该能明白为什么 js 里浮点数也能参与位运算了吧。这也是没有办法，因为对于内存来说整型、浮点型都没有区别了。

这里是有一个问题的，因为当 js 需要进行位运算时，会将操作数通通转成 32 位比特序列（0，1），也就是补码。操作完成之后，再按照 64 位浮点数存储

直接丢弃！！！ 曾呐！这么虎？

没错，就是这么暴力，那么问题来了，既然小数部分不参与位运算，那么为什么不能像 java、go 那样直接禁止呢？关于这个问题，我想那就是语言设计者的想法，我就不知道了。但是这其实也带来了一些特别的操作，比如在 js 中双取反是可以做取整操作的。

当 js 需要进行位运算的时候，对于非数值类型，会首先将操作数转成一个整型（就是0）然后在进行运算。这就解释了为什么 js 中可以允许非数值类型参与运算，其实这是个伪命题，因为实质上是对非数值操作数的整型表达式进行的位运算。

这里需要注意，上面说过了 js 中的整型在内存中都是一个 64 位双精度浮点型，但是 js 进行位运算时，会将操作数转成带符号位的 32 位比特序列（0，1），也就是补码。运算结束后，再按照 64 位存储。那么问题来了，这里肯定会存在精度丢失对吧，这应该不难理解。 js 确实也是这样处理的，超过 32 位的部分直接截断。

所以对一个非数值变量做取反操作，得到的一定是 -1，因为实际上等于对 0 做取反操作。

首尾呼应一下，毕竟就是这个问题使我查资料写了这篇文章。

首先解释一下， >>> 无符号右移原本是 java 里特有的（这里是和 js、go 对比，其他语言我没用过，不能乱说）。 js 中的无符号右移跟 java 几乎一样，除了一点两种语言处理方式完全不一样。

那就是并没有真正发生移位的情况下，符号位会不会被替换成0。 java 中是不会替换的，但是 js 中是会发生替换的。

当操作数是正数的时候，不管有没有真的移位并没有区别，因为正数的符号位是 0。

当操作数是负数时，移动位数大于0，也体现不出区别：

但是当操作数是负数，无符号右移 0 位时，区别就大了：

这是因为 -1 的补码是：

>>>0 实际上并没有发生数位变化，但是 js 却会把符号位替换成 0，

此时原来负数的补码，变为了正数的源码（这就是为什么 js 中 -1>>>0 会变成一个巨大的正整数）。

js 中无符号右移时，不管正数、负数都会首先将符号位替换成 0，然后再进行移位。也就是说，该运算符永远返回正整数。

js 的位运算，为什么会有这么多奇怪的地方呢？我相信很多同学都会有这种想法，特别是 java 的同学们吧。为此我查了 js 的历史。

1995 Sun 公司正式发布 java 语言，当时的网景公司正在为它们的 Navigator 浏览器寻找一种网页脚本（此前的浏览器不具备互动能力）。当他们看到 Sun 公司的宣传后，与 Sun 合作开发全新的脚本语言 javascript 。此前我一直不明白 js 既然不是 java 的脚本，为什么叫这个名字。现在懂了，因为当时新脚本语言的决策中， Sun 公司占了很大一环。

1995年5月 按照公司的要求（一个像 java 但是比 java 简单的脚本语言）， Brendan Eich 仅用10天就写出了 javascript 。

在我们膜拜大神的时候，也要认清一个现实，当时给 Brendan Eich 的时间太短了，所以很多问题并没有很好的解决，而且一边模仿 java、c ，一边还要简化数据类型、内存模型。我觉得这就是为什么 js 的位运算这么奇怪的原因。

js 完全套用了 java 的位运算符。

但是 java 的位运算是针对整数的，对 js 没什么用啊，因为 js 中，所有数字都保存为双精度浮点型。如果使用它们的话， js 不得不将操作数先转为整数，然后再进行运算。

所以很多人不建议在 js 中使用位运算，理由是 js 天生就会进行类型转换，使得效率降低。

---