匯出的 FDX 回不來的是什麼

一份從 SlateX 寫出的 FDX 再回到 App，並不等於把原專案原樣裝回來。檔案層級會寫專案名稱，場景層級圍繞場號、內外景、場景名、日夜、八分位、修訂色、省略標記、頁碼與劇本項這些內容交換；不在這組寫出範圍裡的 App 資料，不能靠這份檔案帶回來。更重要的是，即使屬於寫出範圍，部分值在「匯出再匯入」之後也會發生可由兩側程式碼直接推導出的改寫。

FDX 能帶回來的上限先由寫出範圍決定；在範圍內的值，也不等於會逐字回到原樣。

寫出去的範圍就是回得來的上限

檔案層級與場景層級合起來看，寫出端保留專案名稱，以及場號、內外景、場景名、日夜、八分位、修訂色、省略標記、頁碼和劇本項這一組資訊。鏡頭、條記錄、機位、時碼、媒體路徑等等不在這份 FDX 的寫出結構裡，因此不能從這份檔案恢復這些現場記錄。

這也是《FDX 適合交換什麼，又會丟掉什麼》與本篇的分工。父篇說明交換範圍，本篇只看同一份劇本交換檔案出去再回來時，範圍內的內容會怎樣變化，以及哪些內容根本沒有回程載體。

三處內容會在往返之後被確定性地改寫

一類是場頭疊加。由 FDX 匯入過的場，場景名裡保留的是整串原標題，同時內外景和日夜又各存了一份；再次匯出時，寫出端會用「內外景前綴 + 整串原標題 + 分隔符 + 原日夜」重新拼場頭，於是標題與日夜會疊一遍。在 App 內手動新建的場在這一點上不同，因為這三個部分原本就是分開存的，不會出現同樣的疊加來源。

另一類是句點重複。解析端會把類似 INT. 的前綴連句點一起保留，寫出端又會在內外景之後補一個句點，所以往返一次可能出現雙點。這裡說的是兩側規則拼在一起的結果，不是對第三方軟體行為的推斷。

還有摘要頂替。匯入時，備註、摘要類內容可能進入場次摘要，而當沒有這類待寫摘要時，開頭那條動作或普通段落也可能被拿來當作摘要，因此摘要裡裝的可能是動作描寫全文，不是劇情梗概。寫出端又不把場次摘要寫回對應屬性，所以重新匯入時，這個位置可能再次由開頭動作或普通段落頂替。

還有三種回程變化需要分開看

場次八分位為 0 時，寫出端不寫長度屬性；回讀時沒有長度會按 1/8 頁處理，因此「0 或空白」會變成 1/8 頁。重新匯入的場次狀態會按「未拍攝」寫入，不能靠 FDX 恢復原來的拍攝狀態。備註或摘要類段落不會作為劇本項按原本位置回歸，劇本項順序也會重新編號。

這些變化不是在說檔案損壞，而是在說「這個格式寫了什麼」和「回讀時怎樣建立物件」不是同一件事。《交付檔案裡的空值有四種樣子》可以幫忙區分空字串、缺屬性和佔位等形態，但這裡仍只討論 FDX 往返本身。

硬邊界：程式碼可推導，不等於第三方往返已驗收

場頭疊加、雙點和摘要頂替，都是寫出端與回讀端規則拼起來能直接推出的結果。我方尚未用真實的第三方劇本軟體完整走過「開啟、另存新檔、再匯入」這一圈，所以這裡能確定的只有一句：往返不保證逐字保真。

這條邊界同時限制了外推範圍。不能把這裡確定性的程式碼行為寫成「某個第三方軟體一定會怎樣」，也不能把沒有走過的真實往返寫成已經驗收；接收方應自行核對實際的交換檔案，以及回讀後的場頭、長度、摘要與狀態。

往返不保證逐字保真；程式碼能證明改寫路徑存在，但真實第三方軟體的開啟、另存新檔、再匯入仍需逐件核對。

FAQ

FDX 能把鏡頭和條記錄一起帶回來嗎？

不能從目前的寫出結構裡得到這些現場物件。它們不在這份 FDX 的交換範圍內，重新匯入也不會憑空重建。

為什麼場頭可能多出一層前綴和日夜？

匯入過的場同時保留整串原標題、內外景和日夜，再次匯出時又把三者拼在一起。手動新建的場在這一點上表現不同，因為三個部分原本分開儲存。

摘要為什麼可能變成動作描寫？

當沒有待寫的備註或摘要時，開頭那條動作或普通段落可能被當成摘要，而摘要也沒有對應的寫回路徑。重新匯入時，這個位置因此可能被動作描寫全文頂替。

這些結論代表第三方劇本軟體已經走通往返嗎？

不代表。我方尚未完成真實第三方軟體的完整往返驗證，因此接收方應自行核對實際檔案，公開邊界仍是「往返不保證逐字保真」。

Axiom One LLC — SlateX。以上數字截至 2026-09-24。