O motivo pelo qual você está vendo esse problema é que o padrão curinga muda o comando COPY
para o modo de concatenação, que é projetado para arquivos ASCII de texto simples. No modo ASCII, alguns dados em arquivos binários parecem um caractere "End of File".
Arquivos Excel .XLSX são essencialmente arquivos Zip com uma extensão diferente
e arquivos Zip são arquivos binários, não ASCII. O comando COPY
está tratando esse arquivo binário como um arquivo ASCII e tentando concatenar o conteúdo com nada.
Pode-se pensar que concatenar um arquivo com nada lhe daria o mesmo arquivo com o qual você começou, mas não neste caso.
O comando COPY
continua processando um arquivo apenas até atingir um caracter End of File (EOF) . Quando alcança esse personagem, continua no próximo arquivo. (Neste caso, ele pára completamente o processamento.)
Seus arquivos binários do Excel contêm dados que, quando convertidos em ASCII, representam caracteres EOF e, portanto, a concatenação do arquivo termina antes do esperado.
Para ilustrar isso, usei o comando COPY
para concatenar um arquivo 7zip com um arquivo em branco do Excel (acabei de renomeá-los como file_1.xlsx
e file_2.xlsx
). Eu abri o arquivo 7zip e o arquivo de saída no Notepad ++ e comparei o conteúdo usando o WinMerge.
Comovocêpodevernaimagem,osdoisarquivossãoidênticosatéocaractere(1A)
.
Emseguida,concateneidoisarquivosdetextosimples,quefuncionaramperfeitamente.Noentanto,depoisqueinseriessecaractere(1A)
(queaparecenoNotepad++como(sub)
)emumdosarquivosdetexto,confirmeiqueocomandoCOPY
parouexatamentenessepontoepassouparaopróximoarquivo.