숫자·단위·비트
큰 ID에 필요한 비트 수와 16진수 확인하기
사용할 도구
주문 ID를 표에 붙이니 끝자리가 0으로 바뀌거나 연속된 두 ID가 같은 숫자로 보입니다. 큰 정수를 표시하는 능력과 모든 자릿수를 보존하는 능력은 다릅니다. 작은 값에서 정상인 처리도 경계를 넘으면 실패할 수 있습니다.
실제 ID 대신 경계가 분명한 예제 정수를 씁니다. 정수형에 들어가는지 확인하고 진법을 바꿨다가 되돌립니다. DB뿐 아니라 API, 브라우저, 스프레드시트 전달 과정 전체의 표현을 판단하는 데 활용하세요.
255 다음 값도 8비트에 들어갈까요?
정수 범위에서 범위 모드, 8비트, 부호 없음을 고르면 0부터 255입니다. 값은 256종류지만 최댓값은 256이 아닙니다. 값의 개수와 최댓값이 하나 다른 관계는 큰 비트 폭에서도 같습니다.
254 = 11111110₂
255 = 11111111₂
256 = 100000000₂필요 비트 모드에서 부호 없는 255와 256은 각각 8비트와 9비트입니다. 1만 늘어도 이진 자릿수가 늘 수 있습니다. 예상 사용량으로 정한다면 현재 값뿐 아니라 미래 증가와 예약 값도 고려하세요.
64비트라고 범위가 모두 같지는 않습니다
64비트에서 부호 유무를 비교하세요. 부호 있는 정수는 음수도 표현해 양의 최댓값이 작습니다. 각각 9,223,372,036,854,775,807과 18,446,744,073,709,551,615입니다. '64비트 열'만으로 호환성을 판단할 수 없습니다.
부호 있는 8비트 최댓값은 127입니다. 양수 128은 부호 없으면 8비트, 있으면 9비트가 필요합니다. 음수를 쓰지 않는 ID도 수신 타입이 부호 있다면 그 범위에 맞아야 합니다. ID라고 자동으로 unsigned가 되지 않습니다.
20자리 정수를 16진수로 바꿨다가 되돌리기
1844674407370955161510진→16진 변환 결과는 f 16개인 ffffffffffffffff입니다. 이를 16진→10진으로 넣으면 원래 20자리로 돌아옵니다. 끝자리까지 비교해 정수가 유지되는지 확인하세요. 중간에 다른 계산기의 숫자 입력을 거치지 말고 텍스트로 다루세요.
16진수 한 자리는 4비트를 표현하므로 이 값은 64비트가 모두 1입니다. 하지만 최소 폭을 글자 수로 추정할 때는 앞의 0과 첫 자리 값을 봐야 합니다. 두 글자 0f도 값 15에는 부호 없는 4비트면 됩니다. 고정 저장 폭과 최소 폭은 다른 질문입니다.
정수형에 들어가도 Number에서 안전하지는 않습니다
JavaScript의 일반 Number는 64비트 정수형이 아닙니다. 안전 정수 상한은 9,007,199,254,740,991입니다. 더 큰 일부 정수도 표현되지만 모든 이웃 정수를 구별하지는 못합니다. 하나 표시되었다고 같은 자릿수의 모든 ID가 안전하지는 않습니다.
9007199254740993진수 변환에 직접 넣으면 16진수 20000000000001입니다. 역변환도 확인하세요. 다른 처리를 거친 뒤 9007199254740992로 바뀌었다면 이미 원래 자릿수를 잃었습니다. 나중에 BigInt로 바꿔도 원래 정수를 추론해 복구할 수 없습니다.
ID는 숫자여야 할까요, 문자열이어야 할까요?
00123은 수치로 123이지만 텍스트 표기는 다릅니다. 진수 변환은 숫자를 다루므로 앞의 0 개수 보존용이 아닙니다. 계산할 양인지 정확히 일치해야 하는 식별자인지 먼저 정하세요. 우편번호나 회원번호가 숫자뿐이라고 수치로 바꾸지 마세요.
API에서 문자열로 ID를 보내려면 수신 자료형까지 합의해야 합니다. 따옴표만 붙여 해결됐다고 하지 마세요. 문자열 계약인데 중간에 Number로 바꾸면 그곳이 손실 지점일 수 있습니다. 저장뿐 아니라 표시·검색·CSV 출력까지 추적하세요.
전달 단계마다 끝자리까지 비교하기
안전한 작은 값 하나 대신 경계 직전·경계·직후를 시험하세요. 부호 없는 8비트는 254, 255, 256이고 Number는 안전 경계 근처 연속 값입니다. 명시적 거부와 반올림을 구분해 기록하세요. 통과시키려고 값을 줄이는 것은 해결이 아닙니다.
'64비트면 괜찮다' 대신 '부호 없는 64비트 저장에는 들어가지만 브라우저에서는 문자열로 유지'처럼 위치와 표현을 함께 적으세요. 필요 비트 수는 선택 자료일 뿐 DB 열이나 프로토콜 지원을 보장하지 않습니다. 규격과 실제 경로의 왕복 테스트로 확인하세요.
같은 비트도 부호 해석에 따라 값이 달라집니다
8비트 11111111은 부호가 없으면 255이고 2의 보수로 해석하면 -1입니다. 255를 이진수로 변환한다고 자동으로 -1이 되지는 않습니다. 진법은 표기법이고 부호와 비트 폭은 고정 길이 필드의 해석 규칙입니다. 로그의 ff를 무조건 255로 읽기 전에 해당 필드가 부호 있는 값인지 확인하세요.
앞자리 0도 주의해야 합니다. 숫자로는 0010과 10이 같지만 상품 코드로는 다를 수 있습니다. 진법 변환기는 식별자의 자릿수를 보존하는 도구가 아니며 CSV를 읽는 프로그램도 문자열 코드를 숫자로 바꿀 수 있습니다. 계산할 수량인지 대조할 이름인지 먼저 정하세요. 작은 값도 숫자 변환으로 중요한 정보를 잃을 수 있습니다.
경계값 하나만 보지 말고 바로 앞뒤도 시험하세요. 부호 없는 8비트는 254·255·256, JavaScript 안전 정수는 9007199254740991 주변을 확인합니다. JSON 해석이나 API 전달 전후에서 언제 문자열이 숫자가 되는지 추적하세요. 앞 단계에서 잃은 자릿수는 정밀한 도구로도 복구할 수 없습니다. 원문을 보존하고 처음 달라지는 지점을 찾는 것이 빠릅니다.