Der Grund für dieses Problem besteht darin, dass das Platzhaltermuster den COPYBefehl in den Verkettungsmodus wechselt, der für Nur-Text-ASCII-Dateien konzipiert ist. Im ASCII-Modus sehen einige Daten in Binärdateien wie ein "Ende der Datei" aus.
.XLSX-Dateien in Excel sind im Wesentlichen Zip-Archive mit einer anderen Erweiterung, und Zip-Archive sind Binärdateien und keine ASCII-Dateien. Der COPYBefehl behandelt diese Binärdatei als ASCII-Datei und versucht, den Inhalt mit nichts zu verketten.
Man könnte meinen, eine Verkettung einer Datei mit nichts würde Ihnen die gleiche Datei geben, mit der Sie angefangen haben, aber in diesem Fall nicht.
Der COPYBefehl verarbeitet eine Datei nur so lange, bis ein EOF-Zeichen erreicht wird . Wenn dieses Zeichen erreicht ist, wird die nächste Datei angezeigt. (In diesem Fall wird die Verarbeitung vollständig abgebrochen.)
Ihre binären Excel-Dateien enthalten Daten, die bei der Konvertierung in ASCII EOF-Zeichen darstellen. Daher endet die Verkettung der Datei früher als erwartet.
Um dies zu veranschaulichen, habe ich Ihren COPYBefehl verwendet, um eine 7zip-Datei mit einer leeren Excel-Datei zu verketten (ich habe sie gerade in file_1.xlsxund umbenannt file_2.xlsx). Ich habe die 7zip-Datei und die Ausgabedatei in Notepad ++ geöffnet und den Inhalt mit WinMerge verglichen.
Wie Sie im Bild sehen können, sind die beiden Dateien bis zum (1A)Zeichen identisch .
Als nächstes habe ich zwei reine Textdateien verkettet, die einwandfrei funktionierten. Nachdem ich dieses (1A)Zeichen (das in Notepad ++ als angezeigt wird (sub)) in eine der Textdateien eingefügt hat, konnte ich jedoch bestätigen, dass der COPYBefehl genau an diesem Punkt angehalten und zur nächsten Datei verschoben wurde.
