Linux'ta dosya sistemi karakter kodlaması hakkında birkaç soru

Windows ( GBK kodlaması) ve Linux ( UTF-8 kodlaması) arasında çok sayıda dosya değişimi çalışması nedeniyle, kolayca karakter kodlama sorunlarıyla karşılaşacaktır, örneğin:

• Windows sisteminde adı Çince karakterler içeren zip / tar dosyaları, Linux sisteminde unzip / untar.
• GBK kodlaması adlı dosyaları diske yazan taşınan eski java web uygulamasını (Windows sisteminde tasarlanan, JSP'de GBK kodlamasını kullanarak) çalıştırın.
• ftp get / put GBK kodlaması adlı dosyaları Windows FTP sunucusu ve Linux istemcisi arasında.
• Linux'ta LANG ortamını değiştirin.

Daha önce bahsedilen genel sorun, dosya bulma / adlandırmadır. Google'dan sonra, http://www.linux.com/archive/feed/39912 Linux'ta Unicode'u kullanma makalem var :

işletim sistemi ve birçok yardımcı program, dosya adlarındaki baytların hangi karakterleri temsil ettiğini fark etmez.

Bu nedenle, farklı kodlamaya sahip 2 中文 .txt dosyasına sahip olmak mümkündür:

[root@fedora test]# ls
????  中文
[root@fedora test]# ls | iconv -f GBK
中文
涓iconv: illegal input sequence at position 7
[root@fedora test]# ls 中文 && ls $'\xd6\xd0\xce\xc4'|iconv -f gbk
中文
中文

Sorular:

1. Linux dosya sistemini LANG / LC_ALL ortamından bağımsız olarak dosya adlarını depolamak için sabit karakter kodlaması ( NTFS dahili olarak UTF-16 kullanır gibi) kullanarak yapılandırmak mümkün müdür ?
2. Ya da, aslında sormak istediğim şey: Dosya adı 中文 .txt ( $'\xe4\xb8\xad\xe6\x96\x87.txt') zh_CN.UTF-8 ortamında ve dosya adı 中文 .txt ( $'\xd6\xd0\xce\xc4.txt') zh_CN.GBK ortamında aynı dosyaya başvuruyor mu?
3. Yapılandırılamazsa, dosya sistemi ve mevcut ortam arasında karakter kodlamasını çevirmek için çekirdeği yamalamak mümkün mü (sadece bir soru, uygulama talep etmiyor)? ve mümkünse ne kadar performans etkisi olur?

Sorularınızı sırayla okuduğunuzda belli olması gereken nedenlerden dolayı biraz yeniden biçimlendirdim.

1. Linux dosya sistemini LANG / LC_ALL ortamından bağımsız olarak dosya adlarını saklamak için sabit karakter kodlaması kullanacak şekilde yapılandırmak mümkün müdür?

Hayır, bu mümkün değil: sorunuzda belirttiğiniz gibi, bir UNIX dosya adı sadece bir bayt dizisidir; çekirdek kodlama hakkında hiçbir şey bilmiyor, ki bu tamamen bir kullanıcı-alanı (yani, uygulama-seviyesi) kavramı.

Başka bir deyişle, çekirdek LANG/ hakkında hiçbir şey bilmiyor LC_*, bu yüzden çeviremiyor.

2. Farklı dosya adlarının aynı dosyaya başvurmasına izin vermek mümkün mü?

Aynı dosyaya ilişkin birden fazla dizin girişiniz olabilir; bunu sabit bağlantılar veya sembolik bağlantılar aracılığıyla yapabilirsiniz .

Bununla birlikte, geçerli kodlamada geçerli olmayan dosya adlarının (örneğin, UTF-8 yerel ayarında çalışırken GBK karakter dizeniz), hiç görüntülenmeyeceğini unutmayın.

3. Dosya sistemi ve mevcut ortam arasında karakter kodlamasını çevirmek için çekirdeği yamalamak mümkün müdür?

Bunu yapmak için çekirdeği yatıramazsınız (bkz. 1.), ancak bu çeviriyi gerçekleştirmek için C kitaplığını (örneğin, glibc) yayabilir ve teoriyi çağırdığında her zaman dosya adlarını UTF-8'e dönüştürebilirsiniz, ve çekirdekten bir dosya adı okuduğunda bunları geçerli kodlamaya geri dönüştürür.

Daha basit bir yaklaşım , dosya adını UTF-8'e / UTF-8'den dönüştürdükten sonra herhangi bir dosya sistemi isteğini başka bir konuma yönlendiren FUSE ile bir bindirme dosya sistemi yazmak olabilir . İdeal olarak bu dosya sistemini bağlayabilirsiniz ~/transve bir ~/trans/a/GBK/encoded/pathdosyaya erişim sağlandığında FUSE dosya sistemi gerçekten erişir /a/UTF-8/encoded/path.

Ancak, bu yaklaşımlardaki sorun şudur: Dosya sisteminizde zaten var olan ve UTF-8 kodlu olmayan dosyalarla ne yaparsınız? Sadece tercüme edilmeden geçemezsiniz, çünkü o zaman onları nasıl dönüştüreceğinizi bilmiyorsunuz; geçersiz karakter dizilerini şu dile çevirerek yönetemezsiniz ?çünkü bu çakışmalar yaratabilir ...

Yapabileceğiniz şey, desteklenen yerel ayarların miktarını yalnızca UTF-8 yerel ayarlarıyla sınırlamaktır.

http://www.fifi.org/cgi-bin/man2html/usr/share/man/man5/locale.gen.5