Je regarde juste les constructeurs pour StreamReader/Writer et je note qu'il utilise UTF8 par défaut. Quelqu'un sait pourquoi c'est? J'aurais supposé qu'il aurait été plus sûr de par défaut à Unicode.Pourquoi le .NET Framework StreamReader/Writer utilise-t-il par défaut le codage UTF8?
UTF-8 fonctionnera avec n'importe quel document ASCII, et est généralement plus compact que UTF-16 - mais il couvre toujours l'ensemble de l'Unicode. Je dirais que UTF-8 est loin plus commun que UTF-16. C'est également la valeur par défaut pour XML (lorsqu'il n'y a pas de nomenclature et qu'aucun codage explicite n'est spécifié). Pourquoi pensez-vous qu'il vaudrait mieux utiliser le format UTF-16 par défaut? (C'est ce que Encoding.Unicode est.)
EDIT: Je soupçonne que vous êtes confus sur exactement ce que UTF-8 peut gérer. This page le décrit assez clairement, y compris comment un caractère Unicode particulier est codé. C'est un encodage à largeur variable, mais il couvre l'ensemble de l'Unicode.
UTF8 est Unicode, plus précisément l'un des types de codage Unicode.
Plus important encore son arrière compatible avec ASCII, plus il est le standard par défaut pour XML et HTML
« Unicode » est le nom d'une norme, donc il n'y a pas de codage « Unicode ». Il existe plutôt deux méthodes de mappage: UTF et UCS. En ce qui concerne la partie "pourquoi", UTF-8 a une compatibilité maximale avec ASCII.
Eh bien, dans le framework .NET, le codage UTF-16 est appelé Unicode. (La propriété Encoding.Unicode.) Cela n'aide pas avec la confusion. ;) – Guffa
Comme tous les autres déjà dit, UTF-8 est une norme de codage dans Unicode. UTF-8 utilise un nombre variable d'octets pour coder tous les caractères Unicode existants.
Tous les caractères ASCII sont représentés tels quels, de sorte que les fichiers ASCII puissent être lus avec plus de précision. Dès qu'un octet du flux a son huitième bit (bit le plus élevé,> 127), le lecteur le combine avec l'octet suivant jusqu'à ce qu'il soit < 128. La combinaison est alors considérée comme 1 caractère.
Il y a des caractères dans LATIN-1 (ANSII), qui sont encodés en utilisant deux caractères: par exemple é est codé comme e et '. La longueur ('é') est donc 2.
Windows utilise le format UTF-16 en interne, ce qui limite les caractères codables à 64 Ko, ce qui ne signifie en aucun cas tous les caractères Unicde. UTF-32 permet pour le moment tous les caractères, mais est également artificiellement limité. Et tous deux ne sont pas compatibles vers le haut en ASCII, comme les principaux zéros ont:
A = ASCII h41 = UTF-8 h41 = UTF-16 h0041 = UTF-32 h00000041
Il y a aussi des petits et grands encodages endian:
A = UTF-16 big endian h0041 = UTF-16 little endian h4100
Imaginez que vous utilisez UTF16 ou UTF32 pour enregistrer vos fichiers. Ils seraient (pour les fichiers texte) de taille double ou quadrouple par rapport à ASCII et UTF-8 (UTF-8 si seulement des caractères ascii sont utilisés). UTF-8 permet non seulement tous les caractères de la norme Unicode, même pour les futures améliorations, mais économise également de l'espace de manière efficace.
Habituellement, les deux premiers octets d'un fichier, la BOM ou le marqueur d'ordre des octets, vous indiquent quel est le standard d'encodage utilisé. Si omis, XML et StreamRedaer utilisent UTF-8, comme vous l'avez découvert. Cela rend encore plus clair, car les fichiers ASCII n'ont pas de nomenclature et sont donc lus dans la plupart des cas correctement.Cela peut ne pas être vrai pour les fichiers utilisant tout LATIN-1.
Je suppose que (corrigez-moi comme je me trompe;)). NET utilise nativement UTF16 pour les chaînes il y aura des scénarios (peut-être dans des cultures différentes) où il tente de sortir un caractère que UTF8 ne peut pas gérer. – Quibblesome
UTF-8 gère tous les caractères Unicode. –
@Quarrelsome UTF-8 est un encodage de caractères de longueur variable, et il est capable de représenter le caractère _any_ de la norme Unicode. Il utilisera simplement plus d'octets (octets de 8 bits), jusqu'à 4 d'entre eux. –