# MP4 改后缀成 ZIP 竟然能解压?视频+压缩包二合一文件的原理与制作方法

## 一、这是个什么现象?

先说结论:这不是黑科技,也不是文件坏了,而是有人把**一个压缩包直接拼到了一个视频文件的后面**。

具体表现是这样的:

1. 你拿到一个 `.mp4` 文件,双击正常播放,画面声音都没问题;
2. 把后缀名改成 `.zip`,它突然变成了一个能解压的压缩包,里面还藏着别的文件;
3. 改回 `.mp4`,又能继续当视频看。

一个文件,两种身份,自由切换。这种玩法有个专业名字:**多面体文件(Polyglot 文件)**,俗称"伪装文件"。

看完这篇文章,你能学会三件事:①看懂它的原理;②自己一分钟做一个;③用脚本检测手头的文件是不是这种结构。

## 二、一句话原理

如果只记一句话,记这个:

> **视频播放器只从文件"开头"读数据,解压软件只从文件"结尾"读数据。把压缩包拼在视频后面,两边软件各看各的,互不打架。**

打个比方你就懂了:

- **MP4 像一本从第一页开始正着读的书**——读者从封面开始一页页翻;
- **ZIP 像一本"总目录订在最后一页"的书**——读它的人会直接翻到书尾找目录,再按目录找内容。

现在把 ZIP 整本"订"到 MP4 这本书的后面:

- **看视频的人**:从第一页读起,读完 MP4 的正文就"全书完"了,后面订着什么他根本不翻;
- **解压的人**:直接翻到最后一页找到 ZIP 的目录,按目录取文件,前面订着什么他根本不看。

同一个文件,两种读法,谁也不干扰谁。就这么简单。

## 三、三分钟自己做一个

只需要一条命令,不需要装任何专业软件。

**Windows**:打开 cmd,执行(`copy /b` 表示按二进制拼接):

```
copy /b 视频.mp4+压缩包.zip 输出.mp4
```

**Linux / macOS**:

```
cat 视频.mp4 压缩包.zip > 输出.mp4
```

做出来的 `输出.mp4` 就是二合一文件:双击是视频,改成 `.zip` 后缀就是压缩包。

两个注意点,做到效果更好:

1. **顺序不能反:视频在前,压缩包在后。** 原因见第二节——压缩包必须待在文件末尾(解压软件只看末尾);视频放前面,尾巴上挂多少东西都不影响播放。
2. 最好先把视频转成"快速启动"格式(moov 数据提前,网盘在线播放秒开):

   ```
   ffmpeg -i 输入.mp4 -c copy -movflags faststart 输出.mp4
   ```

使用方法:想看视频,保持 `.mp4` 后缀或直接拖进播放器;想解压,把后缀改成 `.zip`,用 7-Zip、WinRAR 或 Windows 自带解压都行。

## 四、深入一点:字节层面它长什么样?

这一节给想深挖原理的读者,全是可验证的实测数据,不感兴趣可直接跳到第五节。

我实际拆解过一个 933MB 的"二合一文件",它的内部结构就两段,严丝合缝拼在一起:

| 偏移范围(字节) | 内容 |
|---|---|
| 0 ~ 182,568,372 | 完整的 MP4 视频 |
| 182,568,372 ~ 933,420,084 | 完整的 ZIP 压缩包(750MB) |

### 4.1 前半段:播放器怎么认出 MP4

每种文件格式开头都有"身份标识"(专业叫**魔数**,可以理解为文件开头的身份证)。MP4 的身份证是第 5~8 个字节的字母 `ftyp`,播放器靠它认出"这是个 MP4"。

MP4 内部像一列火车,由一节节"车厢"(专业叫 **box**)连成:每节车厢开头 8 个字节,前 4 个字节写"这节车厢多长",后 4 个字节写"是什么车厢"。顺着长度一路往下跳,就能走完整列火车。实测这个文件的火车:

```
@0          "ftyp"  长 32        ← 身份标识
@32         "moov"  长约 1MB     ← "目录",记录每一帧画面在哪
@1004499    "free"  长 8         ← 空车厢,占位用
@1004507    "mdat"  长约 1.8 亿  ← 货车厢,装真正的画面和声音
```

走完这 4 节车厢,正好是 182,568,372 字节,再往后就不是合法车厢了——**MP4 部分到此为止,后面全是拼上来的 ZIP**。

播放器的工作路径是:开头认身份 → 读 `moov` 这本目录 → 按目录到 `mdat` 里取画面。**全程只在前面 182MB 里活动,后面拼的 750MB 它碰都不碰**,所以视频播放完全正常。

