Solución:
Primero, los casos fáciles:
ASCII
Si sus datos no contienen bytes por encima de 0x7F, entonces es ASCII. (O una codificación ISO646 de 7 bits, pero esas son muy obsoletas).
UTF-8
Si sus datos se validan como UTF-8, entonces puede asumirlos con seguridad es UTF-8. Debido a las estrictas reglas de validación de UTF-8, los falsos positivos son extremadamente raros.
ISO-8859-1 frente a windows-1252
La única diferencia entre estas dos codificaciones es que ISO-8859-1 tiene los caracteres de control C1 donde windows-1252 tiene los caracteres imprimibles € ‚ƒ„… † ‡ ˆ ‰ Š ‹ŒŽ ”“ ”• –—˜ ™ š› œžŸ. He visto muchos archivos que usan comillas o guiones, pero ninguno que usa caracteres de control C1. Así que ni siquiera se moleste con ellos, o ISO-8859-1, simplemente detecte windows-1252 en su lugar.
Eso ahora te deja con una sola pregunta.
¿Cómo distingue MacRoman de cp1252?
Esto es mucho más complicado.
Caracteres indefinidos
Los bytes 0x81, 0x8D, 0x8F, 0x90, 0x9D no se utilizan en windows-1252. Si ocurren, entonces asuma que los datos son MacRoman.
Caracteres idénticos
Los bytes 0xA2 (¢), 0xA3 (£), 0xA9 (©), 0xB1 (±), 0xB5 (µ) resultan ser los mismos en ambas codificaciones. Si estos son los únicos bytes que no son ASCII, entonces no importa si elige MacRoman o cp1252.
Enfoque estadístico
Cuente las frecuencias de caracteres (¡NO de bytes!) En los datos que sabe que son UTF-8. Determine los personajes más frecuentes. Luego, use estos datos para determinar si los caracteres cp1252 o MacRoman son más comunes.
Por ejemplo, en una búsqueda que acabo de realizar en 100 artículos aleatorios de Wikipedia en inglés, los caracteres no ASCII más comunes son ·•–é°®’èö—. Basado en este hecho,
- Los bytes 0x92, 0x95, 0x96, 0x97, 0xAE, 0xB0, 0xB7, 0xE8, 0xE9 o 0xF6 sugieren windows-1252.
- Los bytes 0x8E, 0x8F, 0x9A, 0xA1, 0xA5, 0xA8, 0xD0, 0xD1, 0xD5 o 0xE1 sugieren MacRoman.
Cuente los bytes que sugieren cp1252 y los bytes que sugieren MacRoman, y elija el que sea mayor.
Mozilla nsUniversalDetector (enlaces de Perl: Encode :: Detect / Encode :: Detect :: Detector) está probado en un millón de veces.
Mi intento de tal heurística (suponiendo que haya descartado ASCII y UTF-8):
- Si 0x7f a 0x9f no aparecen en absoluto, probablemente sea ISO-8859-1, porque esos son códigos de control que se usan muy raramente.
- Si 0x91 a 0x94 aparecen en el lote, probablemente sea Windows-1252, porque esas son las “comillas tipográficas”, con mucho, los caracteres más probables en ese rango para ser usados en texto en inglés. Para estar más seguro, puede buscar pares.
- De lo contrario, es MacRoman, especialmente si ve mucho de 0xd2 a 0xd5 (ahí es donde están las comillas tipográficas en MacRoman).
Nota al margen:
Para archivos como la fuente Java donde no existe tal función interna en el archivo, colocará la codificación antes de la extensión, como SomeClass-utf8.java
¡¡No hagas esto!!
El compilador de Java espera que los nombres de los archivos coincidan con los nombres de las clases, por lo que cambiar el nombre de los archivos hará que el código fuente no sea compilable. Lo correcto sería adivinar la codificación, luego usar el native2ascii herramienta para convertir todos los caracteres no ASCII a secuencias de escape Unicode.