69 votes

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

Existe-t-il un moyen de configurer Windows 7 pour qu'il utilise globalement UTF-8 comme standard ?
c'est vraiment ennuyeux de devoir configurer chaque éditeur de texte pour l'utiliser.

49voto

jsalonen Points 8473

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

Pour développer, je crains que vous ne trouviez pas d'option d'encodage 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 demander quel est le problème que vous essayez de résoudre ?

C'est à l'application de choisir si elle utilise l'unicode en interne pour représenter les données. L'utilisation de l'unicode est encouragée vous ne pourrez jamais être sûr que toutes vos applications le prennent en charge en interne.

Ce que vous peut faire Cependant, il s'agit de modifier le codage des caractères par défaut pour chacune des applications énumérées :

  • Pour Eclipse, l'encodage par défaut pour les nouveaux fichiers peut être défini à partir de Windows > Préférences > Général > Types de contenu (voir post sur Eclipse Community Forms )
  • Pour Notepad++, naviguez vers Paramètres > Préférences > Nouveau document/par défaut/répertoire et définissez Encodage à UTF-8
  • Quant à Thunderbird, je suis sûr qu'il utilise déjà l'UTF-8 comme encodage par défaut (cf. ces notes sur le codage des caractères )
  • Dans le cas d'OpenOffice (et de LibreOffice), vous n'avez même pas besoin de vous préoccuper de l'encodage, puisque les documents sauvegardés par OpenOffice sont basés sur XML, dans lequel l'encodage est spécifié de manière interne dans les fichiers XML (et UTF-8 est déjà la valeur par défaut ici aussi)
  • Du point de vue de l'UTF-8, PowerShell est délicat. Il a un encodage par défaut de UTF-16LE .

24voto

Chris KL Points 2418

Ce n'est pas possible, principalement parce que Windows n'autorise pas UTF-8 comme page de code ANSI du système, même s'il existe une page de code ANSI pour 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, Unicode était 16 bits.
  • Windows a une page de code ANSI pour chaque langue supportée. Contrairement à Unix et Linux, où la langue et l'encodage peuvent être définis de manière indépendante.
  • La page de code 65001 ne fonctionne pas partout. Plus précisément, elle ne fonctionne pas avec certaines des prises en charge multi-octets de Windows qui s'attendent à ce que les caractères multi-octets nécessitent un ou deux octets, alors que l'UTF-8 nécessite entre un et quatre octets. Le site WriteFile() API par exemple, renvoie un résultat incorrect sous la page de code 65001, ce qui se répercute sur tout le code de la bibliothèque qui en dépend, comme par exemple write() .

Le regretté Michael Kaplan, qui travaillait sur l'internationalisation chez Microsoft, avait un blog, "Faire le tri" avec plusieurs articles sur des sujets connexes. Je lui ai envoyé directement un courriel au sujet de certaines de ces préoccupations à l'époque.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X