mat*_*teo 8 linux unicode encoding utf-8
我知道简短的答案应该是"无处",但是在下面的测试2中有些东西并不完全相加.
测试1.在Gedit中,我创建了一个只包含字符串"aàbï"的新文件,我选择"另存为",并且有一个选择字符编码的选择器.所以我将其保存为"Unicode(UTF-8)",然后我重复相同的操作,并将其保存为另一个文件"ISO-8859-15".第一个文件大小为7个字节(2个1字节字符,2个2字节字符和文件末尾的LF,如十六进制转储所示).第二个文件大小为5个字节(拉丁编码中的4个1字节字符加上LF).这表明编码不存储在文件中的任何位置.显然,当我在Gedit中打开文件并正确解码时,它必须通过分析内容来弄清楚如何解码它.
测试2.我做的与上面相同,但这次文件的内容只是"abcd",即四个ascii字符.这两个保存的文件具有相同的大小(5个字节)和相同的十六进制转储.看起来两个文件是相同的,难以区分,因此,似乎没有关于编码的信息包含在文件中.
但是,当我在Gedit中再次打开测试2的两个文件时,我转到另存为,选择了保存文件的编码.Gedit可以告诉你一个文件是用UTF-8编码的,另一个文件是用ISO-8859-15编码的,尽管两个文件只包含导致相同字节序列的ascii字符,它们看起来是相同的.那个怎么样？
文件系统中是否有某种元数据？或者只是Gedit有自己的缓存并记住用户在同一台计算机上打开(并保存)的文件的用户选择？
PS注意,这个问题是即使我提出一个非编程测试的情况下,因为这是如何的文件给定类型的编码与编程相关,whic影响一个如何阅读,分析,解码,编码,并将它们从一个写程序.
它不是,至少不是默认情况下.这两个文件包含的方式实际上没有区别abcd存储在文件系统中,因为文本字符串abcd在两个语言环境的ASCII子集中编码相同.
Ext文件系统不记录文件编码元数据.虽然可以通过使用扩展属性记录有限数量的数据(大约几千字节)以及ext文件系统上的文件,但gedit显然不使用它来存储字符编码,而是缓存特定用户的为特定文件选择的编码.您可以通过以另一个用户身份登录(我以root身份登录此实验)并打开同一文件来证明这一点 - gedit将使用默认系统区域设置读取它,而不是您在其他登录名下保存的自定义区域设置.