JavaScript 비트 연산자

JavaScript에는 &, |, ^, ~, <<, >>, >>> 등 7개의 비트 연산자가 있습니다(C#에는 이 연산자가 없지만 C#에서는 >> ; 이 연산을 구현하기 위한 논리적 오른쪽 시프트), 비트 연산은 모두 이진수로 수행됩니다.

비트 AND 연산자(&)

두 숫자의 동일한 비트가 1이면 1을 반환하고 그렇지 않으면 0을 반환합니다. 예를 들어 1&2=0이면 1의 이진 표현은 0001입니다. 2 의 이진수 표현은 0010이고, 둘 사이의 연산은 0000을 반환합니다.

비트 OR 연산자(|)

두 숫자의 자릿수가 동일하지만 자릿수가 다른 경우 1을 반환하고, 그렇지 않으면 0을 반환합니다(예: 1|2=3).

비트 XOR 연산자(^)

두 숫자 중 동일한 비트가 하나만 있으면 1을 반환하고, 그렇지 않으면 0을 반환합니다(예: 1^2=3).

비트 NOT 연산자(~)

~는 모든 비트를 부정하는 단항 연산자입니다. 우선, 음수 저장에 대해 이야기해야 합니다. 따라서 음수에 대한 연산을 수행할 때 음수, 즉 2의 보수를 올바르게 얻어야 합니다. 양수 코드를 보완합니다. 보수는 반전한 후 1을 더함으로써 구현됩니다. 아래 예를 살펴보겠습니다.

먼저 3의 보수를 계산합니다. 3의 이진 형식은 00000011, 보수는 11111100, 보수는 11111101입니다. so -3 의 이진 코드는 11111101이고, 그 보수인 00000010을 취하려면 ~-3이 필요합니다. 이것은 -3의 보수이고 이를 10진수 2로 변환합니다.

몇 번 더 시도해 보면 숫자의 보수가 실제로는 1의 반대쪽인 소수점임을 알 수 있습니다.

왼쪽 시프트 연산자(<<)

왼쪽 시프트 연산자는 숫자의 모든 비트를 일괄적으로 왼쪽으로 시프트하며, 첫 번째 비트가 두 번째 비트가 되고 두 번째 비트가 됩니다. 3위가 됩니다. . . 비어있는 새 비트는 0으로 채워집니다. 예를 들어, 1 < 의 이진 표현은 1111 1111입니다. 1111 1100을 얻으려면 왼쪽으로 두 자리 이동하십시오. 1로 시작하는 숫자는 음수입니다. 이를 십진수로 변환하려면 역순으로 보수 계산을 수행해야 합니다. 즉, 먼저 1을 빼서 1111 1011을 얻은 다음 이를 부정하여 0000 0100을 얻은 다음 이를 십진수로 변환하고 음수 기호를 추가하여 4를 얻습니다. 여기서 이진 빼기 알고리즘에 주의를 기울여야 합니다: 1-1=0-0=0, 1-0=1, 0-1=1(상위 비트에서 빌려옴).

여기서 왼쪽 시프트 연산은 십진수에 2의 거듭제곱을 곱하는 것임을 알 수 있습니다.

부호 오른쪽 쉬프트 연산자(>>)

왼쪽 쉬프트는 2를 곱하므로 오른쪽 쉬프트는 2로 나누어야 합니다. 실제로는 다음과 같은 경우입니다. 숫자 자체가 양수이면 상위 비트에 0이 추가되고, 음수이면 상위 비트에 1이 추가됩니다. 예를 들어, 3 > 인코딩은 1111 1101입니다. 1111 1110을 얻으려면 1비트를 오른쪽으로 이동하십시오. 이것은 음수입니다. 먼저 1을 빼서 1111 1101을 얻습니다. 0010이면 -2가 됩니다.

부호 오른쪽 시프트 연산은 소수를 2의 거듭제곱으로 나누고 나머지를 버리는 것입니다.

부호 없는 오른쪽 시프트 연산자(>>>)

양수의 부호 없는 오른쪽 시프트 연산 결과는 부호 있는 오른쪽 시프트 연산과 동일하며 주로 음수입니다. 오른쪽 쉬프트 연산. 부호 있는 오른쪽 쉬프트와 다른 점은 양수이든 음수이든 상위 비트에 0을 추가하므로 양수의 경우 부호 있는 연산과 부호 없는 연산이 동일하지만 음수의 경우에는 차이의 세계. 예: -1 > 1111 1111 1111 1111 1111 1111 1111, 첫 번째 숫자는 0이며 이를 십진수로 변환하면 230+229+...+20=230(1-1/231)입니다. /(1-1/2)=231 -1=2147483647, 마침내 필요한 결과를 얻었습니다. 결과가 끔찍하므로 주의해서 사용하세요.

비트 연산자의 적용:

오랫동안 이야기한 결과, 궁극적인 목표는 이러한 연산자를 사용하는 것입니다. 몇 가지 예를 살펴보겠습니다.

RGB 값 color 및 16진수 변환: 예를 들어 색상 값: #33cc10, 처음 두 자리는 빨간색(R), 가운데 두 자리는 녹색(G), 마지막 두 자리는 파란색(B)으로 변환합니다. 다음과 같은 이진 인코딩: 0011 0011 1100 1100 0001 0000(색상에 할당됨) 먼저 빨간색 값을 가져와야 합니다. 이 값은 color>>16만큼 오른쪽으로 이동해야 하며 이는 0000 0000 0000 0000 0011 0011입니다. 이런 방식으로 R=51을 얻은 다음 녹색 값을 얻으려면 8비트(color>>8)만큼 오른쪽으로 이동하여 0000 0000 0011 0011 1100 1100을 얻은 다음 첫 번째 값을 변경해야 합니다. 8비트를 0, 0000 0000 0011 0011 1100 1100|0000 0000 0000 0000 1111 1111로 변환하면 0000 0000 0000 0000 1100 1100이 됩니다. 이런 식으로 G=204를 얻고 마지막으로 파란색 값을 취합니다. 는 처음 8자리를 0으로, 색상 | 0000 0000 0000 0000 0001 0000, B =16, #33cc10을 RGB 값으로 변환하면 (51,204,16)입니다. 반면에 RGB를 16진수로 변환하는 것은 정확히 반대 방법입니다. 즉, G

한 노드가 다른 노드의 상위 노드인지 확인: 예를 들어 두 개의 노드 a와 b가 있습니다. 즉, a가 b의 하위 노드인지 확인하는 방법은 a.contains(b)이고 다른 노드는 다음과 같습니다. 최신 브라우저에서는 a.compareDocumentPosition(b) 메서드를 사용합니다. 이 반환 결과는 부울 값이 아닙니다. a와 b가 동일한 노드인 경우 0을 반환합니다. a와 b가 다른 문서에 있거나 둘 중 하나 이상이 문서 외부에서는 1을 반환합니다. , b가 a 앞에 있으면 2를 반환하고, a가 b 앞에 있으면 4를 반환하고, b에 a가 포함되어 있으면 8을 반환하고, a에 b가 포함되어 있으면 16을 반환하고, 32는 다음과 같습니다. 브라우저 전용입니다. 0, 1, 2, 4, 8, 16의 바이너리 코드는 각각 0000 0000, 0000 0001, 0000 0010, 0000 0100, 0000 1000, 0001 0000입니다. a.compareDocumentPosition(b) & 16이 변환되는지 확인할 수 있습니다. a가 b의 노드인지 확인하기 위해 True 또는 false로 변환한 다음 a.compareDocumentPosition(b) == 16을 사용하여 확인하는 것은 어떨까요? a.compareDocumentPosition(b)는 20(4+ 16)을 반환해야 하므로 a.compareDocumentPosition(b) == 20을 사용하여 작동할 수 있습니다. & 연산자를 사용하면 이러한 점을 고려할 필요가 없습니다. 필요한 값이 16인 & 연산이 true를 반환할 수 있는지 고려하세요. (John Resig는 CompareDocumentPosition을 시뮬레이션하는 방법을 가지고 있으므로 IE에서도 적용 가능합니다. 관심 있는 분은 기사 마지막에 있는 링크를 참고하시면 됩니다~)

비트별 왼쪽 쉬프트 연산: 우리는 1비트씩 왼쪽으로 시프트하는 것이 2를 곱하는 것임을 안다면 a*2 대신 a<<1을 사용할 수 있습니다. 왜냐하면 비트 연산의 효율성이 일반 연산보다 빠르기 때문입니다(때로는 반대 결과를 얻을 수도 있습니다. C#에 비해 JavaScript의 비트 연산 성능은 매우 낮습니다~).

비트 오른쪽 시프트: 한편으로는 a>>1을 사용하여 a/2를 대체할 수 있습니다. 또한 비트 오른쪽 시프트를 사용하면 소수를 3.1415>>0과 같은 정수로 쉽게 변환할 수 있습니다. =3, 비트 시프트 연산에는 피연산자가 정수여야 하므로(자세한 내용은 ECMA-262 매뉴얼 참조) 연산 후 소수점 이하 자릿수는 버려집니다~

참고: 비트 연산자에는 숫자 피연산자는 정수이고, 이러한 피연산자는 32비트 정수로 표시되며 32번째 비트는 부호 비트입니다. 또한 피연산자는 32비트 정수 범위로 제한되며 오른쪽 피연산자는 0에서 31 사이여야 합니다. (본 글의 바이너리 인코딩은 표준화된 것이 아니며 편의를 위한 것입니다~)