我在从 Windows 批处理文件执行复制命令时注意到了一些奇怪的事情，想知道是否有人遇到过这种情况并可以解释原因。
我在批处理文件中有一行将 Excel 文件从位置 A 复制到位置 B，并重命名该文件。例如：
Copy \\server\share\folder\locationA\file_*.xlsx \\server\share\folder\locationB\file.xlsx /y
复制看起来完成得很好，因为 Excel 文件位于位置 B，但是当我打开该文件时，收到一条错误消息，指出：
“Excel 无法打开该文件...因为文件格式或文件扩展名无效。请验证该文件是否已损坏并且文件扩展名是否与文件格式匹配。”
我使用上述命令行运行了一些测试，并注意到仅当我在 A 部分的文件名中使用通配符时才会发生此问题。例如，文件复制后，我可以使用以下命令正常打开它：
Copy \\server\share\folder\locationA\file_LongName.xlsx \\server\share\folder\locationB\file.xlsx /y
我知道有很多方法可以解决这个问题，但我对解决方案不感兴趣，我感兴趣的是解释。我的问题是为什么会发生这种情况？
答案1
您看到此问题的原因是通配符模式将COPY命令切换到连接模式，该模式专为纯文本 ASCII 文件而设计。在 ASCII 模式下，二进制文件中的某些数据看起来像“文件结束”字符。
Excel .XLSX 文件本质上是具有不同扩展名的 Zip 档案，并且 Zip 档案是二进制文件，而不是 ASCII。该COPY命令将此二进制文件视为 ASCII 文件，并尝试将内容与空文件连接起来。
有人可能会认为，连接一个没有任何内容的文件会给你与开始时相同的文件，但在这种情况下并非如此。
该COPY命令继续处理文件，直到达到文件结束 (EOF) 字符一旦到达该字符，它将继续处理下一个文件。（在这种情况下，它会完全停止处理。）
您的二进制 Excel 文件包含数据，当转换为 ASCII 时，这些数据代表 EOF 字符，因此文件的连接比预期的更早结束。
为了说明这一点，我使用您的COPY命令将 7zip 文件与空白 Excel 文件连接起来（我只是将它们重命名为file_1.xlsx和file_2.xlsx）。我在 Notepad++ 中打开了 7zip 文件和输出文件，并使用 WinMerge 比较了内容。
正如您在图片中看到的，这两个文件直到(1A)字符为止都是相同的。
接下来，我连接了两个纯文本文件，运行起来毫无问题。但是，一旦我将此(1A)字符（在 Notepad++ 中显示为(sub)）插入其中一个文本文件，我就能确认命令COPY恰好在该位置停止并转到下一个文件。
