UTF-16LE 대 UTF32-LE에 대한 유니 코드 BOM

Question

UTF16-LE 및 UTF-32LE에 사용되는 바이트 순서 마크 사이에 모호성이있는 것 같습니다. 특히 다음 8 바이트가 포함 된 파일을 고려하십시오.

FF FE 00 00 00 00 00 00

이 파일이 포함되어 있는지 어떻게 알 수 있습니까?

1. UTF16-LE BOM (FF FE)과 3 개의 널 문자; 또는
2. UTF32-LE BOM (FF FE 00 00)과 하나의 널 문자?

유니 코드 BOM은 여기에 설명되어 있습니다. http://unicode.org/faq/utf_bom.html#bom4 그러나이 모호성에 대한 논의는 없습니다. 내가 뭔가를 놓치고 있습니까?

Answer 1

이름에서 알 수 있듯이 Bom은 바이트 순서, 인코딩이 아닙니다. 인코딩이 무엇인지 알아야한다면 BOM을 사용하여 멀티 파이트 시퀀스의 가장 적게 또는 가장 중요한 바이트가 먼저 있는지 여부를 결정할 수 있습니다.

BOM의 운이 좋은 부작용은 때때로 그것을 알지 못하면 인코딩을 추측하는 데 때때로 그것을 사용할 수 있다는 것입니다. 그러나 그것은 그것이 설계된 것이 아니며 적절한 인코딩 정보를 보내는 대체물이 아닙니다.

Answer 2

모호하지 않습니다. FF FE UTF-16LE입니다 FF FE 00 00 UTF-32LE를 나타냅니다. 그것을 생각할 이유가 없습니다 FF FE 00 00 UTF는 텍스트 용으로 설계되었으며 사용자는 텍스트에 NUL 문자를 사용해서는 안되기 때문에 UTF-16LE 일 수 있습니다. 결국, 마지막으로 16 진 편집자를 열고 00의 몇 바이트를 텍스트 문서에 삽입 한 시간은 언제입니까? ^_^

Answer 3

에드워드와 같은 문제를 경험했습니다. 나는 Dustin에 동의합니다. 일반적으로 Textfiles에서 Null-Characters를 사용하지 않습니다.

그러나 모든 유니 코드 문자가 포함 된 파일을 만들었습니다. UTF-32LE 인코딩, UTF-32BE 인코딩, UTF-16LE 및 UTF-16BE 인코딩 및 UTF-8 인코딩을 처음 사용했습니다.

파일을 UTF-8로 다시 인코딩하려고 할 때 결과를 이미 기존 UTF-8 파일과 비교하고 싶었습니다. BOM 이후 파일의 첫 번째 문자는 Null-Character이기 때문에 UTF-16LE BOM으로 파일을 성공적으로 감지 할 수 없었으며, 바이트가 Edward가 설명한 것과 똑같이 나타나기 때문에 UTF-32LE BOM으로 표시되었습니다. BOM FFF의 첫 번째 문자는 0000이지만 BOM 검출은 BOM FFFE0000을 발견하여 UTF-16LE 대신 UTF-32LE을 감지하여 첫 0000 차이터가 도난 당하고 BOM의 일부로 취해졌습니다.

따라서 UTF-16 Little Endian으로 인코딩 된 파일의 첫 번째 문자로 Null-Character를 사용해서는 안됩니다. UTF-16LE 및 UTF-32LE BOM을 모호하게 만들기 때문입니다.

내 문제를 해결하기 위해 첫 번째와 두 번째 캐릭터를 교환합니다. :-)