Como adivinhar a codificação de um arquivo sem BOM em .NET?

votos
5

Eu estou usando a classe StreamReader em .NET como este:

using( StreamReader reader = new StreamReader( c:\somefile.html, true ) {
    string filetext = reader.ReadToEnd();
}

Isso funciona bem quando o arquivo tem um BOM. I teve problemas com um arquivo sem BOM .. basicamente eu tenho rabiscos. Quando eu especificado Encoding.Unicode ele funcionou bem, por exemplo:

using( StreamReader reader = new StreamReader( c:\somefile.html, Encoding.Unicode, false ) {
    string filetext = reader.ReadToEnd();
}

Então, eu preciso para obter o conteúdo do arquivo em uma string. Então como é que as pessoas geralmente lidar com isso? Eu sei que não há nenhuma solução que irá funcionar 100% do tempo, mas eu gostaria de melhorar minhas chances .. há obviamente software lá fora, que tenta adivinhar (por exemplo, bloco de notas, navegadores, etc). Existe um método no framework .NET que vai adivinhar para mim? Alguém tem algum código que gostaria de compartilhar?

Mais de fundo: Esta pergunta é praticamente a mesma que a minha, mas eu estou em terra .NET. Essa pergunta me levou a um blog listando vários detecção de codificação de bibliotecas, mas nenhum deles está em .NET

Publicado 29/03/2009 em 17:41
fonte usuário
Em outras línguas...                            


8 respostas

votos
0

UTF-8 foi concebido de uma forma que é improvável ter um texto codificado em uma 8bit-codificação arbitrária como latin1 sendo decodificado para unicode adequada usando UTF-8.

Assim, a abordagem mínima é este (pseudocódigo, eu não falo .NET):

tente: u = some_text.decode ( "UTF-8"), excepto UnicodeDecodeError: u = some_text.decode ( "mais provável que codifica")

Para o mais provável que codifica um geralmente utiliza por exemplo latin1 ou CP1252 ou qualquer outra coisa. abordagens mais sofisticadas podem tentar e encontrar pares de caracteres específicos do idioma, mas eu não estou ciente de algo que faz isso como uma biblioteca ou algo assim.

Respondeu 29/03/2009 em 17:47
fonte usuário

Respondeu 29/03/2009 em 17:51
fonte usuário

votos
0

Eu usei isso para fazer algo semelhante um tempo atrás:

http://www.conceptdevelopment.net/Localization/NCharDet/

Respondeu 29/03/2009 em 17:54
fonte usuário

votos
0

Use IsTextUnicode do Win32.

No sentido geral, é um promlem difícil. Veja: http://blogs.msdn.com/oldnewthing/archive/2007/04/17/2158334.aspx .

Respondeu 29/03/2009 em 17:57
fonte usuário

votos
3

Você deve ler este artigo por Raymond Chen. Ele entra em detalhes sobre como os programas podem adivinhar o que uma codificação é (e um pouco da diversão que vem de adivinhar)

http://blogs.msdn.com/oldnewthing/archive/2004/03/24/95235.aspx

Respondeu 29/03/2009 em 18:08
fonte usuário

votos
0

Uma técnica hacky poderia ser a de fazer um MD5 do texto, em seguida, decodificar o texto e re codifica-lo em várias codificações, MD5'ing cada um. Se um combina com você acho que é esse tipo de codificação.

Isso é, obviamente, muito lento para algo que lida com um monte de arquivos, mas para algo como um editor de texto que eu poderia vê-lo trabalhando.

Outros do que isso, vai ser mãos sujas portar as bibliotecas Java a partir deste post que vieram da questão Delphi SO, ou usando o recurso IE MLang.

Respondeu 29/03/2009 em 18:10
fonte usuário

votos
0

Veja a minha resposta (recente) para esta (tanto quanto eu posso dizer, equivalente) pergunta: Como posso detectar a codificação / página de códigos de um arquivo de texto

Ele não tenta adivinhar em toda uma gama de possíveis codificações "nacionais" como MLang e NCharDet fazer, mas sim assume que você sabe que tipo de arquivos não-Unicode é provável que você encontrar. Tanto quanto eu posso dizer de sua pergunta, ele deve resolver o seu problema bastante confiável (sem contar com a "caixa preta" de MLang).

Respondeu 29/04/2011 em 10:27
fonte usuário

votos
1

Eu tive sorte com Pude , um C#porto de Mozilla Universal Charset Detector.

Respondeu 20/06/2011 em 21:16
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more