离线 · 无上传 · 浏览器本地完成Offline · no uploads · runs in the browser
GIF 转 Word——离线、帧数据进包、播不播由 WordGIF to Word offline — all frames in the package
这条路常被误解成「GIF 进 Word 就只剩一张静态图」，而**它其实不做取帧这一步**。链是 `gif>html` + `html>docx`（路径基线现读）：第一步把文件的**原始字节**用 `FileReader.readAsDataURL` 编成 data URI 写进一个 `<img>`，第二步 `html>docx` 先净化、再剥掉远程引用，最后打包器把 `<img>` 上那条 `data:` **从标记里提出来写成包里独立的 base64 媒体部件**并重写引用——判据不是注释，是 `scripts/e2e-test.mjs:2271-2275` 那条用夹具专属载荷钉住的用例（它刻意避开通用 PNG 头，防止「图被吃掉仍绿」）。所以：**每一帧都还在包里**，`.docx` 里没有 data URI 残留，而且显示这张图不需要任何一次取数。要说清的是另一半：**播不播、循环几遍由打开它的程序决定**。动图能否播放是 Word 那一边对 GIF 媒体部件的处理方式说了算，本扩展只承诺数据侧完整；这跟 GIF→PNG / JPG 那几条形成对照——那几条**必须**过画布，交付的就是一帧，而且提示只会固定说「只保留第一帧」（`lostFrames` 是布尔值，从不报帧数）。文档体则是 altChunk：逐字排版、分页与图片的最终显示尺寸都由 Word 打开时决定，本扩展不产出 Word 原生段落，也不给缩放参数。类型前提也照写：从 ZIP 解包出来的文件不带 MIME 类型，那条 data URI 前缀会是 `application/octet-stream`，不在图片白名单里，会在写出前被剥掉 `src`（`utils/core/html-sanitize.ts:83`）。想真正做一张静态图进文档，请走 GIF→PNG 再 GIF→Word 之类；想要动图本身，这一路与 GIF→HTML 是同一份字节。This route is commonly mistaken for "GIF into Word, and only a still survives" — **it takes no frame-selection step at all**. The chain is `gif>html` + `html>docx`, read live from the route baseline: step one encodes the file’s **raw bytes** with `FileReader.readAsDataURL` into a data URI inside an `<img>`, and step two sanitises, strips remote references, then lets the packer **lift that `data:` off the markup into its own base64 media part** and rewrite the reference. The proof is not a comment but the end-to-end case at `scripts/e2e-test.mjs:2271-2275`, pinned with a fixture-unique payload so an eaten image cannot stay green. So every frame is still inside the package, no data URI survives in the `.docx`, and drawing it costs no fetch. The other half is what must be said plainly: **playback belongs to whatever opens the file**. Whether the animation runs is how Word treats a GIF media part, and this extension only guarantees the data side. The contrast is GIF to PNG or JPG, which *must* pass over a canvas, deliver one frame, and disclose it with a fixed «first frame kept» notice — `lostFrames` is a boolean and never a count. The document body is an altChunk, so typesetting, paging and the picture’s displayed size are Word’s when it opens; no native paragraphs and no scaling knobs come from here. The type caveat stays on the page too: a file unpacked from a ZIP carries no MIME type, so its data URI prefix is `application/octet-stream`, which is outside the image allow-list and loses its `src` before writing (`utils/core/html-sanitize.ts:83`). Want a genuine still inside a document, take GIF to PNG first; want the animation itself, this route carries the same bytes as GIF to HTML.
这条链路怎么走How the route runs
GIFGIF HTMLHTML Word (.docx)Word (.docx)
共 2 步，由扩展的路径搜索自动选出，中间产物不落盘。2 steps, chosen by the extension's own path search; intermediate results never touch the disk.
会保留什么What carries over
- 不做取帧这一步：整份动图的字节原样进包，一帧都不少No frame-selection step: the whole animation goes into the package, frame for frame
- data URI 被提成包里独立的图片部件，`.docx` 内不留 data URI，显示它不需要取数The data URI is lifted into its own image part, so no data URI survives and drawing it needs no fetch
- 远程引用在写出前剥掉——那份标记由 Word 在你机器上渲染，请求不该由这条链替你决定Remote references are stripped before writing, because Word renders that markup on your machine — a request is not this chain’s call
- 文档体是 altChunk：本扩展不猜 Word 的分页，也不产出原生段落The body is an altChunk: no guessing at Word’s pagination and no native paragraphs produced here
- 一批最多 200 个文件、单个 100 MB，与其他路线共用同一道闸门Up to 200 files per batch and 100 MB each — the same gate every other route shares
如实说明的限制What it does not do
- 播不播由 Word 决定：帧都在包里，但这一路不承诺动画在文档里跑起来Playback is Word’s call: every frame is in the package, but this route does not promise the animation runs inside the document
- 与 GIF→PNG / JPG 不同，这里没有「只留一帧」的固定提示——因为确实没减帧，也就没有可提示的损失Unlike GIF to PNG or JPG there is no fixed first-frame notice here — no frames were removed, so there is no loss to disclose
- 文档体是 altChunk：逐字排版、分页与图片显示尺寸由打开它的程序决定The body is an altChunk: typesetting, paging and the picture’s displayed size are decided by whatever opens it
- 从 ZIP 解包的文件不带类型，前缀是 `application/octet-stream`，会被剥掉 `src`、那一格留空A file unpacked from a ZIP has no type, so the prefix is `application/octet-stream` and the `src` is stripped, leaving an empty slot
- 不 OCR、不裁切、不改帧率：要改动画本身，本扩展没有对应功能No OCR, no cropping, no frame-rate editing: nothing here changes the animation itself
实操提示Working with it
- 只想放进网页：GIF→HTML 与这条共享第一步，动图在那边同样完整To put it in a web page: GIF to HTML shares this first step, and the animation is just as complete there
- 要一张静态图进文档：先 GIF→PNG（取首帧并固定提示），再 PNG→WordFor a still inside a document: GIF to PNG first (one frame, with the fixed notice), then PNG to Word
- 要 Markdown 里的图：GIF→Markdown 是第一步加一步序列化，负载同样是整份动图For a picture in Markdown: GIF to Markdown is step one plus a serialisation, with the whole animation as payload
常见问题Questions people actually ask
所以我的动图在 Word 里到底会不会动？So does my animation actually move inside Word?
这一路能保证的是帧数据一段没少：文件字节原样进包、被提成图片部件。会不会播放、循环几次，是 Word 对包内 GIF 部件的处理方式，本扩展无法替它承诺，也不在产物里加任何「强制静态」的处理。要一个确定不动的图，就走 GIF→PNG。What this route guarantees is that the frame data is complete: the file’s bytes go into the package untouched and become an image part. Whether it plays and how often it loops is Word’s handling of a GIF part, which this extension neither promises nor forces — it adds no «make it static» step. For a picture that certainly does not move, take GIF to PNG.
为什么 GIF 转 Word 不报「丢了几帧」？Why doesn’t GIF to Word report frames lost?
因为它没有丢帧可报：这条链不过画布。会报「只保留第一帧」的是需要重编码的那几条（GIF→PNG / JPG / WebP / PDF），而且那句是一句固定提示——帧数是布尔判断的结果，界面从不给出具体数字。Because there is no loss to report: this chain never enters a canvas. The routes that say «first frame kept» are the ones that must re-encode (GIF to PNG, JPG, WebP or PDF), and even there it is a fixed notice — the check yields a boolean, and the interface never prints a count.
图片会不会又变成「链接到本机某个路径」？Will the picture end up linked to a local path again?
不会。打包器把那条 data URI 写成包里独立的媒体部件，引用指向部件——换机器、换目录，读的都是包里那一份。真要说风险，是类型没被认出的时候（从 ZIP 解包），那种情况连部件都不会生成，那一格直接空着。No. The packer writes that data URI as its own media part and points the reference there, so another machine or folder still reads it from inside the package. The real risk is the unrecognised type — a file unpacked from a ZIP — where no part is created at all and the slot comes out empty.
不需要账号，也不需要联网：装好扩展后点图标，在新标签页里打开工作台，文件从磁盘直接选。No account and no network: install the extension, click its icon, and the workbench opens in a new tab reading straight off your disk.
从 Chrome 应用商店安装Install from the Chrome Web Store 安装步骤Install steps GitHub 源码Source on GitHub