Ustawienie UTF8 jako domyślnego kodowania znaków w systemie Windows 7

Krótka odpowiedź brzmi nie, nie jest to możliwe.

Obawiam się, że nie znajdziesz w Windows 7 opcji globalnego kodowania, która pozwala 1) ustawić globalne ustawienia domyślne, które 2) będą przestrzegane przez wszystkie wymienione aplikacje.

Chciałbym również zapytać, na czym polega problem, który starasz się rozwiązać?

Do aplikacji należy wybór, czy do reprezentacji danych używają wewnętrznie unicode. Chociaż zachęcamy do używania unicode , możesz nigdy nie być pewien, czy wszystkie Twoje aplikacje rzeczywiście obsługują go wewnętrznie.

To, co możesz zrobić, to zmienić domyślne kodowanie znaków dla każdej z wymienionych aplikacji:

• Dla Eclipse, domyślne kodowanie dla nowych plików można ustawić z Windows > Preferencje > Ogólne > Typy zawartości (patrz post na Eclipse Community Forms )
• Dla Notatnika++, Przejdź do Ustawień > Preferencji > Nowy dokument/usterka/katalog i ustaw kodowanie na UTF-8
• Co do Thunderbird'a, jestem całkiem pewien, że już używa UTF-8 jako domyślnego kodowania? (zobacz te uwagi na temat kodowania znaków )
• W przypadku OpenOffice (i LibreOffice), tak naprawdę nie musisz się nawet troszczyć o kodowanie, ponieważ dokumenty zapisywane przez OpenOffice są oparte na XML, w którym kodowanie jest określone wewnętrznie w plikach XML (a UTF-8 jest tam również domyślne)
• Z punktu widzenia UTF-8, PowerShell jest trudny. Posiada domyślne kodowanie UTF-16LE.
• Sposób wyprowadzania plików z PowerShell'a do UTF-8, patrz ta odpowiedź
• Sposób zmiany domyślnego kodowania patrz ta odpowiedź

Nie jest to możliwe głównie dlatego, że Windows nie dopuszcza UTF-8 jako strony kodowej systemu ANSI, mimo że posiada stronę kodową ANSI dla UTF-8, strona kodowa 65001 . Wydaje się, że jest ku temu kilka powodów:

• Gdy Unicode był nowy Microsoft zdecydował, że UCS-2 będzie najlepszym sposobem na wsparcie Unicode. W tym czasie Unicode był 16-bitowy.
• Windows ma jedną stronę kodową ANSI dla każdego obsługiwanego języka , w przeciwieństwie do Uniksa i Linuksa, gdzie język i kodowanie mogą być ustawione niezależnie.
• Strona kodowa 65001 nie działa wszędzie. W szczególności jest łamana przez niektóre z obsługiwanych MultiByte w Windows, które oczekują, że znaki wielobajtowe będą wymagały jednego lub dwóch bajtów, podczas gdy UTF-8 wymaga od jednego do czterech bajtów. Na przykład WriteFile() API zwraca błędny wynik pod stroną kodową 65001, który bulgocze w górę przez cały kod biblioteczny bazujący na nim, jak write() .

Nieżyjący już Michael Kaplan, który pracował nad internacjonalizacją w Microsoft, miał bloga “Sorting it all Out” , z kilkoma postami na pokrewne tematy. Wysłałem mu mailem bezpośrednio o niektórych z tych problemów w tamtych czasach.