인코딩·문자셋
16진수 바이트를 UTF-8 문자로 확인하기
사용할 도구
로그에 글자 대신 e3 81 82가 있으면 16진수라는 사실만으로 세 바이트가 한 글자인지 여러 글자인지 알 수 없습니다. 문자 인코딩이 필요하며 텍스트·바이트 도구는 UTF-8을 사용합니다. 알고 있는 짧은 글자부터 대응을 확인하세요.
あ를 세 바이트로 바꾸기
あ16진수 e38182(여기서 나눠 쓰면 e3 81 82), 2진수 11100011 10000001 10000010, 길이 3바이트가 나옵니다. 같은 데이터를 다른 진법으로 쓴 것이며 16진수 두 자리나 2진수 여덟 자리가 한 바이트입니다. 표시 공백은 바이트 구분이지 원문 공백이 아닙니다.
복원에서 16진수를 선택하고 결과 JSON이나 필드명이 아닌 hex 바이트만 넣으면 あ로 돌아옵니다. 2진수 복원에는 해당 여덟 자리 묶음을 넣어야 하며 선택만 바꾼다고 입력 표기가 변환되지는 않습니다.
영문, 일본어, 이모지를 하나씩 더하기
Aあ😀A는 41 한 바이트, あ는 세 바이트, 😀는 f0 9f 98 80 네 바이트로 총 여덟 바이트입니다. 하나씩 지워 변화를 보고 문자 수 도구에서 표시 문자, 코드 포인트, UTF-16 단위, UTF-8 바이트를 비교하세요.
여덟 바이트는 16진수 열여섯 자리지만 원본이 열여섯 바이트가 된 것은 아닙니다. 그 표기를 텍스트 파일로 저장하면 별도 용량이 생깁니다. 로그나 제한을 볼 때 실제 바이트와 진단 문자열 길이를 구분하세요.
바이트를 중간에서 자르면 문자가 깨집니다
e3 81마지막 82를 빼면 불완전한 UTF-8이라 복원이 실패합니다. 임의 바이트로 오류를 없애도 원문 복구는 아닙니다. 로그나 전송이 잘랐다면 원본이 남은 곳으로 돌아가세요. 조용히 대체 문자로 바꾸지 않는 것이 손상을 찾는 단서입니다.
16진수 자릿수가 홀수이거나 g 같은 문자가 있으면 문자 해석 전에 바이트 표기부터 잘못된 것입니다. 표기와 UTF-8 유효성을 순서대로 확인해 전사 실수, 잘림, 인코딩 차이를 구분하세요.
읽히지 않는다고 암호화는 아닙니다
여기서는 UTF-8로 읽으며 압축 데이터, 이미지, 암호문, 임의 인코딩을 추정해 복원하지 않습니다. 원래 인코딩을 알면 문자 인코딩 변환을 쓰세요. 여러 추측 끝에 읽을 만한 글자가 나왔다고 정답이 확정되지는 않습니다.
U+3042는 코드 포인트이지 e3 81 82라는 UTF-8 바이트가 아닙니다. 3042를 16진수 바이트로 넣어도 あ가 되지 않습니다. 로그 필드가 문자 번호인지 인코딩 바이트인지 확인한 뒤 도구를 고르세요.
보이지 않는 줄바꿈도 바이트입니다
A는 41, LF를 붙이면 41 0a, CRLF면 41 0d 0a입니다. 비슷하게 보여도 해시·서명 입력은 다릅니다. 줄바꿈을 지우기 전에 끝 바이트를 확인해야 원래 차이의 증거를 잃지 않습니다.
원문, UTF-8이라는 근거, 표기 방식, 예상 길이를 남기세요. 비슷한 모양은 바이트 일치를 보장하지 않고 다른 바이트는 정규화 차이일 수도 있습니다. 바이트 비교와 사람이 읽는 동등성을 나누면 다음 도구를 고르기 쉽습니다.