导出的 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 的交换范围内，重新导入也不会凭空重建。

为什么场头可能多出一层前缀和日夜？

导入过的场同时保留整串原标题、内外景和日夜，再导出时又把三者拼到一起。手工新建的场在这一点上表现不同，因为三个部分原本分开保存。

摘要为什么可能变成动作描写？

当没有待写的备注或摘要时，开头那条动作或普通段落可能被当成摘要，而摘要又没有对应的写回路径。重新导入时，这个位置因此可能被动作描写全文顶替。

这些结论代表第三方剧作软件已经走通往返吗？

不代表。本篇没有替第三方剧本软件的实际打开、另存、再导入结果背书，接收方应核对自己拿到的那份文件；公开边界只到“往返不保证逐字保真”。

上海智独教育科技有限公司 — SlateX