Sur mon système de fichiers (Windows 7), j'ai quelques fichiers texte (ce sont des fichiers de script SQL, si cela a de l'importance).
Lorsqu'ils sont ouverts avec [Notepad++][1], dans le menu "Encodage" ; certains d'entre eux sont signalés comme ayant un encodage de "UCS-2 Little Endian" ; et d'autres de "UTF-8 without BOM" ;.
Quelle est la différence ? Ils semblent tous être des scripts parfaitement valides. Comment pourrais-je savoir quels sont les encodages du fichier sans Notepad++ ?
Les fichiers indiquent généralement leur encodage par un en-tête de fichier. Il existe de nombreux exemples [ici][1]. Cependant, même en lisant l'en-tête, on ne peut jamais être sûr de l'encodage réellement utilisé par un fichier.
Par exemple, un fichier dont les trois premiers octets sont 0xEF,0xBB,0xBF
est probablement un fichier encodé en UTF-8. Cependant, il peut s'agir d'un fichier ISO-8859-1 qui commence par les caractères 
. Ou bien il peut s'agir d'un type de fichier entièrement différent.
Notepad++ fait de son mieux pour deviner l'encodage utilisé par un fichier, et la plupart du temps, il y parvient. Il arrive cependant qu'il se trompe. C'est la raison pour laquelle le menu "Encodage" est là, pour que vous puissiez passer outre sa meilleure estimation.
Pour les deux encodages que vous mentionnez :
Les fichiers "UCS-2 Little Endian" ; sont des fichiers UTF-16 (d'après ce que j'ai compris de l'info [ici][2]) donc probablement ils commencent avec 0xFF,0xFE
comme les 2 premiers octets. D'après ce que je sais, Notepad++ les décrit comme "UCS-2" ; puisqu'il ne supporte pas certaines facettes de l'UTF-16.
Les fichiers "UTF-8 sans BOM" n'ont pas d'octets d'en-tête. C'est ce que signifie le bit "without BOM" ;.
[1] : http://www.garykessler.net/library/file_sigs.html [2] : http://www.unicode.org/faq/basic_q.html#14
C'est impossible. Si vous pouviez le faire, il n'y aurait pas autant de sites Web ou de fichiers texte contenant du "charabia aléatoire". C’est pourquoi le codage est généralement envoyé avec la charge utile sous forme de métadonnées.
Si ce n'est pas le cas, tout ce que vous pouvez faire, c'est une "supposition intelligente", mais le résultat est souvent ambigu, car la même séquence d'octets peut être valide dans plusieurs codages.