匯出的 FDX 回不來的是什麼

一份從 SlateX 寫出的 FDX 再回到 App，並不等於把原專案原樣裝回來。檔案層級會寫專案名稱，場景層級圍繞場號、內外景、場景名、日夜、八分位、修訂色、省略標記、頁碼與劇本項這些內容交換；不在這組寫出範圍裡的 App 資料，不能靠這份檔案帶回來。更重要的是，即使屬於寫出範圍，部分值在檔案匯出再讀回時，仍會按固定行為被改寫。

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

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

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

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

往返時需要區分的三類場頭與摘要行為

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

另一類是句點。匯入時會把類似 INT. 的前綴原樣保留，匯出時只在末尾沒有句點時才補一個，所以往返不會多出 INT.. 那種雙點；會重複的是場頭裡的標題與日夜資訊。這裡說的是兩側規則拼在一起的結果，不是對第三方軟體行為的推斷。

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

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

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

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

硬邊界：這些行為可以描述，仍有四項要落到實際檔案

場頭疊加、摘要頂替、八分位為 0 時省略長度並在回讀時補成 1/8 頁、重新匯入後狀態寫為「未拍攝」，以及備註／摘要類段落不按原劇本項位置回歸、劇本項順序重新編號，都是本 App 寫出一份再讀回時可以觀察到的行為。本篇仍不能越界的只有以下四項：

某份真實 FDX 還會丟掉哪些欄位。 匯入只按上述五項屬性取值；要列出某份檔案實際還丟了什麼，必須逐項對照那份檔案。

去重實際過濾掉哪些場。 具體被過濾的場次集合取決於輸入檔案，需核對來源檔案與匯入結果。

第三方劇本軟體的實際互通結果。 本篇不承諾無損往返；第三方軟體開啟、另存新檔、再匯入的結果，應以你用那份檔案走一遍的實際結果為準。

這些固定改寫在某次往返裡的實際幅度。 這些改寫確實會發生；某份檔案的標題、摘要或長度具體改變了多少，仍需比較實際匯出檔案與回讀結果。

因此，對外邊界是：往返不保證逐字保真。不能把已經確定的行為擴大成為「每份檔案都發生同樣程度的變化」，也不能把第三方軟體的實際結果寫成已經確認；接收方應核對實際交換檔案和回讀後的場頭、長度、摘要與狀態。

往返不保證逐字保真；這些改寫確實會發生，但每份檔案的實際變化仍需逐件核對。

FAQ

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

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

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

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

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

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

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

不代表。本篇沒有替第三方劇本軟體的實際開啟、另存新檔、再匯入結果背書，接收方應核對自己所拿到的那份檔案；公開邊界只到「往返不保證逐字保真」。

Axiom One LLC — SlateX