Abriu uma imagem JPG com o bloco de notas, colou todo o “texto” em um novo arquivo do bloco de notas, mudou para .JPG e não abre mais. Por quê?

Question

Esse fenômeno me deixou perguntas a fazer.

Aqui está o experimento detalhado, meu sistema operacional é o Windows 7 x64 SP1:

• Eu mudei um arquivo de imagem (JPG) para TXT simplesmente mudando sua extensão (ou poderia apenas escolher abrir o JPG com o bloco de notas, a mesma coisa)

Deveria ter esta aparência, estranhamente procurando sequências de textos, e alguns deles (muito raros) são realmente significativos, como na imagem abaixo "creator: dg-jpeg v1.0 ..."

• DesativeiaopçãodeagrupareselecioneitodootextousandoCtrl+A(paratercertezadequenadafoiperdido)
• EucoleiotextocopiadoemoutroarquivoTXTembrancoeosalveicomoJPG,compareionovotamanhodoarquivocomoJPGoriginal.Todoseles(oJPGoriginal,oarquivoTXTconvertidoeoarquivoTXTrecém-criado)têmomesmotamanhoexato,parabytes.

Quandotenteiabrir,oWindowsdizia"O Windows Photo Viewer não pode abrir esta imagem porque o arquivo parece estar danificado, corrompido ou muito grande" .

Eu até tentei testá-lo usando outro método: Abrai o JPG com o bloco de notas, cortei UM caractere conhecido de um local fácil de lembrar (como o primeiro caractere da segunda linha) e salve o Arquivo. O visualizador mostraria a mesma mensagem. Então abri novamente e colei o caractere no local EXATO (o Notepad lembra seu estado de saída como posição do windows, quebra automática, tamanho das fontes ... então não tenho nenhum problema em fazer isso direito)

E ainda o mesmo erro. Você pode tentar isso para ter uma idéia, lembre-se de escolher uma imagem pequena que o Bloco de Notas funcionará como um velho homem enferrujado.

O que poderia ter sido a causa desse fenômeno?

    

Answer 1

Dependendo da codificação usada para abrir o arquivo, você pode ver um comportamento diferente. O meu bloco de notas do Windows 7 permite abrir um arquivo em ANSI, UTF-8, Unicode ou Unicode big endian.

Eu testei esse problema com uma pequena imagem jpeg de 2x2 pixels criada com o gimp e abrindo e salvando o arquivo de imagem com codificação ANSI. Abrindo tanto a imagem original quanto a salva com um editor hexadecimal, vejo que todas as 00 seqüências (dois dígitos hexadecimais, caractere de controle NUL ) foram convertidos para 20 (caractere de espaço).

Substituindo de volta no editor hexadecimal, todos os 20 por 00 restauram o formato da imagem.

Eu pesquisei um pouco no Google e não encontrei referências que explicassem por que isso acontece. Apenas uma referência a um post que avisa sobre (link de cache do google, a página não está disponível).

Se você salvar / abrir o arquivo como UTF-8, ele ainda converterá caracteres NUL em espaços, mas também aumentará o tamanho do arquivo resultante devido a conversões de caracteres de byte único para seqüências de bytes múltiplos UTF-8. / p>

Se você salvar / abrir o arquivo como Unicode, parece que ele ainda converte caracteres NUL em espaços, mas também adiciona um byte ao início do arquivo, o BOM .

    

Answer 2

Por que falha:

O bloco de notas cria espaços (ASCII code 32) caracteres para caracteres como NUL (ASCII code 0) porque a caixa de texto da API do Windows permite somente o final terminado char * ASCIIZ (matriz de caracteres, ponteiro) . É cortado na primeira NUL.

Isso acontece porque a API do Windows é escrita principalmente na linguagem C e sequências com terminação nula é um dos recursos mais comuns. Mesmo quando o Windows moderno e o Unicode são considerados iguais, ocorrem sequências terminadas por nulo. Assim, o bloco de notas simplesmente os substitui por espaço para que você possa visualizar o arquivo completo.

Então, quando você salva o arquivo, ele está corrompido.

strings com terminação wikipedia-null

Como fazer mais pesquisas:

Você pode usar um comparador como além de comparar (comercial, teste) para ver o efeito de substituição de caractere. veja também outras ferramentas de comparação binária .

Nota:(20)₁₆=(32)₁₀

Razãoparaoblocodenotasatualentamenteemarquivosgrandes

Eleverificacadacaractereesubstituicaracteresespeciaisporespaços.Outrossoftwaresnãofazemconversõesnamemória(pelomenosnãoprimitivocomoonotepad).Elesapenasprocessamcaracteresespeciaisdeformadiferente.Eelesusamtécnicasavançadasdebuffering.

ExaminandooNotepad.exe(XP32bit)

(EstouassumindoqueaindaestáescritoemC++oupelomenosuseum linker similarmente similar)

EstouusandoaferramentaPEiD(queinterrompeuodesenvolvimentocomaintroduçãodePE+/64exes)

PEiDpodeserencontradonapastabindo Extrator Universal

