它会把我的文件还给我吗？

Importing from FET 28 九月 2026 1 分钟阅读

您的 .fet 文件是一份工作学期表，在将其交给任何工具之前，有一个值得问的问题，以及一个两分钟就能得出答案的测试。

.fet 文件看起来并不起眼。不过是几百千字节的 XML 数据，静静地躺在去年文件的文件夹旁边。

但你深知其中倾注了多少心血。八月里那两周，你为了确保科学楼不能同时举办两场实验课而绞尽脑汁。为了达成共识，你与语言系主任进行了三次沟通。你逐一添加了十一条约束条件，每一条都是在经历过一次你绝不想再重演的排课事故后才总结出来的。

这些心血并没有记录在其他任何地方。它们作为约束条件存在于那个文件中，如果文件丢失，你失去的不仅仅是一个文档，而是你所有的排课逻辑。等到九月开学，当课表变得一团糟时，你才会发现问题的严重性。

因此，当一个网页工具声称可以打开该文件时，问题不在于这个工具是否有用，而在于：它能把我的文件原封不动地还给我吗？

为什么答案通常是“不完全能”

大多数读取 .fet 文件的工具都采用了显而易见的方法。开发者研究了文件格式，为他们认为需要的部分编写了代码——比如老师、主题、空间、教学班、常用约束——然后就发布了。

这种方法确实有效，但它会悄无声息地导致失败。FET 的约束条件词汇表非常庞大，并且随着每个版本的发布而不断增长。任何工具作者未实现的功能都不会被读取，当文件被重新导出时，那些从未被读取的内容也就丢失了。文件依然可以打开，依然有效。只是它丢失了你最关心的那三个约束条件，而且没有任何地方会提示你。

这正是最值得防范的失败，因为它在你最需要发现它的时候，却表现得毫无察觉。

FET Explorer 不试图理解每一个约束条件。它尽量不去依赖这种理解。

当读取文件时，每一个约束条件都会按其名称存储，其内容保持原样——无论本应用程序是否知道该约束条件的含义。当你下载时，每一个约束条件都会以相同的名称、相同的内容、相同的顺序被写回。

这里没有所谓的“支持的约束类型列表”，因为根本不需要支持。即使是我们在 FET 发布版本中从未听说过的约束类型，也会被原封不动地保留下来，就像你抄写一段你不认识的文字时，文字本身并不会改变一样。

在我们目前拥有的课表语料库中，这涵盖了 20 种不同类型的 2,987 条约束条件，它们在导出代码中无需任何特殊处理即可实现往返传输。

权重会原样返回。设置为 80% 的约束条件依然是 80%——不会被四舍五入，不会被重新推导，也不会被提升为“开启”状态。非激活状态的约束条件返回时依然是非激活的。你的注释也会原样返回。

有一件事我们会进行干预。

一个 FET 无法打开的 .fet 文件比没有文件更糟糕：你直到最后一步才发现问题，却根本不知道数千条记录中到底是哪一条出了错。因此，文件在交付给你之前会先进行构建和检查。

如果缺少了真正必要的内容——例如一个没有主题的教学班，或者一个指向不在老师列表中的老师的课程——你会收到通知，并明确指出具体的记录。那些可以安全设置默认值的内容会被自动处理，绝不会成为你的困扰。

如果文件有效但看起来内容缺失，你会收到提醒，并看到一个 仍然下载 按钮。那只是建议，而非阻拦。

如果检查本身运行失败，下载将直接进行。如果检查没有得出结论，这不应成为阻碍你获取自己文件的理由。

这是最值得亲自操作的部分，因为它几乎不需要任何成本，而且能一劳永逸地解决这个问题。

它们除了格式（缩进、属性间距、少数可选字段的顺序）之外，不应有任何其他区别。同样的教学班，同样的约束条件，同样的权重，同样的注释。

如果两个文件在实质内容上存在差异，那就是一个 Bug，我们希望了解它。这不应该是你需要绕过的问题，更不应该是你在九月才发现的隐患。

如果你的课表是从电子表格而非 .fet 文件构建的，那么有一个细节值得注意。CSV 行不包含 FET 教学班标识符，而位置约束需要稳定的 ID 才能指向具体的课程。

我们不会拒绝处理，而是在构建文件时分配这些标识符——并将其存储起来，确保它们不会改变。第二次下载会与第一次完全匹配。你可以通过电子表格构建课表，并依然能从另一端获得一个连贯的 .fet 文件。

FET Explorer 不生成课表。它不会优化、重新求解或改进 FET 生成的结果。FET 完成了最困难的部分；而本程序负责读取、展示、共享和编辑结果。

这正是往返一致性如此重要的原因。一个仅仅用来查看课表的工具可以只理解文件的一半内容。但一个你可能会用来进行编辑的工具，必须能把整个文件原样交还给你。