大家好，我是前端西瓜哥。

上周圖形編輯器交流群里有人問，對于 Figma 導(dǎo)出的 fig 文件，該如何解析其格式，拿到可讀數(shù)據(jù)。

經(jīng)過群友的一番討論，這個(gè)問題最后算是解決了。

fig 文件

導(dǎo)出 Figma 的設(shè)計(jì)文件，我們會得到一個(gè) fig 文件。

fig 是一種二進(jìn)制的格式。

它沒有使用 XML 或是 JSON 的格式，而是選擇使用了 Figma 自己實(shí)現(xiàn)的特殊編碼工具進(jìn)行了序列化編碼，并做了封裝，最后得到一個(gè)二進(jìn)制文件。

二進(jìn)制相比明文格式（JSON 和 XML），優(yōu)點(diǎn)有：

• 體積更小，因?yàn)閿?shù)據(jù)更緊湊；
• 解析速度快，像是 JSON 這種，要逐個(gè)字符解析然后構(gòu)建 AST，考慮轉(zhuǎn)義、空格等特殊情況，對于大文件，解析效率很差；
• 高保真，比如一些類型明文格式其實(shí)是不好表達(dá)的，需要多做一層轉(zhuǎn)換（比如 Float32Array 類型，要保存為字符串就要轉(zhuǎn)為普通數(shù)組）；
• 安全性。因?yàn)榫幋a規(guī)則是應(yīng)用自己實(shí)現(xiàn)的，此外方便做加密（比如異或加密）。編碼和解碼的規(guī)則我們是無法知道的，除非它主動(dòng)公布出來，否則只能嘗試去做逆向。

先用 Figma 隨便畫幾個(gè)基本圖形。

然后導(dǎo)出 fig 文件，拿到了一個(gè)名為 fig-file.fig 的文件。

先用 vscode 打開看看。

不是文本文件，應(yīng)該就是二進(jìn)制文件了。

不管怎樣，強(qiáng)行用文本格式打開。

PK 打頭，應(yīng)該就是 ZIP 格式文件頭的標(biāo)識。

順便再查看一下這個(gè)文件的二進(jìn)制內(nèi)容，看到開頭這個(gè) 50 4B 03 04，說明確確實(shí)實(shí)是個(gè) ZIP 文件。

基本上很多應(yīng)用的導(dǎo)出文件都選擇 ZIP 格式，然后再把后綴名改成自己定義的，比如 fig、xmind。

使用 ZIP 格式有以下好處：

• 進(jìn)行了文件壓縮，體積更小，并且是單文件；
• 保留了目錄結(jié)構(gòu)；
• 跨平臺，基本所有主流操作系統(tǒng)都支持 ZIP。雖然用戶一般來說并不會手動(dòng)解壓它，但用戶安裝的應(yīng)用程序能直接使用操作系統(tǒng)的底層 API 去解壓，有助于減少應(yīng)用程序包體積；

解壓一下。

unzip fig-file.fig

解壓內(nèi)容

解壓后的內(nèi)容為：

.
├── canvas.fig
├── fig-file.fig # 這個(gè)是壓縮源文件
├── images
│   └── 0b15125516ae308a2d819f2970e851c0402949d2
├── meta.json
└── thumbnail.png

需要注意的是，解壓出來的內(nèi)容，并沒有一個(gè)根文件夾存放這些內(nèi)容。

但如果你用可視化界面去解壓，通常會解壓出一個(gè)文件夾，這個(gè)文件夾和壓縮包同名。

這個(gè)其實(shí)是操作系統(tǒng)的額外操作，目的是防止解壓出大量文件和當(dāng)前文件夾的其他文件混在一起了，可能還會有文件同名的問題。

canvas.fig 是真正的 Figma 數(shù)據(jù)內(nèi)容，記錄圖形樹中圖形的關(guān)系，以及圖形的屬性。

images 文件夾，存放的是圖片，給里面的文件加上 .png 后綴可查看圖片。

meta.json 是一些圖紙的基本信息，比如導(dǎo)出的客戶端使用的背景色，文件名等。

thumbnail.png 是預(yù)覽圖圖片，如果你裝了 figma 桌面端，則在會從 fig 提取出這個(gè)圖片給文件預(yù)覽器預(yù)覽。

等下，不對，canvas.fig？怎么又是 fig 文件，這是在玩套娃？

經(jīng)識別，也是個(gè)二進(jìn)制文件，但它的文件格式卻是。。。fig-kiwi？

Kiwi

這個(gè)叫做 Kiwi 的特殊格式被 Figma 的前 CTO，Evan Wallace 開源了。

https://github.com/evanw/kiwi。

Kiwi 是一種基于 Schecha 的二進(jìn)制格式，用于高效地對樹形數(shù)據(jù)結(jié)構(gòu)進(jìn)行編碼。

