假设我们有数字1，它在二进制下的表示为：
00000000000000000000000000000001
现在我想要翻转所有位以获得以下结果:
11111111111111111111111111111110
~（按位取反运算符）来翻转所有位，但~1的结果是-2：
As far as I know, the solution is to use the ~ (bitwise NOT operator) to flip all bits, but the result of ~1 is -2:
console.log(~1); //-2
console.log((~1).toString(2)); //-10 (binary representation)
为什么我会得到这个奇怪的结果？
在1和-2之间有两个整数：0和-1
1在二进制中是00000000000000000000000000000001
0在二进制中是00000000000000000000000000000000
-1在二进制中是11111111111111111111111111111111
-2在二进制中是11111111111111111111111111111110
("binary" 指的是 2 的补码，在按位非 ~ 的情况下)
正如你所看到的，~1等于-2并不奇怪，因为~0等于-1。
正如@Derek在这里解释的那样，这些按位运算符将其操作数视为32位序列。另一方面，parseInt不会这样做。这就是为什么你会得到一些不同的结果。
这里有一个更完整的演示:
for (var i = 5; i >= -5; i--) {
console.log('Decimal: ' + pad(i, 3, ' ') + ' | Binary: ' + bin(i));
if (i === 0)
console.log('Decimal: -0 | Binary: ' + bin(-0)); // There is no `-0`
}
function pad(num, length, char) {
var out = num.toString();
while (out.length < length)
out = char + out;
return out
}
function bin(bin) {
return pad((bin >>> 0).toString(2), 32, '0');
}.as-console-wrapper { max-height: 100% !important; top: 0; }11111111111111111111111111111110 表示的是负数 -2，那么为什么执行 parseInt('11111111111111111111111111111110', 2) 后返回的是 4294967294？ - Afshin Mehrabani~时，你得到的是-2，但解析时得到的是4294967294，这并不奇怪。 - Derek 朕會功夫100 -4
101 -3
110 -2
111 -1
000 0
001 1
010 2
011 3
理解二进制补码的一个简单方法是把它看做是普通的二进制，只是最后一位对应的值取反。在我创造的三位二进制补码中，第一位是1，第二位是2，第三位是-4（请注意负号）。
因此，可以看出，在二进制补码中的按位非为-(n + 1)。令人惊讶的是，将其应用于一个数字两次会得到相同的数字：
-(-(n + 1) + 1) = (n + 1) - 1 = n
当谈论按位操作时，很明显，但在它的算术效果中就不是那么明显了。
还有一些更多的观察可以让我们更容易地记住它的运作方式：
注意负值是如何递增的。规则完全相同，只是0和1互换了。如果你愿意，也可以进行按位非操作。
100 -4 011 - I bitwise NOTted this half
101 -3 010
110 -2 001
111 -1 000
----------- - Note the symmetry of the last column
000 0 000
001 1 001
010 2 010
011 3 011 - This one's left as-is
通过将二进制数列表循环移位总数的一半，您可以得到一个典型的从零开始的升序二进制数序列。
- 100 -4 \
- 101 -3 |
- 110 -2 |-\ - these are in effect in signed types
- 111 -1 / |
*************|
000 0 |
001 1 |
010 2 |
011 3 |
*************|
+ 100 4 \ |
+ 101 5 |-/ - these are in effect in unsigned types
+ 110 6 |
+ 111 7 /
0100001 可以是数字33或者是 !（这就是 ASCII 将该比特序列映射成的方式）。您可以使用一种称为二进制补码的编码方式。在这种编码方式中，您需要决定每个数字将有多少位（例如8位）。最高有效位被保留作为符号位。如果它是0，那么该数字应被解释为非负数，否则为负数。其他7位包含实际数字。
00000000表示零，就像无符号数字一样。 00000001是一，00000010是二，依此类推。在二进制补码中，您可以在8位上存储的最大正数是127（01111111）。
下一个二进制数（10000000）是-128。这可能看起来很奇怪，但稍后我会解释为什么这是有意义的。10000001是-127，10000010是-126等等。 11111111是-1。
11111011，5 是 00000101。 11111011
+ 00000101
----------
000000000
00000000，也就是0。看起来它是起作用的。00010111，-7是11111001。 00010111
+ 11111001
----------
100010000
再次举例，最高有效位丢失了，我们得到00010000 == 16。它起作用了！
这就是二进制补码的工作原理。计算机在内部使用它来存储带符号的整数。
您可能已经注意到，在二进制补码中，当您否定数字N的位时，它会变成-N-1。例如：
~00000000 == 11111111 == -1~00000001 == 11111110 == -2~01111111 == 10000000 == -128~10000000 == 01111111 == 127这正是您观察到的：JS假装使用二进制补码。那么为什么parseInt('11111111111111111111111111111110', 2)是4294967294？因为它只是在假装。
在内部，JS总是使用浮点数表示。它的运作方式与二进制补码完全不同，其位求反大多数情况下也是无用的，因此JS假装一个数字是二进制补码，然后取反其位并将其转换回浮点数表示。这在parseInt中不会发生，因此即使二进制值似乎相同，您仍会得到4294967294。
一个使用2进制补码表示的32位有符号整数（Javascript中规定这是32位有符号整数的格式），将-2存储为11111111111111111111111111111110
所有结果都与预期相同。
parseInt('11111111111111111111111111111110', 2) 的结果是 4294967294 呢？ - Afshin Mehrabani[11111111111111111111111111111110]₂=[10]₂¹。前导的1可以有很多个，但仍然是相同的数字，类似于无符号整数/十进制中的前导0s。[10]₂指定10应解释为基数2（二进制）JavaScript中的数字是浮点数，由IEEE 754标准存储和表示。
然而，对于位运算，操作数在内部被视为以二进制补码格式表示的有符号32位整数:
所有位运算符的操作数都会被转换为以二进制补码格式表示的有符号32位整数。二进制补码格式意味着一个数的负数副本（例如5与-5）是该数的所有位取反（该数的按位NOT，也称为该数的一次补码）加上1。
一个负数的正数副本的计算方式相同。因此我们有：
1 = 00000000000000000000000000000001b
~1 = 11111111111111111111111111111110b
11111111111111111111111111111110b = -2
Number.toString() 不应返回二进制补码表示法。(-2).toString(2) 的结果为 -10，其中 - 是减号，后面跟着数字 2 的二进制表示 10。
11111111111111111111111111111111是-1>~0 === -1- CerbrusparseInt的第一个参数必须是一个字符串。parseInt('11111111111111111111111111111110', 2) | 0- zerkms