### 4.2 后半段:解压软件怎么认出 ZIP

ZIP 的设计跟 MP4 相反:它的"总目录"(专业叫**中央目录**)放在**文件最末尾**,最后还有一个固定的"结束标记"(EOCD,魔数 `PK\x05\x06`)。

解压软件打开文件的第一步:**从文件末尾往前翻**,找到结束标记 → 顺着它找到中央目录 → 按目录里记录的位置把每个文件解出来。文件开头是什么?它压根不看。

所以整个文件的读取路径是这样的:

```
┌─────────────────────┬───────────────────────────┐
│   MP4 视频(182MB)   │   ZIP 压缩包(750MB)        │
└─────────────────────┴───────────────────────────┘
 ↑ 播放器从头读,182MB 处就"读完了"     解压软件从尾往前找 ZIP ↑
```

实测这次拆解,由 ZIP 末尾的结束标记反推出压缩包的起点,正好等于 MP4 部分的结束位置,一个字节都不多——纯粹的两文件拼接,没有任何加密或变形。

### 4.3 一个容易翻车的细节:偏移要"重新对表"

ZIP 的中央目录里记录的每个文件位置,是**相对 ZIP 自己开头**的距离。拼接之后,ZIP 整体被推后了 182MB,这些记录就全"不准"了。

不过不用慌:主流解压软件(7-Zip、WinRAR、Windows 自带)都会自动"重新对表"——先算出 ZIP 实际从哪里开始,再给所有位置记录统一加上这段偏移,所以日常使用都能正常打开。极少数老旧工具不支持,可以用 `zip -FF 文件.zip --out 修复.zip` 把记录修正。

## 五、检测脚本:一眼看穿伪装文件

把上面的拆解过程写成了一个脚本,Node 直接运行,自动打印文件的完整布局和 ZIP 内容:

```js
// polyglot_check.mjs — 检测"视频+压缩包"二合一文件
// 用法: node polyglot_check.mjs <文件路径>
import fs from 'node:fs';

const path = process.argv[2];
const fd = fs.openSync(path, 'r');
const size = fs.fstatSync(fd).size;
console.log(`文件: ${path}\n大小: ${size} 字节`);

// 1. 读文件头, 确认是不是 MP4
const head = Buffer.alloc(32);
fs.readSync(fd, head, 0, 32, 0);
console.log('\n== 文件头 ==');
console.log(head.subarray(0, 16).toString('hex'));

// 2. 遍历 MP4 顶层 box, 找到 MP4 部分的结束点
console.log('\n== MP4 顶层 box ==');
let off = 0;
while (off + 8 <= size) {
  const b = Buffer.alloc(8);
  if (fs.readSync(fd, b, 0, 8, off) < 8) break;
  let boxSize = b.readUInt32BE(0);
  const type = b.subarray(4, 8).toString('latin1');
  if (boxSize === 0) boxSize = size - off;                  // size=0 表示延伸到文件尾
  else if (boxSize === 1) {                                 // 64 位大 size
    const ext = Buffer.alloc(8);
    fs.readSync(fd, ext, 0, 8, off + 8);
    boxSize = Number(ext.readBigUInt64BE(0));
  }
  if (boxSize < 8 || !/^[\x20-\x7e]{4}$/.test(type)) break; // 不是合法 box → MP4 到此为止
  console.log(`  @${off}  ${JSON.stringify(type)}  size=${boxSize}`);
  off += boxSize;
}
console.log(off === size
  ? 'MP4 正好占满整个文件(纯视频)'
  : `MP4 在 ${off} 处结束, 尾部还挂着 ${size - off} 字节非 MP4 数据`);

// 3. 从文件尾找 ZIP 的结束标记(EOCD, 魔数 PK\x05\x06)
const tailStart = Math.max(0, size - 131072);
const tail = Buffer.alloc(size - tailStart);
fs.readSync(fd, tail, 0, tail.length, tailStart);
let eocd = -1;
for (let i = tail.length - 22; i >= 0; i--) {
  if (tail[i] === 0x50 && tail[i+1] === 0x4b && tail[i+2] === 0x05 && tail[i+3] === 0x06) { eocd = i; break; }
}
if (eocd === -1) {
  console.log('\n尾部未找到 ZIP 结束标记, 尾部数据不是 zip');
  process.exit(0);
}
const absEocd  = tailStart + eocd;
const entries  = tail.readUInt16LE(eocd + 10);
const cdSize   = tail.readUInt32LE(eocd + 12);
const cdOffRel = tail.readUInt32LE(eocd + 16);

// 4. 反推 zip 起点 = EOCD绝对位置 - 中央目录大小 - 中央目录偏移
const zipStart = absEocd - cdSize - cdOffRel;
console.log('\n== ZIP ==');
console.log(`推算 zip 起点: ${zipStart}`);
const probe = Buffer.alloc(4);
fs.readSync(fd, probe, 0, 4, zipStart);
console.log('起点字节:', probe.toString('hex'),
  probe[2] === 3 ? '(ZIP 本地文件头, 拼接成立)' : '(不是本地文件头!)');

// 5. 列出 zip 里的文件
console.log('\n== zip 内条目 ==');
let p = zipStart + cdOffRel;
const nb = Buffer.alloc(512);
for (let i = 0; i < entries; i++) {
  fs.readSync(fd, nb, 0, 46, p);
  if (!(nb[0] === 0x50 && nb[1] === 0x4b && nb[2] === 0x01)) { console.log('  解析中断'); break; }
  const nameLen  = nb.readUInt16LE(28);
  const compSize = nb.readUInt32LE(20);
  const method   = nb.readUInt16LE(10);
  const name = Buffer.alloc(nameLen);
  fs.readSync(fd, name, 0, nameLen, p + 46);
  console.log(`  - ${name.toString('utf8')}  压缩后=${compSize}  方法=${method === 0 ? 'store' : method === 8 ? 'deflate' : method + '(AES加密等)'}`);
  p += 46 + nameLen + nb.readUInt16LE(30) + nb.readUInt16LE(32);
}
```

