今天，我刚刚发现可以使用该copy /b命令合并某些文件。特别是，我注意到当我合并两个 mp3 文件时，VLC 播放器在时间上表现出奇怪的行为：
这里，很正常，但是第一首音乐即将结束......然后有趣的部分随之而来......
在这里，时间搜索实际上是在播放的同时运行的。
使用此技术合并图片或 PDF 时，我发现文件大小会正确增加，但只会显示第一张图片。
所以我的问题是：这个copy /b命令到底有什么用？它真的是用来合并文件的吗？还是这只是一个黑客行为？
答案1
/b该命令的标志将copy文件视为二进制（即，无意义的字节的原始流），并逐字节复制它们，而不是默认（或/a）行为将它们视为文本行（带有行尾字符、文件结束符等）。
您可以使用默认文本行为或二进制开关合并文本文件，但基本上任何二进制文件将无法工作。您不能简单地从两个二进制文件中复制字节并期望它们能够工作，因为二进制文件通常具有标题，元数据，数据结构等定义文件格式的规则。如果您进行二进制复制，那么您将只是按原样复制所有字节，最终将这些结构放在它们不应该出现的位置，因此当您打开它们时，解析函数将遇到问题并查看哪些是损坏的数据。有些程序会忽略无意义的部分，只显示它们可以显示的内容（这允许立体摄影工作），但有些程序会抛出错误并抱怨文件已损坏。检测损坏的能力取决于文件类型。
作为示例，让我们发明一种简化的 PDF 格式：
Byte(s) Meaning
---------------------
File header:
0-1 # of Pages
2-3 Language
4-5 Font
6-EOF Data (each page encoded separately)
Page data:
0-1 Page number
2-3 # of characters on page
4-#chars Letters contained on the page
如您所见，每个文件都包含一个文件级标头，其中包含一些常规信息，后面是包含页面数据的每个页面的数据块。如果您将两个文件（每个文件包含一页）合并为二进制文件，那么您将不会创建一个包含两页的文件，而是一个损坏的文件，该文件以一页开始，然后包含一堆垃圾（当程序尝试读取第二页时，文件标头毫无意义）。
您的 MP3 也会发生同样的事情。当您像这样组合它们时，ID3 标签第二个文件的开头和/或结尾处的声音被保留，当播放器尝试读取下一帧时，它期待的是音频数据，但发现第二个文件的标题与音频数据的预期格式不匹配，因此它不知道该怎么做。有些播放器会将标题作为音频数据播放（可能会播放为静态/噪音/爆音/等），有些会切断声音直到下一个正确的帧，有些可能会完全停止播放歌曲，有些甚至会崩溃。
该copy命令对纯文本以外的文件类型一无所知（即使如此，也只知道 ASCII 文本），因此只有纯文本才能与其正确组合。二进制文件必须使用知道如何正确解析和解释内容的编辑器进行组合。
答案2
很久以前，在 Win ME 时代，我用它来简单地连接视频剪辑。它并不总是有效，但有时确实有效。
这是我使用的命令的示例：
copy /b movie1.mpg + movie2.mpg + movie3.mpg movie4.mpg
如果影片不是太大，且类型、帧速率等都相同，它们通常可以完美合并。最近没有尝试过这样的事情。
答案3
在您的示例中，对于 MP3，由于 MP3 的编码方式，它可能会给出奇怪的行为。例如，ID3v1 标签是 MP3 的最后 128 个字节（即艺术家、专辑等）。此信息不可“播放”。当 VLC 或其他媒体播放器打开 MP3 时，它（可能）会播放第一个 MP3，对信息做出奇怪的反应，然后可能播放文件的其余部分。我现在没有加载 Windows，所以我无法进行确定的测试。
我认为这与图像和电影相同；文件的编码方式决定了文件将如何“组合”。我猜想此功能源自 DOS 时代，当时所有内容都是纯文本
答案4
关于 MP3，大致来说，标头后面的内容都可以作为数据读取。有一款游戏，Sega Genesis 中的 Sonic 3 和另一款名为 Sonic & Knuckles 的游戏。Sonic & Knuckles 的原始卡带有一个用于插入其他游戏的插槽，但是当添加 Sonic 2 和特别是 3 时，校验和可能会触发另一组指针，游戏的行为会有所不同。在使用 ROM 的早期阶段，每当我们想让两个卡带像在硬件中一样工作时，我们都会使用copy /b sonick.bin+sonic3.bin sonic3k.bin。这样，它们的合并将产生一个大的单个 ROM，其中 sonick 将具有指令集（指针）以使其使用 sonic3 资源。