macos - 파일의 인코딩 메커니즘은 무엇입니까?

Question

예를 들어 내 Mac에는 f.txt 파일이 있습니다. 시스템은 utf-8로 인코딩되어 있습니다.
그 안에 "xE6x97A5" 데이터가 있습니다. 즉, utf-8 인코딩의 한자 "日"입니다.

그런 다음 ultraedit를 사용하여 f.txt를 다음 파일로 저장했습니다.

1. f1.txt 파일

   실제 저장된 내용은 "xE6x97A5"입니다. ultraedit가 이를 gb18030 인코딩으로 해석하면 ultraedit 인터페이스에서 잘못된 문자로 표시됩니다. 이후 gb18030 인코딩 파일로 저장되었는데, Mac 시스템에서 열어보니 UTF-8로 되어 있어서 디스플레이가 정상이었습니다.
   

2. f2.txt 파일

   실제 저장된 내용은 "xE6x97A5"인데, 이는 utf-8로 해석되어 "日"로 표시됩니다
   

3. f3.txt 파일

   gb18030 인코딩으로 직접 저장하면 ultraedit가 자동으로 인코딩을 변경합니다. 즉, "xE6x97A5"를 "xC8xD5"로 변경합니다. 그런 다음 vim은 파일을 열고 ASCII 인코딩 해석을 호출합니다.
   

질문입니다.

실제 저장된 데이터는 "xE6x97A5"인데 왜 내 편집자는 이를 utf-8 인코딩으로 해석합니까? GBK에서 설명하는 잘못된 코드를 얻으려면 어떻게 해야 하나요?
문서의 바이너리 헤더에 일종의 태그를 추가하는 것인가요? 그렇다면 이 태그를 어떻게 볼 수 있나요?
코딩 기반 의미 분석은 에디터 측에서 수행되나요?

Answer 1

vim을 예로 들어보겠습니다

텍스트 파일을 열 때 vim은 특정 인코딩 A에 따라 열고, 저장 시에는 다른 인코딩 C로 변환합니다. vim으로 자동 완성.
인코딩 B: 전체 파일에 영향을 미치지 않지만, 표시와 관련이 있습니다. vim이 운영 체제와 상호 작용할 때 사용되는 인코딩입니다.

인코딩 A: set fileencodings=ucs-bom,utf-8,gbk,cp936,latin-1을 사용하여 설정하세요. vim은 설정된 순서대로 탐지 파일의 인코딩을 확인합니다. 일부 인코딩에서는 바이너리 시퀀스의 특정 조합이 존재하지 않기 때문에 감지되면 이 인코딩이 아닌 것으로 간주하고 다음 인코딩을 확인하고 그렇지 않으면 이 인코딩으로 간주합니다. latin-1은 바이너리 시퀀스의 모든 조합으로 나타날 수 있으므로 먼저 배치되면 항상 latin-1로 표시됩니다. 编码A：使用 set fileencodings=ucs-bom,utf-8,gbk,cp936,latin-1设置。vim 按照设置的顺序检查检测文件的编码。因为某些编码里不存在某些二进制序列的组合，所以如果检测到就认为不是这种编码，检查下一种编码，否则就认为是这一种。因为latin-1可以出现任何二进制序列的组合，所以如果放到第一个，那么将永远以latin-1显示。

在一般的二进制文件里是不存在字符编码的标记的。但是Unicode里面有个特殊叫做零宽度空格（FEFF）而FFFE是不存在的编码，所以在Unicode的标准里可以人为的在开始加入这个字符（这个字符在任何字体下都是没有宽度的，在中文字符里面没有任何的效果跟没有一样，是为了照顾东南亚某些语言的显示而设置的）。这样就便于文本编辑器检查字符和字节顺序，但是在代码里include这种文件经常会出问题（这可是个大坑，编译器会认为这是一个非法字符，可是你又看不到）。

编码B：set fileencoding=utf-8

일반 바이너리 파일에는 문자 인코딩 표시가 없습니다. 하지만 유니코드에는 너비가 0인 공백(FEFF)이라는 특수 문자가 있고 FFFE는 존재하지 않는 인코딩이므로 이 문자를 인위적으로 처음에 추가할 수 있습니다. 유니코드 표준에서 ( 이 문자는 어떤 글꼴에도 너비가 없으며 한자에는 영향을 주지 않습니다. 동남아시아 일부 언어의 표시를 처리하도록 설정되어 있습니다.) 이렇게 하면 텍스트 편집기에서 문자와 바이트 순서를 확인하기가 더 쉬워지지만 include와 같은 파일은 종종 코드에서 문제를 일으킵니다(이것은 큰 함정입니다. 컴파일러는 이것이 잘못된 문자라고 생각하지만, 당신은 그것을 볼 수 없습니다).

인코딩 B: set fileencoding=utf-8, 저장 시 사용된 인코딩, 저장 시 자동으로 다른 인코딩으로 변환됩니다. 하지만 처음 열었을 때 잘못된 인코딩이 인식되면 존재하지 않는 문자를 변환할 때 완전히 변환되지 않습니다.

그래서 gp18030으로 저장된 f1.txt는 인코딩 변환을 수행하지 못할 수 있습니다. 🎜 🎜"질문은 실제 저장된 데이터가 "xE6x97A5"라는 것입니다. 그런데 gb18030 인코딩을 사용하여 설명하는 방법은 무엇입니까?" 🎜

Answer 2

파일 인코딩은 실제 저장 방법에 대한 코드 사양입니다. 우선 질문에 대답하자면 UTF8의 日 인코딩은 xE6x97A5입니다. >. GB18030을 사용한 인코딩 결과가 여전히 xE6x97A5의 日 문자라고 말할 수는 없습니다. 日在UTF8编码中是xE6x97A5，你就不可能说采用GB18030编码结果还为xE6x97A5的日字。

编辑器识别文本文件编码有不同的方式，有的文件编码带有Magic

편집자가 텍스트 파일 인코딩을 식별하는 방법은 다양합니다. 일부 파일 인코딩에는 처음 몇 바이트를 직접 식별하여 완료할 수 있는 Magic 헤더가 있습니다. 식별 코드는 컨텍스트와 사용자의 로케일을 기반으로 편집기에서 완전히 추측됩니다. 🎜