为什么同一批条记录在几份交件里行号互不对应

同一批条记录在几份交件里行号互不对应，不是因为它们从不同项目取数，而是因为每种产物按自己的排序规则输出。表格式产物基本保留记录的创建先后，结构化清单重新按场号、镜号、条号排序，可读日报又使用另一套镜头键；三件现在都按机位展开，所以同一趟导出的行数是同一个粒度，对不上的是行序。

跨文件对表时，稳定的共同键是场、镜、条身份，不是“第几行”。

起点相同，后面的排序规则不同

表格式产物基本按记录创建的时间先后排列。结构化清单会重新按场次、镜头编号与条号排序，其中场次和镜头使用自然序比较。于是同一批记录在两种产物里的行位置不再对应。

可读日报还会再走一套排序：场次之后，它使用镜头的限定名作为第二把键，再按条号排列。这个限定名并不等于结构化清单使用的原始镜头编号，因此两份文件即使包含同一批 take，也没有“第二行就应该对第二行”的关系。

界面日志还有另一套顺序。它按镜头号字符串升序，再按条号升序。字符串排序下，10 会排在 2 前面。这是界面自己的显示顺序，也不能拿来反推导出文件中的位置。

行号不对应，核心在于各走一套排序键

三件都按机位展开：一条 take 如果包含多个机位，各生成多行；没有机位时也都保留一行。所以同一趟导出的三份文件，行数其实是同一个粒度——差别在同样这些行被各自的键排成了不同的次序。

这也解释了为什么行号互不对应：CSV 基本按记录创建的先后，ALE 按场号、镜号、条号重排，日报按场号、镜名、条号。日报那一列看起来像序号的 No. 还是整份文档的行号，不是 take 编号，所以更不能把它作为跨文件的对表键。

行号不对应来自各套排序键不同；它不等于某一份文件“多了一条拍摄”或“少了一条拍摄”。

镜头标识在不同产物里也可能不是同一个字符串

可读日报会使用镜头限定名，而表格式产物的镜头列使用原始镜头编号。一个镜头在界面或某份文件中可能带着场次前缀或限定形态，在另一份文件里只保留较短的编号。接收方应把它们放回场、镜、条关系中理解，而不是仅凭某一列字符串全等来判断是否同一条。

这里描述的是产物本身。当前证据不能继续断言某个下游软件会因此如何错配、漏配或拒绝导入。具体接收行为仍应由接收方按自己的导入模板逐列核对。

对表时应该用什么

跨文件核对时先锁定场次，再锁定镜头，再看条号；多机位记录还要继续看机位。这样做的目的，是把身份关系当作共同语言，而不是把某一份文件偶然出现的行位置当成主键。

同一趟导出的三份文件行数现在是同一个粒度，顺序不同就先看它们各用了哪套排序键。跨趟比不成立：只有按拍摄日那一趟才生成日报，整部戏那一趟只有 ALE 与 CSV。只有身份关系本身对不上时，才需要回到源记录检查，而不是先要求几份产物行行对齐。需要按接收方流程判断一份交件能否继续用时，可按《接收方怎样判断一份现场交件可以继续用》的核对顺序另行检查。

这些差异来自各产物的职责不同，但“职责不同”也不等于可以忽略核对。每一份产物承担不同职责，接收方仍需确认自己使用的字段确实能回到同一条现场记录。

FAQ

为什么表格式产物和结构化清单顺序不同？

因为表格式产物保留记录先后，机读清单会按场、镜、条重新排序。两者出自同一批条记录，之后的次序规则不同。

同一趟导出的几份文件，总行数一样吗？

一样。三件都按机位逐台出行，一条多机位 take 在三件里都占同样的多行；不一样的是次序。整部戏那一趟不生成日报，跨那种趟比行数本身不成立。

日报里的 No. 可以拿来和另一份文件的行号对吗？

不应该。日报的 No. 是整份文档的行号，与 take 编号不是同一个概念，不能作为跨文件身份键。

几份文件应该用什么共同键来核对？

优先使用场、镜、条身份，并在多机位记录上继续核对机位；不要把行号或某一份文件的排序位置当成共同键。

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