Définir l'UTF8 comme encodage de caractères par défaut dans Windows 7

La réponse courte est non, ce n'est pas possible.

Pour élaborer, je crains que vous ne trouviez pas d'option de codage global dans Windows 7 qui vous permette à la fois 1) de définir un défaut global auquel 2) toutes les applications que vous avez énumérées obéiraient.

Aussi, je voudrais vous demander quel est le problème que vous essayez de résoudre ici?

C'est à l'application de choisir si elle utilise l'unicode en interne pour représenter les données. Bien que l'utilisation de l'unicode soit encouragée ](http://msdn.microsoft.com/en-us/library/dd374081%28v=vs.85%29.aspx), vous ne serez peut-être jamais sûr que toutes vos applications le supportent en interne.

Ce que vous pouvez faire**, c'est changer le codage des caractères par défaut pour chacune des applications énumérées :

• Pour Eclipse, le codage par défaut des nouveaux fichiers peut être défini à partir de Windows > Préférences > Général > Types de contenu (voir post on Eclipse Community Forms )
• Pour Notepad++, naviguez jusqu'à Settings > Preferences > New Document/Default/Directory et réglez l'encodage sur UTF-8
• Quant à Thunderbird, je suis presque sûr qu'il utilise déjà UTF-8 comme encodage par défaut ? (voir ces notes sur l'encodage des caractères )
• Dans le cas d'OpenOffice (et de LibreOffice), vous n'avez en fait même pas besoin de vous soucier de l'encodage, puisque les documents enregistrés par OpenOffice sont basés sur XML, dans lequel l'encodage est spécifié en interne dans les fichiers XML (et UTF-8 est déjà le codage par défaut là aussi)
• Du point de vue de l'UTF-8, PowerShell est délicat. Son encodage par défaut est UTF-16LE.
• Pour la sortie de fichiers de PowerShell en UTF-8, voir cette réponse
• Pour changer l'encodage par défaut, voir cette réponse

Ce n'est pas possible, principalement parce que Windows n'autorise pas l'UTF-8 comme codepage ANSI du système, même s'il existe un codepage ANSI pour l'UTF-8, codepage 65001 . Il semble y avoir plusieurs raisons à cela :

• Lorsque l'Unicode était nouveau, Microsoft a décidé que l'UCS-2 serait le meilleur moyen de prendre en charge l'Unicode. À cette époque, l'Unicode était en 16 bits.
• Windows a une page de code ANSI pour chaque langue prise en charge , contrairement à Unix et Linux où la langue et le codage peuvent être définis indépendamment.
• La page de code 65001 ne fonctionne pas partout. Plus précisément, elle est rompue avec certains des multioctets pris en charge par Windows qui s'attendent à ce que les caractères multioctets nécessitent un ou deux octets alors que l'UTF-8 nécessite entre un et quatre octets. L'API WriteFile() API , par exemple, renvoie un résultat incorrect sous la page de code 65001, qui s'affiche en bulle dans tout le code de la bibliothèque qui en dépend, comme write() .

Le regretté Michael Kaplan, qui travaillait sur l'internationalisation chez Microsoft, avait un blog “Sorting it all Out” , avec plusieurs articles sur des sujets connexes. Je lui ai envoyé directement un courriel sur certaines de ces préoccupations à l'époque.