什么?Figma 的 Fig 文件格式居然解析出來了
大家好,我是前端西瓜哥。
上周圖形編輯器交流群里有人問,對于 Figma 導出的 fig 文件,該如何解析其格式,拿到可讀數據。
經過群友的一番討論,這個問題最后算是解決了。
fig 文件
導出 Figma 的設計文件,我們會得到一個 fig 文件。
fig 是一種二進制的格式。
它沒有使用 XML 或是 JSON 的格式,而是選擇使用了 Figma 自己實現的特殊編碼工具進行了序列化編碼,并做了封裝,最后得到一個二進制文件。
二進制相比明文格式(JSON 和 XML),優點有:
- 體積更小,因為數據更緊湊;
- 解析速度快,像是 JSON 這種,要逐個字符解析然后構建 AST,考慮轉義、空格等特殊情況,對于大文件,解析效率很差;
- 高保真,比如一些類型明文格式其實是不好表達的,需要多做一層轉換(比如 Float32Array 類型,要保存為字符串就要轉為普通數組);
- 安全性。因為編碼規則是應用自己實現的,此外方便做加密(比如異或加密)。編碼和解碼的規則我們是無法知道的,除非它主動公布出來,否則只能嘗試去做逆向。
先用 Figma 隨便畫幾個基本圖形。
然后導出 fig 文件,拿到了一個名為 fig-file.fig 的文件。
先用 vscode 打開看看。
不是文本文件,應該就是二進制文件了。
不管怎樣,強行用文本格式打開。
PK 打頭,應該就是 ZIP 格式文件頭的標識。
順便再查看一下這個文件的二進制內容,看到開頭這個 50 4B 03 04,說明確確實實是個 ZIP 文件。
基本上很多應用的導出文件都選擇 ZIP 格式,然后再把后綴名改成自己定義的,比如 fig、xmind。
使用 ZIP 格式有以下好處:
- 進行了文件壓縮,體積更小,并且是單文件;
- 保留了目錄結構;
- 跨平臺,基本所有主流操作系統都支持 ZIP。雖然用戶一般來說并不會手動解壓它,但用戶安裝的應用程序能直接使用操作系統的底層 API 去解壓,有助于減少應用程序包體積;
解壓一下。
unzip fig-file.fig
解壓內容
解壓后的內容為:
.
├── canvas.fig
├── fig-file.fig # 這個是壓縮源文件
├── images
│ └── 0b15125516ae308a2d819f2970e851c0402949d2
├── meta.json
└── thumbnail.png
需要注意的是,解壓出來的內容,并沒有一個根文件夾存放這些內容。
但如果你用可視化界面去解壓,通常會解壓出一個文件夾,這個文件夾和壓縮包同名。
這個其實是操作系統的額外操作,目的是防止解壓出大量文件和當前文件夾的其他文件混在一起了,可能還會有文件同名的問題。
canvas.fig 是真正的 Figma 數據內容,記錄圖形樹中圖形的關系,以及圖形的屬性。
images 文件夾,存放的是圖片,給里面的文件加上 .png 后綴可查看圖片。
meta.json 是一些圖紙的基本信息,比如導出的客戶端使用的背景色,文件名等。
thumbnail.png 是預覽圖圖片,如果你裝了 figma 桌面端,則在會從 fig 提取出這個圖片給文件預覽器預覽。
等下,不對,canvas.fig?怎么又是 fig 文件,這是在玩套娃?
經識別,也是個二進制文件,但它的文件格式卻是。。。fig-kiwi?
Kiwi
這個叫做 Kiwi 的特殊格式被 Figma 的前 CTO,Evan Wallace 開源了。
https://github.com/evanw/kiwi。
Kiwi 是一種基于 Schecha 的二進制格式,用于高效地對樹形數據結構進行編碼。
它受到 Google 的 Protoclol Buffer 格式的啟發,但更簡單,編碼更緊湊,且對自定義字段有更好的支持。
Kiwi 庫提供了工具,能夠解析二進制文件轉換為編程語言中的對象,目前支持 JavaScript (TypeScript)、C++、Rust、Skew。
但要提供一個 Schecha,來進行類型的映射。
好在這個 Schecha 有保存在 fig 文件里的。
canvas.fig 文件
實際上這個 canvas.fig 文件并不是 Kiwi,它是一個復合產物。
首先開頭的 fig-kiwi 字符串是一個注釋,表示它是一個 fig 文件(畢竟前面也看到了,fig 文件可能也是 ZIP),并使用了 kiwi 進行編碼。
文件里有 Kiwi 的二進制數據部分,也有 Schecha 部分,需要把它們提取出來。
這里要做 切片 了。
有個開源項目 Figma-To-JSON 成功解析了 fig,我們看看它怎么做的。
看了下,貌似是切在 50 89 這個地方,切好幾刀,得到一些切片。我們需要前兩個切片。
第一個切片是 Schecha,第二個是 Kiwi 數據。
每個切片都是 ZIP 壓縮的,需要先給它們解壓,然后再做 Kiwi 解碼。
import { ByteBuffer, compileSchema, decodeBinarySchema } from "kiwi-schema"
export const figToJson = (fileBuffer: Buffer | ArrayBuffer): object => {
// 提取 fig 文件的 schema 和 kiwi 格式數據
const [schemaByte, dataByte] = figToBinaryParts(fileBuffer)
const schemaBB = new ByteBuffer(schemaByte)
const schema = decodeBinarySchema(schemaBB)
const dataBB = new ByteBuffer(dataByte)
const schemaHelper = compileSchema(schema)
// 這個 json 對象就是最終結果了
const json = schemaHelper[`decodeMessage`](dataBB)
return convertBlobsToBase64(json)
}
流程總結一下,大致如下:
Figma-To-JSON
上面都是在說解碼 fig 文件的過程。
如果你只是想要得到 fig 的結構,對過程不感興趣,可以直接用一個名為 Figma-To-JSON 的開源項目去解析。
https://github.com/yagudaev/figma-to-json。
下面是轉換結果,是一個一維數組,風格類似 quill 的 delta。
每個節點保存有父節點的 id,可以關聯構建出一棵圖形樹。
拿到 fig 數據格式有什么好處呢?
首先如果你開發自己的圖形編輯器,或者直接就是 Figma 的競品,你是要設計數據結構的,那 fig 數據格式就有很好的參考價值。
然后就是做二次開發,寫一些工具做一些離線的批處理操作,比如提取 fig 的一些文本數據轉換為 excal 之類的奇怪操作。
這樣你就不用聯網打開 Figma 網站,使用插件去進行這些操作。
Figma 官方的看法
Figma 的 fig 格式算是半公開的,在網上找找能找到不少蛛絲馬跡。因為 Figma 還是比較開放的,使用的 Kiwi 編碼格式也公開了。
但 Figma 不會主動提供在客戶端轉換 fig 的方式(但可以使用開發者 API 請求服務端數據),因為這 和它所希望的生態穩定相悖。
如果 Figma 主動提供 fig 的內部格式出來,那它就要對這個格式負責,且 Figma 在開發新的功能時,fig 文件在未來發展中結構大概率會有破壞性改變的。
當然如果你想和 Photopea 一樣,嘗試去解析它轉換成的結構,那也是可以的,但你自己要對這個數據結構負責。