ASCII 호환 바이트를 확정 인코딩으로 해석하기
16진수 80 미만의 표시 가능한 바이트는 ASCII, UTF-8, 여러 레거시 인코딩에서 같습니다. 이 바이트만으로 원래 문자셋을 복원할 수 없습니다.
바이트 증거로 텍스트 파일 인코딩 감지
인코딩브라우저에서 실행(업로드 없음)
가져오기 전에 파일의 실제 바이트를 검사합니다. 5가지 BOM 서명으로 UTF-8·UTF-16·UTF-32를 확인하고, 엄격한 UTF-8 구조와 ASCII 호환성, NUL 배치에 따른 BOM 없는 Unicode 추정, 레거시 텍스트와 바이너리 의심 데이터를 구분합니다. 파일은 업로드하거나 변경하지 않습니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기
보이지 않는 선두 서명 때문에 첫 CSV 헤더나 script token이 달라질 때 사용합니다. 원본 바이트에서 작업하고 UTF-32 LE를 UTF-16 LE 접두부와 구분하며, 대상 시스템이 확인되기 전에는 UTF-16·UTF-32의 바이트 순서 증거를 지우지 않습니다.
열기관련 도구UTF-8·UTF-16·UTF-32 파일의 BOM 제거
나머지 내용을 재인코딩하지 않고 파일 선두의 지원 BOM 하나만 정확한 바이트에서 제거합니다.
열기관련 도구CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
열기관련 도구CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
열기이 도구 사용 방법
편집기에서 열고 저장하면 검사할 바이트가 바뀔 수 있으므로 손대지 않은 원본 파일을 보관합니다.
25 MiB 이하 파일 하나를 선택하거나 내장 UTF-16LE BOM CSV 예시를 불러옵니다.
파일 선택만으로 분류가 실행되지 않도록 검사 버튼을 직접 누릅니다.
확정, 강한 증거, 호환, 추정, 미확정으로 구분된 증거 강도를 결과 분류와 함께 읽습니다.
선두 16진수 바이트, 엄격한 UTF-8 결과, Unicode 구조, NUL·제어 바이트 수를 확인합니다.
후보 인코딩으로 목적지의 소량 가져오기를 실행하고 알려진 텍스트를 확인한 뒤 전체 파일을 변환합니다.
이 도구를 써야 할 때
CSV 가져오기 인코딩 선택
스프레드시트, 데이터베이스, ETL이 header나 다국어 field를 바꾸기 전에 손대지 않은 export를 검사합니다.
변환 전 텍스트 파일 감사
저장소를 이전하기 전에 source, config, subtitle, 번역 파일이 엄격한 UTF-8인지 확인합니다.
BOM 관련 parser 실패 검토
목적지가 서명을 유지해야 하는지 제거해야 하는지 정하기 전에 정확한 BOM과 구조 증거를 기록합니다.
알 수 없는 첨부 파일 분류
통제된 decoder 후보를 시도하기 전에 레거시 텍스트 가능성과 바이너리 의심 데이터를 구분합니다.
원본 바이트에서 문자 깨짐 진단
바이트 보고서가 범위를 좁힌 뒤 알려진 이름, header, delimiter로 decoder 결과를 확인합니다.
흔한 실수
BOM이 파일 전체의 유효성을 보장한다고 보기
BOM은 의도한 Unicode 인코딩 방식을 식별하지만, 뒤의 스트림에는 홀수 길이, 짝이 없는 surrogate, 잘못된 scalar 값이 남아 있을 수 있습니다.
고위 바이트 하나로 레거시 문자셋 이름 붙이기
Windows-1252, ISO-8859 계열, Shift_JIS 등은 바이트가 겹칠 수 있습니다. UTF-8이 아니라는 사실만으로 하나를 지목할 수 없습니다.
NUL 패턴 추정을 확정 결과로 사용하기
NUL 배치는 ASCII 비중이 높은 UTF-16·UTF-32에서 유용하지만, CJK 중심이거나 짧고 BOM 없는 파일은 뚜렷한 lane 패턴이 없을 수 있습니다.
원본 바이트 검사 전에 깨진 텍스트 저장하기
문자 깨짐은 이미 잘못 디코딩된 텍스트입니다. 깨진 화면을 다시 저장하면 올바른 decoder를 고르는 데 필요한 원본 증거가 사라질 수 있습니다.
예시
다국어 UTF-8 바이트 검증
ASCII 밖의 바이트열이 엄격한 UTF-8 범위를 통과하며 BOM은 없습니다.
입력
EC 84 9C EC 9A B8 2C 5A C3 BC 72 69 63 68출력
UTF-8 | 강한 증거 | BOM 없음UTF-32LE와 UTF-16LE 구분
4바이트 서명을 FF FE인 UTF-16LE 접두사보다 먼저 검사해야 합니다.
입력
FF FE 00 00 69 00 00 00 64 00 00 00출력
UTF-32 LE | BOM 확정 | 구조 유효증거 기반 문자셋 검사의 동작 방식
0번 바이트에서 EF BB BF, FE FF, FF FE, 00 00 FE FF, FF FE 00 00을 식별합니다. UTF-32LE의 4바이트 서명이 FF FE로 시작하므로 UTF-16LE보다 먼저 검사합니다.
엄격한 UTF-8 검증은 well-formed sequence 범위를 따릅니다. C0·C1 overlong lead, E0·F0 하한 위반, ED surrogate 표현, U+10FFFF를 넘는 F4 범위를 거부합니다.
BOM은 서명 증거이지 전체 유효성 보장이 아닙니다. 나머지 UTF-16은 완전한 2바이트 unit과 올바른 surrogate pair여야 하고, UTF-32는 D800-DFFF 밖이면서 10FFFF 이하인 완전한 scalar여야 합니다.
BOM이 없으면 UTF-32를 UTF-16보다 먼저 검토하고 endian별 반복 NUL lane과 유효한 code unit 구조를 함께 요구합니다. 짧거나 CJK 비중이 높은 스트림은 바이트 증거가 부족해 미확정으로 남을 수 있습니다.
표시 가능한 ASCII 범위 데이터는 같은 바이트가 UTF-8과 여러 레거시 인코딩에도 존재하므로 ASCII 호환으로 표시합니다. UTF-8이 아니면서 제어 바이트가 적은 경우도 특정 문자셋 대신 미확정 레거시·단일 바이트 후보로 둡니다.
신뢰할 Unicode lane을 만들지 않는 NUL과 의심스러운 C0 제어 바이트는 바이너리 경고를 냅니다. 26,214,400바이트 상한으로 브라우저 메모리와 처리량을 제한하며, 정상 검사는 로컬에서 실행되고 분석에는 이름과 내용이 들어가지 않습니다.
자주 묻는 질문
선택한 파일이 서버로 업로드되나요?
아니요. 선택한 파일은 브라우저에서 ArrayBuffer로 읽습니다. 집계 분석에는 바이트 수, 결과 분류, 증거 유형, BOM 종류, 경고 수만 기록할 수 있으며 파일명과 파일 바이트는 포함하지 않습니다.
ASCII 호환 결과면 ASCII로 저장된 파일인가요?
아니요. ASCII 전용 스트림은 유효한 UTF-8이기도 하고 여러 단일 바이트 인코딩에서도 같습니다. 그래서 원본 문자셋을 지어내지 않고 ASCII 호환이라고 표시합니다.
엄격한 UTF-8 검증은 무엇을 확인하나요?
예상하지 않은 continuation byte, 잘린 sequence, overlong form, surrogate code point의 UTF-8 표현, U+10FFFF를 넘는 값을 거부합니다. 비ASCII 스트림이 모두 통과하면 강한 UTF-8 증거로 봅니다.
어떤 BOM 서명을 인식하나요?
EF BB BF는 UTF-8, FE FF는 UTF-16BE, FF FE는 UTF-16LE, 00 00 FE FF는 UTF-32BE, FF FE 00 00은 UTF-32LE입니다. 접두사 충돌을 막기 위해 4바이트 서명을 먼저 확인합니다.
BOM 없이 UTF-16이나 UTF-32를 감지할 수 있나요?
추정만 가능합니다. 길이가 충분하고 ASCII 비중이 높은 데이터에서 반복되는 NUL 위치가 LE·BE 직렬화를 시사하고, 해당 UTF-16·UTF-32 구조도 유효해야 합니다. 이 결과는 확정으로 표시하지 않습니다.
모든 레거시 인코딩을 식별할 수 있나요?
아니요. 엄격한 UTF-8이 아니면서 바이너리 증거가 약한 단일 바이트 텍스트 후보인지는 보여 주지만, 외부 맥락 없이 Windows-1252, ISO-8859-1, Shift_JIS 등을 확정하지 않습니다.
이 결과만 보고 바로 가져와도 되나요?
아니요. 결과로 decoder 후보를 고른 뒤 목적지에서 알고 있는 header, 이름, delimiter, replacement character를 검증하세요. 왕복 검증이 끝날 때까지 원본 파일을 보관해야 합니다.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: 바이트 증거로 텍스트 파일 인코딩 감지에서 “UTF-32LE 내보내기를 UTF-16LE 접두사와 구분” 픽스처를 임의로 고치거나 단순화하지 않고 실행했습니다. “정확한 바이트를 수동 검사”에서 “모호한 결과를 그대로 유지”로 이어지는 결과를 대조했습니다. 비성공 경로 검토에는 “ASCII 호환을 ASCII 원본으로 해석”, “Continuation 형태만 보고 UTF-8 허용” 조건을 사용했습니다.
기대 결과: 4바이트 FF FE 00 00 표식과 code unit 구조로 UTF-32LE를 판별했고, 더 짧은 UTF-16LE 접두사만 보고 검사를 끝내지 않았습니다.
공식 출처와 표준
- Encoding StandardWHATWG
관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기
보이지 않는 선두 서명 때문에 첫 CSV 헤더나 script token이 달라질 때 사용합니다. 원본 바이트에서 작업하고 UTF-32 LE를 UTF-16 LE 접두부와 구분하며, 대상 시스템이 확인되기 전에는 UTF-16·UTF-32의 바이트 순서 증거를 지우지 않습니다.
작업 가이드가져오기 전 텍스트 파일 인코딩 감지하기
원본 파일 바이트로 확정된 Unicode 서명과 구조 증거, 보수적 추정을 분리합니다. 후보 decoder가 알려진 header와 다국어 값을 올바르게 복원하는지 소량 가져오기에서 확인한 뒤 전체 작업을 진행합니다.
작업 가이드원본 파일 바이트에서 깨진 텍스트 복구하기
문자셋 감지는 decoder 후보를 좁힐 뿐 이미 깨진 문자열을 자동 복원하지 않습니다. 원본을 보존하고 잘못된 디코딩 경계를 찾은 뒤 통제된 preview를 비교하고, 알려진 값의 왕복 검증이 끝난 경우에만 한 번 변환합니다.
작업 가이드스프레드시트용 CSV를 JSON으로 변환하기
스프레드시트 내보내기를 API용 JSON이나 테스트 fixture로 바꿀 때 원본 텍스트를 보존하고 경고와 행·열 수까지 확인하는 작업 흐름입니다.
작업 가이드CSV와 JSON 변환 오류 고치기
스프레드시트 내보내기, API fixture, CSV/JSON 전달 과정에서 열이 밀리거나 헤더가 사라지거나 JSON이 파싱되지 않을 때 원인을 좁히는 흐름입니다.
작업 가이드데이터 전달용 바이너리-텍스트 인코딩 선택하고 검증하기
API, 데이터베이스 필드, DNS 레이블, 이메일 본문, 설정 파일, 레거시 전송 규칙이 Base32·Base58·Base62·Base85·16진수·엔티티·Punycode·quoted-printable·UTF-16·UUEncode를 요구하지만 변형을 충분히 설명하지 않을 때 사용하는 흐름입니다.
작업 가이드Git과 셸 스크립트에서 CRLF를 LF로 안전하게 변환하기
Windows에서 편집한 스크립트가 Linux에서 실패하거나 Git이 파일 전체의 줄바꿈 변경을 표시하거나 생성 텍스트에 CRLF와 LF가 섞였을 때 사용하는 복구 절차입니다. 먼저 검사하고 확인된 텍스트만 통일한 뒤 저장소 설정으로 결정을 유지합니다.
작업 가이드시스템 간 텍스트 비교 전에 Unicode 정규화하기
신뢰할 수 있는 Unicode 정규화 작업은 원본 표현을 보존하고 대상 시스템의 계약을 확인한 뒤 정준 정규화와 호환 접기를 구분합니다. 정확한 코드 포인트와 숨은 문자를 검사하고, 완성된 값을 비교한 다음 실제 저장·조회 환경에서 다시 검증합니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
UTF-8·UTF-16·UTF-32 파일의 BOM 제거
나머지 내용을 재인코딩하지 않고 파일 선두의 지원 BOM 하나만 정확한 바이트에서 제거합니다.
텍스트
CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
변환
CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
텍스트
Unicode 정규화 | NFC·NFD·NFKC·NFKD 비교
코드 포인트 근거와 호환 손실 경고를 제공하는 Unicode 정규화 도구입니다.
인코딩
제로 폭 문자를 안전하게 검사하고 제거하기
제로 폭 제어 문자 6종의 위치를 찾고 승인한 종류만 제거합니다.
텍스트