파일 인코딩 감지기

브라우저는 chardet 안 갖춤, 일부 흔한 경우 위해 큰 인코딩 감지 라이브러리(ICU CharsetDetector JS 포트는 ~200KB) 임포트는 과함. 이 툴은 95% 경우 커버: BOM·ASCII만·유효 UTF-8·널 바이트 패턴으로 UTF-16. BOM 없는 이국적 아시아 인코딩(Shift_JIS·GB2312·EUC-KR)엔 chardet 필요 — 단 이 툴은 'UTF-8 아님'은 알려줘서 다른 곳 찾을 줄 알게 함.

Byte Order Mark는 인코딩을 명시적으로 표시하는 2-4 바이트 프리픽스. UTF-8 BOM은 EF BB BF(기술적 불필요, 논쟁적 — Microsoft 추가, Unix 도구는 보통 제거). UTF-16/32 BOM(FF FE 등)은 엔디언도 신호하기에 유용. 파일에 BOM 있으면 절대 신뢰.

그렇다면 파일은 UTF-8이 맞고, 그것을 읽는 프로그램이 UTF-8을 쓰지 않는 것이다. 이건 다른 문제이고 해법도 다르다. 로케일 설정, 가져오기 대화상자, 데이터베이스 연결의 문자셋 같은 것들이다. 탐지는 바이트가 무엇인지에 답할 뿐, 다음 프로그램을 동의하게 만들지는 못한다. 무언가를 다시 인코딩하기 전에 읽는 쪽이 무엇을 가정하는지 확인하라.

인코딩을 서로 구분해주는 문자가 들어 있을 만큼이면 된다. UTF-8은 여러 바이트로 이루어진 시퀀스 하나만 있어도 확인되므로, 짧은 파일이라도 그런 문자가 있으면 결론이 난다. 순수 ASCII 파일은 길이와 무관하게 진짜로 모호하다. 거의 모든 인코딩에서 유효하기 때문이다. 그리고 악센트 문자 하나가 든 짧은 한 줄이야말로 탐지기가 추측할 수밖에 없는 경우다.