텍스트 / 2진수 변환
텍스트를 2진수로, 2진수를 텍스트로 변환합니다. UTF-8 바이트를 바이트마다 8자리로 쓰고, 제자리에 있지 않은 문자는 줄과 열을 알려 줍니다.
11101100 10010101 10001000 11101011 10000101 10010101 11101101 10010101 10011000 11101100 10000100 10111000 11101100 10011010 10010100
텍스트가 0과 1이 되는 과정
컴퓨터는 텍스트를 바이트로 보관하며, 1바이트는 8비트이고 비트 하나하나는 0 또는 1입니다. 이 페이지는 그 바이트를 보여 줍니다. 텍스트를 입력하면 모든 바이트가 2진수 여덟 자리로 나오고 바이트와 바이트 사이에는 공백이 들어가며, 반대로 2진수를 붙여넣으면 그 숫자가 이루는 텍스트를 읽을 수 있습니다. 양방향으로 동작하고, 전적으로 브라우저 안에서 실행되며, 이미 변환된 예시로 열립니다.
텍스트가 어떤 바이트로 이루어지는지는 인코딩에 달려 있고, 여기서는 따로 고르지 않는 한 UTF-8입니다. 웹 페이지와 URL과 대부분의 텍스트 파일이 담고 있는 것이 UTF-8이기 때문입니다. ‘단위’에서 고르는 것은 숫자 그룹 하나가 무엇을 나타내느냐입니다. UTF-8의 1바이트, 두 바이트 순서 중 하나로 쓴 UTF-16의 1바이트, 또는 코드 포인트 하나입니다. 고른 단위는 양방향 모두에 적용되며, 페이지가 여러분 대신 바꾸는 일은 없습니다. 붙여넣은 것이 다른 단위처럼 보이면 페이지가 그렇다고 말하고 그 알림 옆에 버튼을 두며, 그 버튼을 누르기 전에는 아무것도 바뀌지 않습니다.
바이트마다 여덟 자리로 쓰는 이유
비트는 2진수 한 자리이고, 바이트는 비트 여덟 개입니다. 8비트를 켜고 끄는 조합은 256가지이므로, 1바이트에는 0부터 255까지의 정수가 들어가며, 0은 00000000이고 255는 11111111입니다. 파일과 메모리와 네트워크는 바이트로 크기를 세고, 여러분이 만날 법한 어느 기계에서나 1바이트는 8비트입니다. 네트워크 표준은 이것을 옥텟이라고 부르는데, 여덟이라는 뜻밖에 될 수 없는 말입니다.
그 값 가운데 처음 128개가 ASCII, 곧 영어 글자와 숫자와 흔히 쓰는 문장 부호를 나타내는 코드이며, 128개의 값에는 7비트만 있으면 됩니다. 그래서 ASCII 문자의 바이트는 모두 0으로 시작하고, UTF-8은 1로 시작하는 바이트를 ASCII에 없는 모든 것을 위해 남겨 둡니다. 이 페이지가 모든 바이트를 앞의 0까지 포함한 여덟 자리 전부로 쓰는 데에는 실용적인 이유도 있습니다. 폭이 하나로 고정된 바이트는 사이에 공백이 없어도 여덟 자리씩 되읽을 수 있기 때문입니다.
글자 H를 비트 하나씩
대문자 H를 봅시다. ASCII는 이 글자에 72번을 매기고, 72를 바이트로 쓰면 01001000입니다. 왼쪽부터 읽을 때 여덟 자리의 자릿값은 128, 64, 32, 16, 8, 4, 2, 1이고, 1은 저마다 제 자리의 값을 셈에 넣습니다. 이 바이트는 자릿값이 64와 8인 자리에 1이 있고, 64와 8을 더하면 72입니다. 소문자 i는 105, 곧 64, 32, 8, 1을 더한 값이므로 Hi는 01001000 01101001이 됩니다.
대소문자는 비트 하나 차이입니다. 소문자 h는 01101000으로, H의 바이트에서 자릿값 32의 자리를 켠 것이며, 영어 알파벳의 모든 글자가 그렇습니다. ASCII가 소문자마다 대문자보다 정확히 32 큰 번호를 매기기 때문입니다.
‘진법’은 같은 바이트를 바꾸지 않은 채 다른 방식으로 씁니다. ‘10진수’를 고르면 H는 72, ‘16진수’를 고르면 48, ‘8진수’를 고르면 110입니다. 한 바이트를 네 가지로 쓴 것이며, 되읽을 때는 어느 진법을 골랐든 그 진법으로 숫자를 받아들입니다. ‘텍스트 / 16진수 변환’은 ‘16진수’로 열리고, 거기서는 한 바이트가 여덟 자리가 아니라 두 자리를 차지합니다.
ASCII 너머의 글자가 2바이트 이상을 차지하는 이유
ASCII는 127에서 끝납니다. 악센트가 붙은 글자, 키릴·히브리·아랍 문자의 글자, 일본어나 한국어 문자, 그리고 이모지는 모두 그 너머에 코드 포인트가 있으며, UTF-8은 ASCII일 때만 문자를 1바이트로 쓰고 1로 시작하는 바이트는 나머지 모두를 위해 남겨 둡니다. 그래서 이것들은 저마다 2바이트, 3바이트 또는 4바이트를 차지하는데, 그 모습을 지켜볼 수 있는 곳이 2진수입니다. 모든 바이트의 첫 비트들이 그 바이트가 문자의 어느 부분인지를 말해 주기 때문입니다.
- 0xxxxxxx는 1바이트 문자입니다. ASCII이며, 그 7비트가 x 자리에 쓰입니다. H는 01001000입니다.
- 110xxxxx 10xxxxxx는 2바이트 문자로, 2,047까지의 코드 포인트에 쓰이며, 유럽 언어의 악센트가 붙은 글자와 키릴·히브리·아랍 문자가 여기에 듭니다. é는 11000011 10101001이고 א는 11010111 10010000입니다.
- 1110xxxx 10xxxxxx 10xxxxxx는 3바이트로, 65,535까지의 코드 포인트에 쓰이며, 일본어 가나와 자주 쓰는 한자, 한국어 한글, 유로 기호가 여기에 있습니다. €는 11100010 10000010 10101100입니다.
- 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx는 4바이트로, 그 너머의 모든 코드 포인트에 쓰이며, 대부분의 이모지가 여기에 있습니다.
1이 두 개, 세 개 또는 네 개 이어지며 시작하는 첫 바이트는 그 문자가 몇 바이트인지 알려 주고, 문자를 이어 가는 바이트는 모두 10으로 시작하므로, 문자 한가운데의 바이트가 문자의 시작으로 오인될 수는 없습니다. א의 두 바이트에서 표지인 110과 10을 떼어 내면 남는 열한 비트, 10111010000이 그 코드 포인트 U+05D0을 2진수로 쓴 것입니다. ‘16진수’를 고르면 같은 두 바이트가 D7 90으로 읽히고 패턴은 숫자 속에 접혀 들어가지만, 2진수에서는 모든 바이트의 첫 비트들에 드러나 있습니다.
이모지 하나에 4바이트
이모지 😀의 코드 포인트 U+1F600은 65,535를 한참 넘으므로, UTF-8은 이 이모지를 4바이트로 씁니다. 11110000 10011111 10011000 10000000입니다. 첫 바이트는 1 네 개로 시작하므로 4바이트 문자를 시작하고, 그 뒤의 세 바이트는 저마다 10으로 시작합니다. 그 코드 포인트는 2진수로 열일곱 자리, 11111011000000000을 차지하는데, 3바이트 문자에 들어갈 수 있는 열여섯 자리보다 하나 많습니다. 4바이트 패턴에는 스물한 자리까지 들어갑니다.
하나의 기호처럼 보이는 이모지가 여러 코드 포인트로 이루어질 수 있고, 그 각각이 빠짐없이 쓰입니다. 피부색을 지정한 손 흔드는 이모지는 코드 포인트 두 개에 8바이트입니다. 4인 가족 이모지는 코드 포인트 일곱 개, 곧 네 사람과 그 사이의 보이지 않는 결합자 셋이며, 25바이트입니다. 하나를 페이지에 붙여넣고 그룹을 세어 보세요.
다른 변환기가 א에 열한 자리를 출력하는 이유
א에 대해 10111010000이라는 열한 자리를 출력하는 변환기는 그 바이트를 쓴 것이 아닙니다. 유니코드가 이 글자에 준 번호, 곧 코드 포인트 U+05D0인 1488을 하나의 2진수로 쓴 것이며, 그 수는 파일이나 네트워크가 담는 어떤 것의 바이트도 아닙니다. 그렇게 쓴 메시지는 같은 가정을 하는 읽는 쪽만 되읽을 수 있습니다.
두 답은 보기보다 가깝습니다. 그 열한 자리는 위에서 보았듯이 표지를 떼어 낸 뒤 UTF-8이 두 바이트에 나누어 싣는 비트 그대로이므로, 두 변환기는 같은 수를 쓰고, 그 수를 저장하는 바이트를 쓰는 것은 한쪽뿐입니다. ASCII 문자에서는 둘이 앞의 0을 빼면 일치하므로, 평범한 영어에는 같은 답을 내고 그 밖의 거의 모든 것에서 갈라집니다.
이 페이지도 그 답을 냅니다. 다만 페이지가 가정하는 것이 아니라 여러분이 고르는 단위로서입니다. ‘코드 포인트’를 고르면 א는 10111010000으로 쓰이고 같은 방식으로 되읽힙니다. 코드 포인트를 쓰는 변환기가 히브리어, 러시아어 또는 일본어로 쓴 메시지를 UTF-8을 고른 채 붙여넣으면 그룹이 바이트로 보기에는 너무 넓습니다. 페이지는 짐작하지 않고, 그룹이 코드 포인트처럼 보인다고 말하며 ‘코드 포인트로 전환’을 내놓습니다. JavaScript의 charCodeAt처럼 UTF-16 코드 단위를 하나씩 다루는 변환기는 😀 이모지를 열여섯 자리 수 두 개로 쓰는데, UTF-16이 이 이모지를 저장하는 서로게이트 쌍의 두 반쪽입니다. ‘코드 포인트’는 그 쌍을 하나의 이모지로 되읽습니다.
2진수를 텍스트로 되읽기
2진수를 다시 텍스트로 바꾸려면 ‘2진수에서 텍스트로’ 방향으로 바꾸고 숫자를 입력하거나 붙여넣으세요. 출력은 그 숫자가 이루는 텍스트입니다. ‘입력으로 사용’은 이를 클릭 한 번으로 해 주며, 출력을 입력으로 옮기고 방향을 바꿉니다. 왕복을 확인하는 가장 빠른 방법입니다. 다음은 모두 같은 바이트로 읽힙니다.
- 바이트 사이의, 줄바꿈을 비롯한 모든 종류의 공백과 쉼표, 세미콜론, 콜론, 하이픈.
- 구분자가 전혀 없는 것. 숫자가 여덟 자리씩 온전한 바이트로 나뉘는 곳이라면 어디서나 읽히며, ‘스타일’의 ‘구분 없음’이 이렇게 씁니다.
- 일곱 자리 이하의 그룹. 앞의 0을 뺀 ASCII 문자가 이런 모양이며, 1001000 1101001은 Hi로 읽힙니다.
- 바이트 앞의 0b(대문자든 소문자든)와, 전체를 감싸는 대괄호, 중괄호, 소괄호 또는 따옴표 한 쌍.
다만 짐작은 하지 않습니다. 그 밖의 문자나, 여덟 자리보다 길면서 온전한 바이트로 나뉘지 않는 그룹이 있으면 읽기가 멈추고, 페이지는 그 자리의 줄과 열을 밝혀 그렇다고 알리며, 그 아래에 그 자리를 표시한 여러분 자신의 줄을 보여 줍니다. 긴 메시지에서는 이것이 찾아낼 수 있는 오타와 조용히 틀린 텍스트의 차이입니다.
바이트로는 문제없이 읽히지만 UTF-8 텍스트가 아닌 2진수는 거부되지 않고 표시됩니다. 문자 한가운데에서 잘린 메시지는 깨진 시퀀스가 대체 문자인 U+FFFD로 표시된 채 돌아오고, 출력 아래의 알림이 그런 시퀀스가 몇 개인지와 첫 번째 것이 어디서 시작하는지를 알려 줍니다. 그 바이트, 여러분이 그것을 위해 붙여넣은 숫자, 그리고 그 줄과 열입니다.
텍스트의 2진수와 수의 2진수
여기에 5를 입력하면 답은 101이 아니라 00110101입니다. 이 페이지가 쓰는 것은 ASCII가 53번을 매긴 문자 5입니다. 텍스트의 숫자란 그 텍스트를 저장하는 바이트이기 때문입니다. 101은 수 5를 2진수로 쓴 것이고, 그것은 다른 답을 가진 다른 질문입니다. 255도 마찬가지입니다. 여기에 입력하면 세 문자, 3바이트이지만, 수 255는 11111111이라는 바이트 하나입니다.
가진 것이 텍스트가 아니라 수라면, 이를테면 개수, 레지스터, 프로그램이 출력한 값이라면, 가져갈 곳은 ‘진법 변환기’입니다. 그 페이지는 값 자체를 2진수, 8진수, 10진수, 16진수와 그 밖의 진법 사이에서 변환하며, 고정 폭에서는 음수를 2의 보수로 쓰고 모든 비트를 클릭해 뒤집을 수 있게 보여 줍니다. 이 페이지는 텍스트의 문자에서 출발하고, 저 페이지는 수에서 출발합니다.
자주 묻는 질문
- 제 이름을 2진수로 쓰려면 어떻게 하나요?
- 입력란에 입력하면 한 바이트씩, 바이트마다 여덟 자리로, 바이트 사이에 공백을 두고 나옵니다. 예를 들어 Ada는 01000001 01100100 01100001입니다. 악센트가 붙은 글자나 다른 알파벳의 글자는 2바이트 이상을 차지하고, 두 이름 사이의 공백도 그 자체로 한 바이트, 00100000입니다.
- 문자 하나는 몇 비트를 차지하나요?
- UTF-8에서는 ASCII 글자, 숫자, 문장 부호가 8비트, 악센트가 붙은 글자나 키릴·히브리·아랍 문자의 글자가 16비트, 일본어 가나와 자주 쓰는 한자, 한국어 한글, 유로 기호가 24비트, 대부분의 이모지가 32비트입니다. 하나의 기호로 보이는 것이 그 아래에서는 여러 코드 포인트일 수 있고, 그 각각이 제 비트를 차지합니다.
- 바이트 사이에 공백이 없는 2진수도 붙여넣을 수 있나요?
- 네, 숫자가 온전한 바이트로 나뉘는 곳이라면 어디서나 됩니다. 열여섯 자리는 2바이트, 스물네 자리는 3바이트입니다. 여덟 자리보다 길면서 길이가 8의 배수가 아닌 그룹은 어느 바이트가 자리를 잃었는지 짐작하지 않고는 나눌 수 없으므로, 잘못 읽히는 대신 그 줄과 열에서 거부됩니다.
- 왜 제 텍스트가 마름모 안의 물음표와 함께 돌아오나요?
- 그 기호는 대체 문자인 U+FFFD로, 바이트가 UTF-8 텍스트가 아닌 곳마다 페이지가 넣는 것입니다. 가장 흔한 것은 바이트가 사라져 문자가 중간에 잘린 경우이고, 아니면 바이트가 애초에 UTF-8이 아니었던 경우입니다. 페이지는 메시지 전체를 거부하는 대신 깨진 시퀀스를 하나하나 그렇게 보여 주고, 출력 아래에서 그것이 몇 개인지와 첫 번째 것이 어디서 시작하는지를 알려 주므로, 붙여넣은 것에서 손상된 곳을 찾을 수 있습니다.
- 다른 변환기는 왜 다른 2진수를 내놓나요?
- 아마 그 변환기는 각 문자의 바이트가 아니라 코드 포인트를 쓸 것입니다. 둘은 ASCII에서 앞의 0을 빼면 일치하고, 그 너머에서 갈라집니다. א는 여기서는 11010111 10010000이고 거기서는 10111010000입니다. 그 변환기의 답을 얻거나 그것이 쓴 메시지를 되읽으려면 ‘코드 포인트’를 고르세요.
- 여기서는 왜 5가 101이 아닌가요?
- 입력란에 입력한 5는 문자이고, 페이지는 그것을 저장하는 바이트인 00110101을 쓰기 때문입니다. 수 5는 2진수로 101입니다. 텍스트가 아니라 수라면 ‘진법 변환기’를 쓰세요.
- 제 텍스트가 서버로 전송되나요?
- 아니요. 두 방향 모두 전적으로 브라우저 안에서 실행되므로, 입력한 텍스트도 붙여넣은 2진수도 기기 밖으로 나가지 않습니다.
관련 도구
- 진법 변환기
이 페이지에 5를 입력하면 문자 5를 저장하는 바이트 00110101이 나옵니다. 저 페이지는 텍스트가 아니라 수를 위한 곳으로, 값 자체를 변환하므로 수 5는 101이 됩니다.
- 텍스트 / 16진수 변환
16진수는 바이트 하나를 두 자리로 쓰고, 2진수는 여덟 자리로 씁니다. Hi는 이 페이지에서 01001000 01101001로, 저 페이지에서 48 69로 쓰이며, 덤프는 바이트를 이렇게 보여 주고 코드도 이렇게 씁니다. 이 페이지에도 16진수가 있지만, 저 페이지는 16진수로 열립니다.
- Base64
Base64 인코딩과 디코딩 — UTF-8 완전 지원.
- URL 인코더 / 디코더
값이나 URL 전체를 퍼센트 인코딩, 그 반대도.