바이트만 제거하지 않고 파일 전체를 재인코딩하기
UTF-16이나 UTF-32 파일을 브라우저 텍스트로 읽은 뒤 UTF-8로 저장하면 모든 코드 단위의 바이트 표현이 달라집니다. 파일 모드는 선두 서명 바이트만 제거하고 나머지 바이트 배열을 보존합니다.
UTF-8·UTF-16·UTF-32 파일의 BOM 제거
텍스트브라우저에서 실행(업로드 없음)
파일의 선두 바이트에서 UTF-8, UTF-16 LE/BE, UTF-32 LE/BE 바이트 순서 표시(BOM)를 검사하고, 일치한 서명만 제거한 뒤 나머지 바이트를 디코딩하거나 재인코딩하지 않고 다운로드합니다. 별도의 디코딩 텍스트 모드는 선두 U+FEFF 문자 하나만 처리하며 결과가 UTF-8로 저장됨을 명확히 구분합니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기
보이지 않는 선두 서명 때문에 첫 CSV 헤더나 script token이 달라질 때 사용합니다. 원본 바이트에서 작업하고 UTF-32 LE를 UTF-16 LE 접두부와 구분하며, 대상 시스템이 확인되기 전에는 UTF-16·UTF-32의 바이트 순서 증거를 지우지 않습니다.
열기관련 도구바이트 증거로 텍스트 파일 인코딩 감지
로컬 파일 바이트에서 BOM, 엄격한 UTF-8, Unicode 구조, ASCII 호환성, 바이너리 단서를 검사합니다.
열기관련 도구CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
열기관련 도구CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
열기이 도구 사용 방법
원본 파일이 있으면 파일 바이트를 선택하고, 다른 프로그램이 이미 디코딩한 문자열만 있을 때에만 디코딩 텍스트를 선택합니다.
25 MiB 이하 파일 하나를 선택하거나 내장 UTF-8 BOM CSV 샘플을 불러옵니다.
파일을 선택했다는 이유만으로 바이트가 삭제되지 않도록 검사·제거 버튼을 직접 실행합니다.
판별된 인코딩 레이블, 서명 길이, 처리 전후의 선두 바이트 증거를 확인합니다.
UTF-16이나 UTF-32라면 대상 시스템이 LE 또는 BE 순서를 이미 아는지 다운로드 전에 확인합니다.
변경된 파일을 다운로드한 뒤 대상 importer나 parser에서 첫 필드·첫 token과 인코딩 계약을 다시 검증합니다.
이 도구를 써야 할 때
UTF-8 CSV 헤더 복구
CSV importer가 첫 헤더를 숨은 접두부가 붙은 다른 필드로 읽을 때 EF BB BF만 제거하고 이후 모든 행 바이트를 보존합니다.
필수 첫 token 복원
#!, { 같은 ASCII token이 반드시 0번 바이트에 있어야 하는 UTF-8 shell·Node·Python·설정 파일을 준비합니다.
명시적인 바이트 순서 계약 충족
수신 인터페이스가 UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE를 이미 명시한 경우 불필요하다고 확인된 서명을 제거합니다.
import 결과물 검토
ETL이나 데이터베이스 import에 복구 파일을 넘기기 전에 전후 hex 접두부로 정확히 어떤 바이트가 달라졌는지 기록합니다.
이미 디코딩된 텍스트 정리
복사한 문자열에서 디코딩된 선두 U+FEFF 하나를 검사하고 이후 U+FEFF는 별도의 Unicode 검토를 위해 보존합니다.
흔한 실수
대상 규칙을 확인하지 않고 바이트 순서 정보 지우기
레이블이 없는 UTF-16·UTF-32 스트림에서는 BOM이 유일한 바이트 순서 신호일 수 있습니다. 대상 시스템이 정확한 LE 또는 BE 인코딩을 이미 요구하거나 알고 있을 때만 제거해야 합니다.
본문 중간의 일치 바이트까지 삭제하기
BOM은 0번 바이트의 서명입니다. 본문 중간의 U+FEFF나 BOM과 닮은 바이트는 파일 메타데이터가 아니라 실제 데이터일 수 있으므로 그대로 보존합니다.
BOM 없음 결과를 인코딩 판정으로 해석하기
BOM이 없다고 해서 파일이 UTF-8, ASCII 또는 특정 인코딩이라는 뜻은 아닙니다. 이 도구는 지원하는 선두 서명만 판별하며 표시가 없는 파일의 문자셋을 추측하지 않습니다.
불완전한 서명을 추측으로 복구하기
EF BB까지만 있는 접두부는 손상된 UTF-8 서명일 수도 있고 일반 비텍스트 바이트일 수도 있습니다. 도구는 잘린 서명 가능성을 알리고 아무 바이트도 제거하지 않습니다.
예시
UTF-8 CSV에서 EF BB BF 제거
CSV 헤더 앞의 UTF-8 서명 3바이트만 제거하고 id,name에 해당하는 나머지 바이트는 그대로 둡니다.
입력
EF BB BF 69 64 2C 6E 61 6D 65출력
69 64 2C 6E 61 6D 65UTF-32 LE와 UTF-16 LE 구분
UTF-32 LE의 4바이트 서명을 먼저 확인해야 앞의 FF FE를 UTF-16 LE로 오인하지 않습니다. 뒤의 UTF-32 LE 바이트는 디코딩하지 않습니다.
입력
FF FE 00 00 69 00 00 00 64 00 00 00출력
69 00 00 00 64 00 00 00바이트를 보존하는 BOM 제거 방식
지원 서명은 UTF-8의 EF BB BF, UTF-16 BE·LE의 FE FF와 FF FE, UTF-32 BE·LE의 00 00 FE FF와 FF FE 00 00입니다.
UTF-32 LE는 FF FE로 시작하므로 4바이트 UTF-32 서명을 2바이트 UTF-16 서명보다 먼저 검사합니다. 이렇게 해야 접두부 충돌로 표시의 절반만 지우는 오류를 막을 수 있습니다.
파일 모드는 Uint8Array에서 동작합니다. TextDecoder, TextEncoder, Unicode 정규화, 줄바꿈 변환, trim 없이 서명 다음 바이트 범위를 결과로 복사합니다.
디코딩 텍스트 모드는 계약이 다릅니다. 첫 UTF-16 코드 단위가 U+FEFF인지 확인하고 짝이 없는 surrogate를 거부하며 선두 문자 하나만 제거한 뒤 UTF-8로 저장합니다.
불완전한 접두부는 변경 허가가 아니라 검토 증거입니다. 짧은 스트림이 지원 서명의 앞부분과만 일치하면 결과를 바이트 단위로 그대로 두고 경고합니다.
브라우저 입력 한도는 파일 26,214,400바이트, 디코딩 텍스트 1,048,576 UTF-8바이트입니다. 일반 처리에서 데이터는 기기에 남고 집계 분석에는 이름과 내용이 포함되지 않습니다.
자주 묻는 질문
어떤 BOM 서명을 지원하나요?
파일 모드는 0번 바이트에서 UTF-8 EF BB BF, UTF-16 BE FE FF, UTF-16 LE FF FE, UTF-32 BE 00 00 FE FF, UTF-32 LE FF FE 00 00의 다섯 Unicode 서명을 인식합니다.
파일 모드가 파일을 UTF-8로 변환하나요?
아닙니다. 파일을 ArrayBuffer로 읽고 판별된 선두 바이트만 제외한 나머지를 다운로드에 넣습니다. 파일을 디코딩하거나 정규화하거나 줄바꿈을 바꾸거나 다시 인코딩하지 않습니다.
디코딩 텍스트 모드를 파일 모드와 분리한 이유는 무엇인가요?
텍스트 상자는 다른 프로그램이 이미 디코딩한 문자를 받습니다. 선두 U+FEFF 하나는 제거할 수 있지만 원본 파일의 UTF-16·UTF-32 바이트 순서를 복원할 수 없으며 다운로드는 UTF-8입니다.
UTF-16이나 UTF-32 BOM을 제거해도 안전한가요?
수신 파서가 BOM 없는 UTF-16을 요구하거나 charset 레이블·파일 계약으로 바이트 순서를 이미 알고 있을 때만 안전합니다. 그렇지 않으면 BOM 제거 후 레이블 없는 UTF-16·UTF-32 스트림의 순서가 모호해질 수 있습니다.
BOM이 없으면 UTF-8 파일인가요?
아닙니다. 다섯 지원 서명 중 어느 것도 0번 바이트에서 발견되지 않았다는 뜻일 뿐입니다. 표시 없는 파일의 문자셋 판별은 별도의 휴리스틱 작업입니다.
본문 중간의 U+FEFF도 제거하나요?
제거하지 않습니다. 선두가 아닌 U+FEFF는 본문 또는 과거의 단어 결합 데이터일 수 있습니다. 코드 포인트 단위 검토가 필요하면 Unicode 검사 도구를 사용해야 합니다.
파일 내용이 업로드되거나 분석 이벤트에 포함되나요?
일반 작업에서 선택한 파일은 브라우저 안에서 읽고 처리합니다. 집계 이벤트에는 모드, 바이트 수, 판별 서명 종류, 성공·실패만 기록할 수 있으며 파일 이름, 파일 바이트, 붙여넣은 텍스트와 출력은 포함하지 않습니다.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: “데이터베이스 import 전 UTF-8 BOM CSV 복구” 문서 입력을 UTF-8·UTF-16·UTF-32 파일의 BOM 제거에 그대로 넣었습니다. 수행 순서는 “텍스트를 열어 다시 저장하지 말고 파일 바이트 검사하기”, “없거나 불완전한 서명을 보수적으로 처리하기”였고 브라우저 결과를 예시 출력과 대조했습니다. 실패 경계는 “원본 파일이 있는데 디코딩 텍스트 모드 사용하기”, “UTF-32 LE 확인 전에 FF FE만 제거하기” 두 항목으로 나눠 검토했습니다.
기대 결과: EF BB BF만 제거하자 파일은 34바이트에서 31바이트가 되고 id가 첫 header byte가 됐으며, 나머지 CSV를 디코딩 후 재작성하지 않았습니다.
공식 출처와 표준
- Encoding StandardWHATWG
관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
재인코딩 없이 CSV·텍스트 파일의 BOM 제거하기
보이지 않는 선두 서명 때문에 첫 CSV 헤더나 script token이 달라질 때 사용합니다. 원본 바이트에서 작업하고 UTF-32 LE를 UTF-16 LE 접두부와 구분하며, 대상 시스템이 확인되기 전에는 UTF-16·UTF-32의 바이트 순서 증거를 지우지 않습니다.
작업 가이드가져오기 전 텍스트 파일 인코딩 감지하기
원본 파일 바이트로 확정된 Unicode 서명과 구조 증거, 보수적 추정을 분리합니다. 후보 decoder가 알려진 header와 다국어 값을 올바르게 복원하는지 소량 가져오기에서 확인한 뒤 전체 작업을 진행합니다.
작업 가이드원본 파일 바이트에서 깨진 텍스트 복구하기
문자셋 감지는 decoder 후보를 좁힐 뿐 이미 깨진 문자열을 자동 복원하지 않습니다. 원본을 보존하고 잘못된 디코딩 경계를 찾은 뒤 통제된 preview를 비교하고, 알려진 값의 왕복 검증이 끝난 경우에만 한 번 변환합니다.
작업 가이드Git과 셸 스크립트에서 CRLF를 LF로 안전하게 변환하기
Windows에서 편집한 스크립트가 Linux에서 실패하거나 Git이 파일 전체의 줄바꿈 변경을 표시하거나 생성 텍스트에 CRLF와 LF가 섞였을 때 사용하는 복구 절차입니다. 먼저 검사하고 확인된 텍스트만 통일한 뒤 저장소 설정으로 결정을 유지합니다.
작업 가이드제로 폭 문자를 제거하기 전에 위치와 의미 검사하기
화면에는 같은 두 값이 비교, 검색, 줄바꿈, 파싱, 표시에서 다르게 동작할 때 사용하는 절차입니다. 수정 전에 지원 제어 문자를 찾고 일반 숨은 구분자와 문자 결합 및 줄바꿈 제어를 구분하며, 줄바꿈과 정규화 상태를 그대로 둔 채 각 제거가 안전한 이유를 기록합니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
바이트 증거로 텍스트 파일 인코딩 감지
로컬 파일 바이트에서 BOM, 엄격한 UTF-8, Unicode 구조, ASCII 호환성, 바이너리 단서를 검사합니다.
인코딩
CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
변환
CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
텍스트
Unicode 정규화 | NFC·NFD·NFKC·NFKD 비교
코드 포인트 근거와 호환 손실 경고를 제공하는 Unicode 정규화 도구입니다.
인코딩
제로 폭 문자를 안전하게 검사하고 제거하기
제로 폭 제어 문자 6종의 위치를 찾고 승인한 종류만 제거합니다.
텍스트