它受到 Google 的 Protoclol Buffer 格式的啟發(fā)，但更簡單，編碼更緊湊，且對自定義字段有更好的支持。

Kiwi 庫提供了工具，能夠解析二進(jìn)制文件轉(zhuǎn)換為編程語言中的對象，目前支持 JavaScript (TypeScript)、C++、Rust、Skew。

但要提供一個(gè) Schecha，來進(jìn)行類型的映射。

好在這個(gè) Schecha 有保存在 fig 文件里的。

canvas.fig 文件

實(shí)際上這個(gè) canvas.fig 文件并不是 Kiwi，它是一個(gè)復(fù)合產(chǎn)物。

首先開頭的 fig-kiwi 字符串是一個(gè)注釋，表示它是一個(gè) fig 文件（畢竟前面也看到了，fig 文件可能也是 ZIP），并使用了 kiwi 進(jìn)行編碼。

文件里有 Kiwi 的二進(jìn)制數(shù)據(jù)部分，也有 Schecha 部分，需要把它們提取出來。

這里要做 切片 了。

有個(gè)開源項(xiàng)目 Figma-To-JSON 成功解析了 fig，我們看看它怎么做的。

看了下，貌似是切在 50 89 這個(gè)地方，切好幾刀，得到一些切片。我們需要前兩個(gè)切片。

第一個(gè)切片是 Schecha，第二個(gè)是 Kiwi 數(shù)據(jù)。

每個(gè)切片都是 ZIP 壓縮的，需要先給它們解壓，然后再做 Kiwi 解碼。

import { ByteBuffer, compileSchema, decodeBinarySchema } from "kiwi-schema"

export const figToJson = (fileBuffer: Buffer | ArrayBuffer): object => {
  // 提取 fig 文件的 schema 和 kiwi 格式數(shù)據(jù)
  const [schemaByte, dataByte] = figToBinaryParts(fileBuffer)

  const schemaBB = new ByteBuffer(schemaByte)
  const schema = decodeBinarySchema(schemaBB)
  const dataBB = new ByteBuffer(dataByte)
  const schemaHelper = compileSchema(schema)

  // 這個(gè) json 對象就是最終結(jié)果了
  const json = schemaHelper[`decodeMessage`](dataBB)
  return convertBlobsToBase64(json)
}

流程總結(jié)一下，大致如下：

Figma-To-JSON

上面都是在說解碼 fig 文件的過程。

如果你只是想要得到 fig 的結(jié)構(gòu)，對過程不感興趣，可以直接用一個(gè)名為 Figma-To-JSON 的開源項(xiàng)目去解析。

https://github.com/yagudaev/figma-to-json。

下面是轉(zhuǎn)換結(jié)果，是一個(gè)一維數(shù)組，風(fēng)格類似 quill 的 delta。

每個(gè)節(jié)點(diǎn)保存有父節(jié)點(diǎn)的 id，可以關(guān)聯(lián)構(gòu)建出一棵圖形樹。

拿到 fig 數(shù)據(jù)格式有什么好處呢？

首先如果你開發(fā)自己的圖形編輯器，或者直接就是 Figma 的競品，你是要設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)的，那 fig 數(shù)據(jù)格式就有很好的參考價(jià)值。

然后就是做二次開發(fā)，寫一些工具做一些離線的批處理操作，比如提取 fig 的一些文本數(shù)據(jù)轉(zhuǎn)換為 excal 之類的奇怪操作。

這樣你就不用聯(lián)網(wǎng)打開 Figma 網(wǎng)站，使用插件去進(jìn)行這些操作。

Figma 官方的看法

Figma 的 fig 格式算是半公開的，在網(wǎng)上找找能找到不少蛛絲馬跡。因?yàn)?Figma 還是比較開放的，使用的 Kiwi 編碼格式也公開了。

但 Figma 不會主動(dòng)提供在客戶端轉(zhuǎn)換 fig 的方式（但可以使用開發(fā)者 API 請求服務(wù)端數(shù)據(jù)），因?yàn)檫@ 和它所希望的生態(tài)穩(wěn)定相悖。

如果 Figma 主動(dòng)提供 fig 的內(nèi)部格式出來，那它就要對這個(gè)格式負(fù)責(zé)，且 Figma 在開發(fā)新的功能時(shí)，fig 文件在未來發(fā)展中結(jié)構(gòu)大概率會有破壞性改變的。

當(dāng)然如果你想和 Photopea 一樣，嘗試去解析它轉(zhuǎn)換成的結(jié)構(gòu)，那也是可以的，但你自己要對這個(gè)數(shù)據(jù)結(jié)構(gòu)負(fù)責(zé)。