같은 ff가 255 또는 -1인 이유는?

사용할 도구

• 도구 열기: 비트 연산
• 도구 열기: 정수 범위

먼저 부호 없는 8비트로 읽기

11111111 (binary)
ff (hexadecimal)
255 (unsigned decimal)

폭 8·부호 없음·16진수·OR를 고르고 FF와 0을 넣습니다. OR 0은 패턴을 유지하므로 십진수 255, 이진수 11111111, 16진수 ff를 비교할 수 있습니다. 10진 입력의 FF는 유효하지 않으므로 입력 진법도 조건입니다.

부호 없는 8비트 범위는 0~255이며 256에는 9비트가 필요합니다. 정수 범위 도구에서 폭 8을 확인하면 오류를 설명할 수 있습니다. 255를 2⁸−1로 이해하면 다른 폭에도 적용하기 쉽습니다.

−1을 입력해 같은 비트인지 확인하기

255 − 256 = −1
11111111 → −1 (signed)
11111111 → 255 (unsigned)

부호 있음·10진수로 바꾸고 8비트에서 −1 OR 0을 입력합니다. 십진수는 −1, 부호 없는 값은 255, 비트는 11111111입니다. 2의 보수는 최상위 비트가 1이면 무부호 값에서 2ʷ를 빼므로 255−256입니다. 부호 뒤에 크기 127을 붙인 방식이 아닙니다.

부호 있는 8비트 입력은 −128~127입니다. 16진 숫자 FF는 255이므로 기본 거부 정책에서는 범위를 넘습니다. 잘림으로 낮은 비트를 명시적으로 남길 수 있지만 부호 전환만으로 자동 재해석되는 것은 아닙니다.

FF와 FFFF는 필드 폭이 다릅니다

0000000011111111 = 255
1111111111111111 = −1 (signed 16-bit)
NOT 0, unsigned 8-bit  → 255
NOT 0, unsigned 16-bit → 65535

부호 있는 16비트 00FF는 최상위가 0이라 255이며 −1은 FFFF입니다. 음수를 넓혀 유지하려면 0 채우기가 아닌 부호 확장이 필요합니다. 프로토콜의 1바이트·2바이트 구분은 표시 길이뿐 아니라 의미에 영향을 줍니다.

NOT 0은 폭 8에서 255, 폭 16에서 65535입니다. 도구는 선택 폭으로 결과를 제한합니다. JavaScript Number 비트 연산처럼 언어 규칙과 비교할 때도 폭을 맞추세요. 큰 정수를 지원해도 고정 폭 규칙이 사라지지는 않습니다.

음수 오른쪽 이동은 빈 비트 채우기 확인

11111110 → 01111111 (logical)   = 127
11111110 → 11111111 (arithmetic) = −1

부호 있는 8비트 −2를 한 칸 오른쪽으로 옮기면 논리는 0을 채워 127, 산술은 부호를 유지해 −1입니다. 오른쪽 이동이 무조건 절반이라는 설명으로는 이 차이를 놓칩니다. 비트 패턴인지 부호 있는 연산인지 먼저 정하세요.

잘림으로 잘못된 값을 숨기지 않기

256을 8비트로 자르면 0이 남습니다. 보존이 아닌 정보 손실이며 거부 정책은 이를 막습니다. 형식이 순환이나 하위 비트 보존을 명시할 때만 잘림을 선택하고 편한 결과가 나올 때까지 설정을 바꾸지 마세요.

원문 FF·16진수·폭 8·부호 조건을 기록하고 여러 바이트라면 명세의 바이트 순서도 확인하세요. 정수 해석 일치가 필드 경계나 바이트 순서까지 증명하지는 않습니다. 조건을 맞춰도 다르면 추출한 데이터 자체를 비교하세요.

참고 자료

• MDN — Bitwise NOT (새 탭에서 열립니다)

사용할 도구

• 비트 연산
• 정수 범위