libiconv 1.14-2를 사용하는 cygwin 1.7.25에서 x86이 리틀 엔디안이고 윈도우가 리틀 엔디안 UTF-16을 생성하더라도 iconv (1)은 iconv -t utf-16
과 함께 사용될 때 big-endian UTF-16을 생성합니다 (BOM 포함). libiconv가 기본 utf-16 변환에 플랫폼 종속적 인 엔디안을 사용하지 않습니까? 내가 사용하고있는 응용 프로그램 (반드시 BOM을 읽음으로써 둘 다 처리 할 수 있기 때문에)은 문제가 아니지만 메모장으로 새 파일을 편집하는 것은 여전히 이상한 행동입니다. 그것은 utf-16le로 bom으로 저장하고, 동일한 시스템에있는 iconv (1)을 통해 실행하고 -t utf-16
과 big-endian bom으로 재정렬 된 파일을 얻습니다.cygwin에서 iconv (1)가`-t utf-16`으로 빅 엔디안 UTF-16을 생성하는 이유는 무엇입니까?
1
A
답변
2
유니 코드 사양에 대한 선호를 표시를 빅 엔디안과 타사 소프트웨어는 기본적으로이를 사용합니다. 특히 UTF-16이 BOM없이 인코딩되고 상위 수준 프로토콜 (예 : 네트워크 및 네트워크 바이트 순서와 같이 바이트 순서를 선언하는 매체)이없는 경우 바이트 순서는 빅 엔디안입니다. 그러나 일부 소프트웨어는 사양을 따르지 않으며 BOM이 없을 때 거의 엔디안을 차지하지 않으므로 이러한 소프트웨어가 작동하도록 BOM을 추가 할 수 있습니다.
libiconv는 기본 utf-16 변환에 플랫폼 종속적 인 엔디안을 사용하지 않습니까?
내가 아는 한 왜 이걸 생각하니?
1
이 꽤 중복이 아니라 Convert UTF8 to UTF16 using iconv에 허용 대답은 명시 적 엔디 언을 지정하고 다음 BOM 씁니다, 간단하고 스크립트 workound을 제안한다 :
(printf "\xff\xfe" ; iconv -f utf-8 -t utf-16le UTF-8-FILE) > UTF-16-FILE
이 스레드에서 : http://lists.gnu.org/archive/html/bug-gnu-libiconv/2012-01/msg00000.html libc iconv와 libiconv iconv에 대한 부분을 잘못 읽은 것 같습니다 ... (Keith Thompson이 RFC에서 "utf-16"(명시 적으로 LE 또는 BE가 아닌)의 endianness가 구현에 따라 다르다는 것을 암시 했음에도 불구하고) – cowbert