바이트 순서 표시 사용
유니코드 텍스트 파일은 UTF-8, UTF-16 및 UTF-32를 비롯한 여러 형식으로 인코딩될 수 있습니다. 이러한 각 형식은 텍스트를 쓸 때 사용되는 바이트 순서를 나타내는 BOM(바이트 순서 표시)을 접두사로 사용할 수 있습니다. 사용 가능한 바이트 순서 표시는 다음 표에 나와 있습니다. UTF-8의 경우 바이트는 한 순서로만 있을 수 있으므로 바이트 순서 표시는 선택 사항입니다. UTF-16 및 UTF-32의 경우 해당 형식이 바이트 순서에 민감하기 때문에 바이트 순서 표시가 필요합니다.
참고 항목
바이트 순서 표시는 텍스트의 바이트 순서를 선택하는 컨트롤 문자가 아닙니다.
| 바이트 순서 표시 | 설명 |
|---|---|
| EF BB BF | UTF-8 |
| FF FE | UTF-16, little endian |
| FE FF | UTF-16, big endian |
| FF FE 00 00 | UTF-32, little endian |
| 00 00 FE FF | UTF-32, big-endian |
참고 항목
레거시 Microsoft 제품은 "유니코드"에 Windows-1252 또는 UCS-2(UTF-16이 고정됨) 작은 엔디안 바이트 주문을 사용합니다. 새 애플리케이션의 경우, UTF-8이 권장됩니다.
이상적으로 모든 유니코드 텍스트는 바이트 순서 규칙 집합을 하나만 따릅니다. 그러나 마이크로프로세서가 가장 중요한 바이트의 배치가 다르기 때문에 이는 불가능합니다. Intel 및 MIPS 프로세서는 가장 중요한 바이트를 먼저 배치하는 반면 모토로라 프로세서(및 모든 바이트 반전 유니코드 파일)는 마지막에 배치합니다. 단일 바이트 순서 규칙 집합만 사용하면 파일이 다른 마이크로 프로세서를 기반으로 다른 운영 체제로 전송되지 않더라도 일반 텍스트 파일을 읽거나 쓸 때마다 한 유형의 마이크로프로세서 사용자는 바이트 순서를 바꿔야 합니다.
바이트 순서를 지정하는 기본 위치는 파일 헤더에 있지만 텍스트 파일에는 머리글이 없습니다. 따라서 유니코드는 문자(U+FEFF)와 비문자(U+FFFE)를 바이트 순서 표시로 정의했습니다. 서로의 미러 바이트 이미지입니다.
U+FEFF 시퀀스는 유니코드가 아닌 일반 텍스트 파일의 시작 부분에서 매우 드물기 때문에 파일을 유니코드 파일로 식별하는 암시적 마커 또는 서명으로 사용될 수 있습니다. 유니코드 및 유니코드가 아닌 텍스트 파일을 모두 읽는 애플리케이션은 이 시퀀스의 현재 상태를 파일이 유니코드 파일일 가능성이 높다는 표시기로 사용해야 합니다. 이 기술을 MS-DOS EOF 마커를 사용하여 텍스트 파일을 종료하는 방법과 비교합니다.
애플리케이션은 텍스트 파일의 시작 부분에서 U+FEFF를 찾으면 일반적으로 파일을 유니코드 파일로 처리하지만 확인을 위해 추가 추론 검사를 수행할 수 있습니다. 이러한 검사는 낮은 순서 바이트의 변형이 상위 바이트의 변형보다 훨씬 높은지 확인하기 위해 테스트하는 것만큼 간단할 수 있습니다. 예를 들어 ASCII 텍스트가 유니코드 텍스트로 변환되는 경우 매초 바이트는 0입니다. 또한 줄 바꿈 및 캐리지 리턴 문자(U+000A 및 U+000D)와 짝수 또는 홀수 파일 크기를 모두 확인하면 파일의 특성을 강력하게 표시할 수 있습니다.
애플리케이션이 텍스트 파일의 시작 부분에서 U+FFFE를 찾으면 파일이 바이트 반전 유니코드 파일임을 의미하는 것으로 해석됩니다. 애플리케이션은 바이트 순서를 교환하거나 사용자에게 오류가 발생했음을 경고할 수 있습니다.
유니코드 바이트 순서 표시 문자는 코드 페이지에서 찾을 수 없으므로 데이터가 ANSI로 변환되면 사라집니다. 다른 유니코드 문자와 달리 변환될 때 기본 문자로 대체되지 않습니다. 파일 중간에 바이트 순서 표시가 있으면 유니코드 문자로 해석되지 않으며 텍스트 출력에는 영향을 주지 않습니다.
참고 항목
유니코드 값 U+FFFF는 일반 텍스트 파일에서 불법이며 애플리케이션 간에 전달할 수 없습니다. 애플리케이션의 프라이빗 사용을 위해 예약되어 있습니다.
관련 항목