拿那个 933MB 的文件跑一遍,输出:

```
MP4 在 182568372 处结束, 尾部还挂着 750851712 字节非 MP4 数据
推算 zip 起点: 182568372
起点字节: 504b0304 (ZIP 本地文件头, 拼接成立)
  - L28/re sister.7z  压缩后=750851404  方法=99(AES加密等)
```

MP4 的结束点和 ZIP 的起点完全重合,一目了然。

## 六、常见问题

**Q1:拼接后的视频播放会卡顿、缺内容吗?**

不会。播放器严格按 `moov` 目录取数据,目录里没有的它不读。唯一的"副作用"是文件变大了。

**Q2:为什么我把 zip 拼在前面就不行?**

因为解压软件只认**文件末尾**的结束标记。zip 在前面时,文件末尾是视频数据,它找不到目录自然打不开。视频在前、zip 在后是唯一正确顺序。

**Q3:网盘会识别出里面藏的压缩包吗?**

文件在网盘眼里就是一个普通 MP4——网盘一般也只看文件头。这类"伪装"的主要用途之一,正是绕过部分网盘对压缩包文件的下载限制或审查。

**Q4:图片也有这种玩法吗?**

有,而且更经典,叫**图种**:JPG 格式天生允许在结尾挂额外数据,把 ZIP 拼在图片后面,图片照常显示、改后缀又能解压。原理和本文完全相同,也是"一头一尾"的组合。

## 七、总结

- 这类二合一文件的本质:**视频 + 压缩包直接拼接**,没有任何加密或格式转换;
- 能成立的原因:**MP4 从文件头读,ZIP 从文件尾读**,两个解析器互不越界;
- 制作:一条 `copy /b`(Windows)或 `cat` 命令,要点是**视频在前、压缩包在后**;
- 检测:文末脚本跑一遍,拼接点和压缩包内容一目了然;
- 提醒:技术本身中性,但请勿用于传播盗版资源;格式研究、CTF 解题、自用备份才是正确用法。

如果这篇文章帮你搞懂了"视频怎么变成压缩包",欢迎点赞收藏;有疑问欢迎评论区交流。

先说结论:这不是黑科技,也不是文件坏了,而是有人把一个压缩包直接拼到了一个视频文件的后面。

MP4 改后缀成 ZIP 竟然能解压?视频+压缩包二合一文件的原理与制作方法

开发工具

MP4伪装ZIP二合一文件原理：视频拼接压缩包实现双格式共存，播放器读文件头、解压软件读文件尾互不干扰。掌握制作方法、检测技巧与常见问题，附脚本实现自动识别，揭示文件真实结构。

代码解释

Windows

MacOS

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MP4 改后缀成 ZIP 竟然能解压?视频+压缩包二合一文件的原理与制作方法-腾讯云开发者社区-腾讯云

MP4 改后缀成 ZIP 竟然能解压?视频+压缩包二合一文件的原理与制作方法

MP4 改后缀成 ZIP 竟然能解压?视频+压缩包二合一文件的原理与制作方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