텍스트 ↔ Hex / 바이너리 변환기
텍스트를 16진·2진·10진 바이트로 변환하고 바이트 덤프를 다시 디코딩
로컬 실행
loading…
이 도구에 대해
텍스트가 정확히 어떤 바이트로 이루어졌는지 보세요. 이 도구는 텍스트를 UTF-8로 인코딩해 16진수, 2진수, 10진수 바이트 값으로 보여줍니다 — 구분자, 대소문자, 0x 접두사도 선택할 수 있습니다. 디코더는 반대 방향이며 의도적으로 관대합니다. 연속된 나열(48656c6c6f), 공백으로 나뉜 쌍, 콜론으로 구분된 MAC 스타일 표기, \x 이스케이프 시퀀스를 모두 받아들입니다.
인코딩이 바이트 수준의 UTF-8이므로 멀티바이트 문자는 메모리와 회선 위에 실제로 존재하는 그대로 표시됩니다. é는 c3 a9, 世는 e4 b8 96, 이모지는 4바이트를 차지합니다. 그래서 인코딩 불일치, BOM 미스터리, "왜 이 문자열이 보이는 것보다 길지" 문제를 디버깅하는 가장 빠른 길이 됩니다.
디코딩된 바이트가 유효한 UTF-8이 아니면 깨진 글자를 찍는 대신 그렇다고 알려줍니다 — 텍스트가 아니라 바이너리 데이터를 보고 있다는 강력한 힌트입니다.
자주 묻는 질문
- 왜 문자 하나가 여러 바이트가 되나요?
- UTF-8은 가변 폭입니다. ASCII는 1바이트로 남고, 대부분의 유럽 문자는 2바이트, CJK는 3바이트, 이모지는 4바이트입니다. 여기서 보는 것이 곧 파일, HTTP, 데이터베이스 등 모든 UTF-8 시스템이 여러분의 텍스트에 대해 저장하는 정확한 바이트 시퀀스입니다.
- 디코더는 어떤 입력 형식을 받아들이나요?
- 16진수는 연속 나열, 공백으로 나뉜 쌍, 0x나 \x 접두사, 콜론/쉼표 구분 모두. 2진수는 공백 유무와 무관한 8비트 묶음. 10진수는 구분된 바이트 값. 뒤섞인 구분자와 떠도는 공백은 자동으로 정리됩니다.
- 왜 디코딩이 바이트가 유효한 UTF-8이 아니라고 하나요?
- 바이트 시퀀스가 UTF-8 규칙을 위반한다는 뜻입니다 — 예를 들어 홀로 있는 ff나 선행 바이트 없는 연속 바이트. 데이터가 바이너리거나, Latin-1 같은 레거시 인코딩이거나, 문자 중간에서 잘렸을 수 있습니다.
- xxd의 16진 덤프와 같은 것인가요?
- 바이트 값은 동일합니다. xxd는 거기에 오프셋과 ASCII 열을 덧붙일 뿐입니다. xxd 덤프의 16진수 열들을(오프셋 열은 빼고) 여기 붙여넣으면 잘 디코딩됩니다.