Eu extraí o bloco de notas. ex_ arquivo do iso do Windows xp, obviamente. Experimente. É um extrato de arquivo cab usando 7z.

Atenção! Seu scanner de vírus pode detectar o Universal Extractor / PEiD como ferramentas de hackers ou vírus. Não confie, não faça o download !!

Mais informações sobre a API do Windows

créditos: Jason C

Não é apenas a caixa de texto; WM_SETTEXT em geral não fornece nenhum parâmetro para especificar o comprimento da cadeia e as cadeias são sempre assumidas como terminadas em nulo. Você sempre pode criar uma caixa de texto personalizada com uma mensagem personalizada que especifique o tamanho da seqüência de caracteres, mas o Bloco de Notas e a maioria dos outros programas não o fazem. Além disso, a função SetWindowText não fornece uma parâmetro de comprimento também.

    

Answer 3

O bloco de notas não preserva todos os caracteres especiais / estendidos exatamente como eles são. Eu não tenho uma referência para esse comportamento imediatamente à mão, mas descobri que este é o caso, por exemplo, com o fim de linha de estilo UNIX LF que o Notepad irá converter em CRLF e null (0x00), que ele irá ignorar. Em um arquivo binário, como um JPG, é provável que ocorram ocorrências aleatórias dos caracteres que o Bloco de Notas não preserva. Experimente o seu experimento com um editor sensível ao HEX e ele deve funcionar então. Vou atualizar minha resposta se encontrar uma boa referência e depois de testar um editor HEX.

Atualização: experimentei alguns editores de programadores conhecidos, mas apenas um deles trabalhou logo de cara, HxD de Maël Hörz . Eu nunca usei o HxD antes, mas achei isso graças a uma resposta a este artigo do Stack, Um plugin hexadecimal de visualização / edição para o Notepad ++ .

Os outros editores que não trabalharam depois de alguns minutos foram o Notepad ++, Notepad2 e UltraEdit (v17.3, versão anterior). Alguns deles tiveram problemas com a cópia / colagem dos primeiros bytes, o número mágico da assinatura do arquivo FF D8 FF do JPEG . Talvez eles trabalhassem com um pouco mais de mexer do que eu tenho no momento.

    

Answer 4

Você costumava fazer isso com o recurso Escrever novamente no mesmo dia. Era um programa padrão no Windows 3.1, mas não me lembro se o Windows 95 o incluiu. A gravação permitiria a edição segura e binária de qualquer arquivo que pudesse ser aberto (provavelmente com tamanho de arquivo muito limitado). O Bloco de Notas definitivamente não é seguro em binário (o texto permanece o mesmo, mas os bytes reais de caracteres que não são de texto [por exemplo, códigos de controle] podem mudar) e é por isso que o seu exemplo JPG não está funcionando. Tente obter uma cópia do Write (e do Windows antigo) e tente novamente a experiência!

De acordo com o artigo "Windows Write" da Wikipedia , o Write foi incluído no Windows NT 3.5. Foi substituído pelo Wordpad no Windows 95 em diante. write.exe ainda estava presente no diretório do Windows, mas era simplesmente um invólucro para abrir o Wordpad.

    

Answer 5

Acho que não é tanto um problema de codificação, mas também de conjunto de caracteres. O formato JPG é basicamente um fluxo de bytes. Permitindo assim caracteres não imprimíveis como NUL, ETX, STX, SOH, DLE, etc.

O Bloco de notas da Microsoft não pode exibir esses caracteres não imprimíveis. Pode exibir espaços reservados de algum tipo como um espaço para um caractere nulo. Então, abrir o arquivo com o Bloco de Notas não mostra o conteúdo real, mas o conteúdo decodificado pela codificação selecionada (utf-8, utf-16, etc) e exibido por um determinado conjunto de caracteres (unicode, ascii, etc) excluindo o não caracteres imprimíveis.

Ao selecionar todo o texto exibido e copiar o texto na área de transferência, você copia apenas os caracteres imprimíveis, incluindo os espaços reservados. Assim convertendo automaticamente caracteres nulos para espaços e ignorando outros caracteres não imprimíveis inteiramente.

Então, basicamente, você só perde o conteúdo fazendo assim. Se você usar um editor hexadecimal, copiará todo o conteúdo.

Atualização: A resposta de Bhathiya Pereras está certa: link Caracteres não imprimíveis não são ignorados ao copiar texto para a área de transferência.

    

Answer 6

O arquivo JPEG contém dados que não são de texto, exceto alguns campos. Basicamente, qualquer valor de byte entre 0 e 255 será encontrado, especialmente na área que representa a imagem compactada codificada que contém dados quase pseudo-aleatórios.

Mas o Bloco de Notas tratará os dados como ANSI por padrão, por isso, fará várias coisas que alterarão os dados originais, como:

• substitua os bytes como especiais / indefinidos / proibidos, pois eles não fazem sentido para um texto ANSI válido

• codifique caracteres nulos, sequências de fim de linha e fim de arquivo para as convenções do Windows / DOS

O que significa que, se você editar e salvar os dados como texto, o jpeg será alterado no melhor dos casos e inutilizado no pior dos casos.