각종 프로그램들 보면 이상하게
ANSI랑 UTF-8 문서를 구분 못한다 싶었는데
알고보니 둘다 BOM이 없고, 영문자같은 1바이트 문자만 있으면 똑같아서 그런거였네.
그러니 구분을 못했지 ㅅㅂ ㅋㅋㅋ
물론 UTF-8 BOM이 있는 경우는 UTF-8 로 구분하지만, 표준이 BOM이 없는거라매.
근데 편집기 따라서 기본값을 ANSI로 해놓은게 있고 UTF-8로 해놓은게 있더라고.
(윈도우 메모장도 윈10부터 UTF-8 No BOM이 기본값. 심지어 무려 윈8.1까지도 No BOM 저장 자체가 없음)
그래서 코드나 문서를
영문만 써놨다가 한글을 넣으면서 여러 편집기 거치다 보면, 어느순간 한글 씹창나 있는거였음 ㅋㅋㅋㅋ
아니 시발 당연히 BOM이 표준이 되어야 정상 아니냐?
왜 이 지랄인거 ㅋㅋㅋㅋㅋㅋㅋ
실제로 ANSI(정확히는 CP1252 같은 특정 코드페이지 기반 인코딩)와 UTF-8 문서는 영문자 범위에서 아무런 차이가 없다. 결국 파일 자체를 들여다봤을 때 BOM(Byte Order Mark)이 없는 UTF-8 문서와 ANSI 문서는 바이트 레벨에서 구분이 불가능하다. 그래서 에디터나 특정 툴 입장에서도 이걸 뭐라고 딱 잘라 구분하기가 쉽지 않다. 프로그램이 언어 환경이나 시스템 설정에 따라 "이 파일은 ANSI일 것이다" 혹은 "UTF-8일 것이다"라고 추측하는 수밖에 없는데, 여기서 추측이 빗나가면 글자가 깨지는 상황이 벌어진다.
UTF-8 BOM을 파일 맨 앞에 넣으면 "이거 UTF-8이야"라고 명확히 알 수 있어서 좋긴 하다. 그런데 원래 UTF-8 표준 자체가 BOM을 강제하지 않는다. UTF-8이 “바이트 순서”에 구애받지 않는 인코딩이라는 점 때문에 BOM을 붙이는 게 딱히 필수적이지 않았기 때문이다. 그래서 유닉스 철학 따르는 쪽(리눅스, macOS 등)에서는 BOM 없는 UTF-8을 많이 써왔다.
반면 윈도우 계열 편집기는 BOM 유무에 민감하고, 오래된 메모장은 ANSI를 기본값으로 하거나, UTF-8이어도 BOM이 없으면 ANSI로 읽으려는 경향을 보였다. 윈도우10 이후 메모장이 UTF-8 No BOM을 기본값으로 바꾼 것도 이 혼란을 줄이려는 움직임의 하나였다.
결국 "왜 BOM이 표준이 아니냐"라는 질문은 UTF-8이 언어, 문자 순서에 독립적인 설계 철학을 따르다 보니 굳이 BOM을 강제하지 않은 역사적 배경이 있다. 서로 다른 운영 체제와 다양한 편집기들이 오랫동안 쌓아온 관행과 호환성 문제가 섞이며, 이렇게 복잡하고 짜증스러운 상황이 되어버린 것이다. 한마디로 과거의 호환성과 현재의 국제 표준, 그리고 각 플랫폼의 선택이 뒤엉켜서 생긴 난장판에 가깝다.
처음부터 BOM 없이 쓰려고 한 놈들이 개쉑들 ㅅㅂ ㅋㅋㅋ 인코딩이 다른거 알면 나중에 나온게 BOM을 만들어야지. 아무려면 ANSI가 먼저지 UTF-8이 먼저겠노? ㅋㅋㅋㅋㅋㅋㅋㅋ