Comment détecter l'encodage d'un fichier texte?

J'essaie de détecter l'encodage des caractères est utilisé dans mon fichier.

J'ai essayer avec ce code pour obtenir la norme d'encodage 

public static Encoding GetFileEncoding(string srcFile)
{
//*** Use Default of Encoding.Default (Ansi CodePage)
Encoding enc = Encoding.Default;
//*** Detect byte order mark if any - otherwise assume default
byte[] buffer = new byte[5];
FileStream file = new FileStream(srcFile, FileMode.Open);
file.Read(buffer, 0, 5);
file.Close();
if (buffer[0] == 0xef && buffer[1] == 0xbb && buffer[2] == 0xbf)
enc = Encoding.UTF8;
else if (buffer[0] == 0xfe && buffer[1] == 0xff)
enc = Encoding.Unicode;
else if (buffer[0] == 0 && buffer[1] == 0 && buffer[2] == 0xfe && buffer[3] == 0xff)
enc = Encoding.UTF32;
else if (buffer[0] == 0x2b && buffer[1] == 0x2f && buffer[2] == 0x76)
enc = Encoding.UTF7;
else if (buffer[0] == 0xFE && buffer[1] == 0xFF)      
//1201 unicodeFFFE Unicode (Big-Endian)
enc = Encoding.GetEncoding(1201);      
else if (buffer[0] == 0xFF && buffer[1] == 0xFE)      
//1200 utf-16 Unicode
enc = Encoding.GetEncoding(1200);
return enc;
}

Mes cinq premiers octets sont 60, 118, 56, 46 et 49.

