BOM
바이트 순서 표시 (Byte Order Mark) 는 유니코드 문자로, 매직 넘버로서 문서의 가장 앞에 추가하여 텍스트를 읽는 프로그램에 여러 정보를 전달할 수 있다.
BOM을 반드시 사용할 필요는 없으며, 사용할 경우 문서의 가장 앞에 등장해야 한다.
BOM의 바이트열은 유니코드 인코딩마다 다르며, 이들이 다른 인코딩으로 저장된 문서의 가장 앞에 등장할 가능성은 적다.
그러므로, 문서의 가장 앞에 인코딩된 BOM을 추가함으로써 텍스트가 유니코드임을 나타내고 그 인코딩 방식을 명시할 수 있다.
UTF-8
BOM의 UTF-8 표현은 바이트열인 0xEF, 0xBB, 0xBF 이다.
유니코드 표준은 UTF-8에 BOM을 허용하지만, 이는 필수가 아니며 권장 사항도 아니다.
UTF-8에서 바이트 순서는 어떤 의미도 없으므로 UTF-8 내에서는 문서의 가장 앞에서 문서가 UTF-8로 인코딩되었거나, BOM이 있는 문서가 UTF-8로 변환된 것을 표시하는 이외의 용도는 없다. 또한 표준에서는 BOM이 존재하는 경우 다른 인코딩으로 변환했다가 되돌릴 때 정보가 손실되지 않고, 이에 의존하는 코드가 계속 작동하도록 제거하지 않는 것을 권장한다.
UTF-16
BOM(U+FEFF)은 파일의 첫 번째 문자로 배치되어 그 파일의 모든 16비트 코드 단위의 엔디언(바이트 순서)을 나타낼 수 있다. 이 스트림을 잘못된 엔디언으로 읽으려고 하면 바이트가 뒤집혀 문자 U+FFFE를 읽을 수 있으며, 이는 유니코드에서 텍스트에 등장해서는 안 되는 "비문자"(non-character)로 정의되어 있다.
UTF-16을 바이트 기반 인코딩으로 해석하는 프로그램은 무의미한 문자열을 표시하지만, UTF-16 표현의 하위 바이트가 ASCII 코드와 같으므로 ASCII 문자는 알아볼 수 있다. 상위 바이트 0은 공백이나 점 등 일정한 문자로 표시되거나 아예 표시되지 않을 수도 있다.
UTF-32
BOM을 사용할 수는 있지만, 이 인코딩은 전송에 거의 사용되지 않는다.
이 이외에는 UTF-16과 동일한 규칙이 적용된다. 리틀 엔디언 UTF-32에서의 BOM 패턴은 리틀 엔디언 UTF-16에서 BOM 다음에 널 문자가 오는 것과 같으며, 이와 같이 서로 다른 인코딩에서 BOM 패턴이 같은 경우는 드물다. BOM을 이용해 인코딩을 추론하는 경우 문서가 UTF-32인지 널 문자로 시작하는지를 결정해야 한다.
'Computer > Front-End' 카테고리의 다른 글
[JavaScript] 📚 Date 문법 / 날짜 문법 / 자바스크립트 날짜 / Intl (1) | 2022.10.11 |
---|---|
[JavaScript] 📚 배열 음수 인덱스 사용하기 / 파이썬처럼 배열 사용하기 / at() / 최신 문법 / Array / index (0) | 2022.10.11 |
[React] 📚 리액트 생성 후 필요 없는 것들 정리하기 (0) | 2022.10.04 |
[Java] Swing / UI / 자바 / 스윙 / 자바 스윙 / Java Swing (0) | 2022.10.04 |
[React] 리액트가 라이브러리인 이유? 라이브러리 vs 프레임워크 (0) | 2022.09.26 |