Est-il un tableau qui montre le codage correspond à ceux des cinq premiers octets?

  • La marque d'ordre d'octet ne doit pas être utilisé pour détecter des encodages. Il ya des cas où il est ambigu dont l'encodage est utilisé: UTF-16 LE et UTF-32 LE les deux commencent par les deux mêmes octets. La NOMENCLATURE doit seulement être utilisé pour détecter d'ordre des octets (d'où son nom). Aussi en UTF-8, à strictement parler, ne devrait même pas avoir une marque d'ordre d'octet et en ajoutant un peut interférer avec certains logiciels qui ne s'y attendent pas.
  • Bayers, donc c'est il possible que je peux detech sorcière de codage sont utiliser dans mon fichier ?
  • Byers: UTF-32 LE démarre avec les mêmes 2 octets en UTF-16 LE. Cependant, il suit également avec des octets 00 00 qui est (je pense très) peu probable en UTF-16 LE. Aussi, la NOMENCLATURE, en théorie, devrait indiquer que vous dites, mais dans la pratique, il agit comme une signature pour montrer ce que l'encodage. Voir: unicode.org/faq/utf_bom.html#bom4
  • Est le UTF7 NOMENCLATURE en fait une chose réelle? J'ai essayé de faire un UTF7Encoding objet et effectuer GetPreamble (), et il a renvoyé un tableau vide. Et contrairement à utf8 il n'a pas un paramètre de constructeur pour elle.
  • Marque Beyers: Votre commentaire est COMPLÈTEMENT faux. La NOMENCLATURE est une preuve de balle de manière à détecter l'encodage. UTF16 ÊTRE et UTF32 be ne sont pas ambigus. Vous devez étudier le sujet avant d'écrire de mauvais commentaires. Si un logiciel ne gère pas de l'utf-8 BOM alors ce logiciel est fom les années 1980 ou mal programmé. Aujourd'hui, chaque logiciel doit manipuler et à reconnaître BOM.
  • Double Possible de Comment puis-je détecter l'encodage/codepage d'un fichier texte
  • Elmue a clairement jamais utilisé lot de filtrage, la concaténation, et le tuyau de redirection de flux de fichiers de texte. Il est irréaliste de poignée/support Nomenclatures dans de tels scénarios.

InformationsquelleAutor Cédric Boivin | 2010-12-23
  1. 81

    Vous ne pouvez pas dépendre sur le fichier ayant une NOMENCLATURE. UTF-8 n'en a pas besoin. Et non-Unicode encodages n'ont même pas de NOMENCLATURE. Il existe cependant d'autres façons de détecter l'encodage.

    UTF-32

    MOB est 00 00 FE FF (pour ÊTRE) ou FF FE 00 00 (pour LE).

    Mais UTF-32 est facile à détecter, même sans BOM. C'est parce que le point de code Unicode gamme est limitée à U+10FFFF, et donc de l'UTF-32 unités de toujours avoir le modèle 00 {00-10} xx xx (pour ÊTRE) ou xx xx {00-10} 00 (pour LE). Si les données ont une longueur qui est un multiple de 4, et suit l'un de ces modèles, vous pouvez supposer que c'est de l'UTF-32. Les faux positifs sont presque impossible à cause de la rareté de 00 octets octets orienté encodages.

    US-ASCII

    Sans BOM, mais vous n'en avez pas besoin. ASCII peut être facilement identifié par le manque d'octets dans les années 80 FF gamme.

    UTF-8

    MOB est EF BB BF. Mais vous ne pouvez pas compter sur cela. Beaucoup de fichiers UTF-8 n'ont pas une NOMENCLATURE, surtout s'ils sont originaires des systèmes non-Windows.

    Mais vous pouvez déduire sans risque que, si un fichier est validé en tant que UTF-8, il est UTF-8. Les faux positifs sont rares.

    Plus précisément, étant donné que les données n'est pas ASCII, le taux de faux positifs pour un 2-séquence d'octets est seulement 3,9% (1920/49152). Pour un 7-séquence d'octets, c'est moins de 1%. Pour un 12-séquence d'octets, c'est moins de 0,1%. Pour un 24-séquence d'octets, c'est moins de 1 sur un million.

    UTF-16

    MOB est FE FF (pour ÊTRE) ou FF FE (pour LE). Notez que l'UTF-16LE MOB est trouvé au début de l'UTF-32LE NOMENCLATURE, afin de vérifier l'UTF-32 la première.

    Si vous avez un fichier qui se compose principalement de l'ISO-8859-1 personnages, le fait que la moitié du fichier octets 00 serait également un bon indicateur de l'UTF-16.

    Sinon, le seul moyen fiable pour reconnaître UTF-16 sans BOM est de regarder pour les paires de substitution (D[8-B]xx D[C-F]xx), mais non BMP personnages sont trop rarement utilisé pour faire de cette approche pratique.

    XML

    Si votre fichier commence avec les octets 3C 3F 78 6D 6C (c'est à dire, les caractères ASCII "<?xml"), puis chercher une encoding= déclaration. Si elle est présente, puis utiliser cet encodage. S'il est absent, alors en charge UTF-8, qui est la valeur par défaut de codage XML.

    Si vous avez besoin de soutien EBCDIC, aussi l'air pour l'équivalent de la séquence 4C 6F A7 94 93.

    En général, si vous avez un format de fichier qui contient la déclaration de codage, puis regarder pour cette déclaration plutôt que d'essayer de deviner le codage.

    Aucun de ces

    Il y a des centaines d'autres encodages, qui demandent le plus d'efforts à détecter. Je vous recommande d'essayer Mozilla de jeu de caractères de détecteur ou un .NET port de.

    Raisonnable par défaut

    Si vous avez exclu l'UTF encodages, et n'ont pas une déclaration de codage ou de la détection statistique qui pointe vers un autre encodage, supposons ISO-8859-1 ou étroitement liées Windows-1252. (Notez que la dernière version du standard HTML nécessite un “ISO-8859-1”, la déclaration doit être interprété en Windows-1252.) En cours de Windows page de code par défaut pour l'anglais (et autres langues populaires comme l'espagnol, le portugais, l'allemand et le français), c'est la plus couramment rencontrés encodage autre que UTF-8.

    • Pouvez-vous préciser votre analyse de l'UTF-8 ci-dessus? Je pense que vous dire que si vous avez un au hasard [flat] la distribution de caractères à partir de laquelle le fichier est fait, vous avez de faibles probabilités de se confondre. En pratique, aucun des fichiers de texte plat distributions comme ça... donc je m'attend à un impact sévère sur l'analyse, le taux de faux positifs étant beaucoup plus élevé. Comment pouvez-vous distinguer entre UTF-16 et UTF-8 si les fichiers sont un même nombre d'octets?
    • Oui, c'est pour une distribution aléatoire d'octets. Pour les données réelles, il est plus difficile à calculer. Mais le point est, pour un héritage codé (par exemple, windows-1252) fichier interprété à tort comme étant en UTF-8, il devrait contenir bizarre séquences de caractères comme ’.
    • OK, ce que j'attendais. Pouvez-vous distinguer de l'UTF-8/UTF-16? PS: Merci pour ce très utile de répondre. +1
    • Vous ne pouvez pas détecter UTF-16 de validation comme vous le pouvez avec UTF-8, car le taux de faux positifs est beaucoup plus élevé. Par exemple, à propos de 93,8% de hasard 4-les séquences d'octets arrive d'être valide UTF-16, le seul invalide étant noncharacters et non appariés des mères porteuses. Et 100% de la même longueur des chaînes ASCII arrive d'être valide UTF-16 (même si c'est un non-sens Chinois phrase comme 畂桳栠摩琠敨映捡獴). Le seul moyen fiable de détecter UTF-16 est de regarder pour la NOMENCLATURE, FE FF ou FF FE. Si vous souhaitez toujours avoir un faux positif pour Latin1 þÿ ou ÿþ, mais ce sont improbables combinaisons.
    • Pour l'UTF-16BE fichiers texte, si un certain pourcentage de même d'octets sont mis à zéro (ou vérifier impair d'octets UTF-16LE), puis il ya une bonne probabilité que l'encodage est UTF-16. Qu'en pensez-vous?
    • Oui, cela fonctionne la plupart du temps. Vous pouvez encore faire des faux négatifs à partir de fichiers qui contiennent uniquement des caractères Latin1.
    • qu'est-ce que le | dans 0x|10?? c'est une valeur constante?
    • Un opérateur "ou". Et le "x" indique un chiffre hexadécimal. C'est, cet octet peut être l'un des 17 des valeurs entre hex 00 hex 10, inclusivement.
    • UTF-8 validité peut bien être détecté par faire de la séquence de bits de chèques; le premier octet de la séquence de bits de précision indique le nombre d'octets de suivre, et les octets suivants ont également des bits de contrôle pour vérifier. Le modèle sont représentées ici: ianthehenry.com/2015/1/17/decoding-utf-8
    • Je suis surpris de cette réponse ne parle pas de Windows ANSI, compte tenu du commun, il est.
    • Parce qu'il est stupide d'un octet-par-symbole de la 8-bits de codage. Tous les octets est techniquement valable en elle (bien que la plupart des < 0x20 gamme ne sont pas conseillé), de sorte qu'il vous ne pouvez pas être décelée que par le langage des heuristiques... c'est une tout autre désordre. Pour ne pas mentionner, ANSI n'est pas un encodage; il y a un Windows encodage ANSI pour chaque région linguistique.
    • Je n'ai pas dit que c'est un bon encodage. Je l'ai dit c'est très couramment utilisé et je suis donc surpris que vous ne le mentionnez pas. Les points que vous venez de répondre à mon commentaire aurait été très utile inclus dans votre réponse.
    • Ce n'est pas mon réponse... et ce n'est pas mentionné parce que c'est à propos de la détection, et, comme je l'ai mentionné, vous ne pouvez pas vraiment détecter simple d'un octet-par-symbole d'encodages. J'ai personnellement posté une réponse sur ce lieu (vaguement) l'identification, bien que.
    • Là, j'ai ajouté une section Latin-1.
    • Désolé @Nyerguds vous avez juste défendu la réponse avec trop d'ardeur, je suppose. Et dan04 merci! Se lit bien.

    InformationsquelleAutor dan04
  2. 5

    Utilisation StreamReader et de l'orienter pour détecter l'encodage pour vous:

    using (var reader = new System.IO.StreamReader(path, true))
{
var currentEncoding = reader.CurrentEncoding;
}

    Et l'utilisation Page de codes Identifiants https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs. 85).aspx
    pour passer de la logique selon elle.

    • Pas de travail, le StreamReader supposons que votre fichier est en UTF-8
    • Vérifier MSDN pour ce constructeur. Avez-vous des preuves que le constructeur ne fonctionne pas systématiquement avec la documentation? D'accord, cela est possible dans Microsoft docs 🙂
    • désolé, sur votre droite. Mais il ne fonctionnent pas 🙁 le codage n'est pas bon
    • Cette version est aussi vérifie uniquement la NOMENCLATURE
    • Euh, vous n'avez pas à appeler Read() avant de lire CurrentEncoding? Le MSDN pour CurrentEncoding dit "La valeur peut être différente après le premier appel à une méthode de Lecture de StreamReader, puisque le codage de détection automatique n'est pas fait jusqu'à ce que le premier appel à une méthode de Lecture."
    • Mes tests montre que cela ne peut pas être utilisée de manière fiable, par conséquent, ne doit pas être utilisé à tous.
    • À partir de MSDN docs, le StreamReader surcharge de vous parler de "[...] initialise le codage de UTF8Encoding" ensuite, le deuxième paramètre, detectEncodingFromByteOrderMarks, "[...] reconnaît automatiquement le format UTF-8, little-endian Unicode, et big-endian texte Unicode si le fichier commence par l'appropriées d'ordre d'octet." Il sera le premier par défaut en UTF8 et puis il ne sera pas auto-détection de tous les encodages, donc ce n'est pas ce que l'OP cherche. (msdn.microsoft.com/en-us/library/7bc2hwcb(v=vs. 110).aspx)

    InformationsquelleAutor Phil Hunt
  3. 4

    Plusieurs réponses sont ici, mais personne n'a posté utile de code.

    Voici mon code qui détecte tous les encodages que Microsoft détecte dans le Cadre de 4 dans la classe StreamReader.

    Évidemment, vous devez appeler cette fonction immédiatement après l'ouverture du cours d'eau avant de lire quoi que ce soit d'autre du ruisseau, car la NOMENCLATURE sont les premiers octets dans le flux.

    Cette fonction nécessite un Flux qui permet de tenter (par exemple un FileStream). Si vous avez un Flux qui ne peuvent obtenir, vous devez écrire un plus compliqué code qui renvoie un tampon d'Octets par octets qui ont déjà été lu, mais qui ne sont pas de NOMENCLATURE.

    ///<summary>
///UTF8    : EF BB BF
///UTF16 BE: FE FF
///UTF16 LE: FF FE
///UTF32 BE: 00 00 FE FF
///UTF32 LE: FF FE 00 00
///</summary>
public static Encoding DetectEncoding(Stream i_Stream)
{
if (!i_Stream.CanSeek || !i_Stream.CanRead)
throw new Exception("DetectEncoding() requires a seekable and readable Stream");
//Try to read 4 bytes. If the stream is shorter, less bytes will be read.
Byte[] u8_Buf = new Byte[4];
int s32_Count = i_Stream.Read(u8_Buf, 0, 4);
if (s32_Count >= 2)
{
if (u8_Buf[0] == 0xFE && u8_Buf[1] == 0xFF)
{
i_Stream.Position = 2;
return new UnicodeEncoding(true, true);
}
if (u8_Buf[0] == 0xFF && u8_Buf[1] == 0xFE)
{
if (s32_Count >= 4 && u8_Buf[2] == 0 && u8_Buf[3] == 0)
{
i_Stream.Position = 4;
return new UTF32Encoding(false, true);
}
else
{
i_Stream.Position = 2;
return new UnicodeEncoding(false, true);
}
}
if (s32_Count >= 3 && u8_Buf[0] == 0xEF && u8_Buf[1] == 0xBB && u8_Buf[2] == 0xBF)
{
i_Stream.Position = 3;
return Encoding.UTF8;
}
if (s32_Count >= 4 && u8_Buf[0] == 0 && u8_Buf[1] == 0 && u8_Buf[2] == 0xFE && u8_Buf[3] == 0xFF)
{
i_Stream.Position = 4;
return new UTF32Encoding(true, true);
}
}
i_Stream.Position = 0;
return Encoding.Default;
}
    InformationsquelleAutor Elmue
  6. 1

    Si votre fichier commence avec les octets 60, 118, 56, 46 et 49, alors vous avez un cas ambigus. Il pourrait être en UTF-8 (sans BOM) ou à l'un des seul octet encodages comme ASCII, ANSI, ISO-8859-1, etc.

    • Hummmm ... j'ai donc besoin de tester tous ?
    • C'est juste pur ascii. UTF-8 sans caractères spéciaux simplement égale ASCII, et si il y a des caractères spéciaux, ceux qui l'utilisent spécifique détectable modèles de bits.
    • peut-être pas. J'ai un fichier texte UTF-8 (sans "spécifique détectable modèles de bits" - et surtout tous les caractères en anglais). Si je l'ai lu avec l'ASCII, il ne parvient pas à lire un particulier, le symbole" -".
    • Impossible. Si le caractère n'est pas ascii, alors il sera codé à l'aide de celles qui sont spécifiques détectables modèles de bits; c'est comment utf-8 travaux. Plus probablement, votre texte n'est ni ascii ni utf-8, mais seulement à 8-bits comme Windows-1252.
    InformationsquelleAutor Codo
  7. 1

    - Je utiliser Ude qui est un C# port de Mozilla jeu de caractères Universel Détecteur. Il est facile à utiliser et donne vraiment de bons résultats.

    InformationsquelleAutor Julien Jacobs