简介：NOI2013数据是2013年全国信息学奥林匹克竞赛的完整赛题资料包，面向备战NOI、IOI及各类算法竞赛的中学生与教练，也适合希望系统训练高级算法与数据结构的学习者。包内共304个文件，以in输入数据、ans标准答案、cpp源码、out输出结果和h头文件为主，另含少量exe、makefile与bak备份，压缩包约18.48MB，覆盖题目描述、样例、测试用例与评分规则等核心内容。目前已有1560人学习下载，可帮助读者还原当年赛题全貌，通过对照标准答案与源码理解动态规划、贪心、图论等解法的实现细节，并借助测试数据反复调试与优化程序，提升算法设计、代码调试与竞赛实战能力。
1. 从一道被反复讨论的题说起：NOI2013数据到底在考什么
如果你在竞赛圈里待过一阵，大概率听过有人提起“NOI2013数据”这个词。它不是一个官方数据集的名字，也不是某个现成的题库压缩包，而是圈内对 NOI2013 那几道题配套测试数据的一种口语化指代。很多人在复现当年题目、搭建本地评测环境、或者想拿这些数据做算法压力测试时，第一反应就是去找这套数据。但真正动手之后才会发现，这套数据的价值远不止“拿来跑一遍”这么简单——它的构造方式、边界覆盖、以及部分题目数据的特殊设计，本身就是一份极好的算法工程教材。
这篇文章面向三类人：一是想拿 NOI2013 题目做本地评测、需要理解数据规格的选手或教练；二是想把竞赛数据当作测试用例、验证自己写的评测机或算法实现是否健壮的开发者；三是单纯好奇“当年那些题的数据到底长什么样”的从业者。我会从数据的基本构成讲起，然后落到怎么在本地把评测环境搭起来、怎么针对不同题型设计校验脚本，最后给出几个我踩过的坑和一套可复用的数据校验流程。整套内容不需要你手头有原始数据文件，重点是理解结构之后，你能自己构造等价测试集，或者拿到任何一份竞赛数据都能快速判断它能不能用。
2. NOI2013数据的构成与题型映射：先搞清楚手里拿的是什么
2.1 从题面到数据文件：一份竞赛数据的标准结构
竞赛数据通常不是单个文件，而是一组按题目和测试点组织的目录树。以 NOI2013 为例，常见做法是每道题一个文件夹，内部再按测试点编号存放输入输出文件，命名规则一般是题目名+编号.in和题目名+编号.out。有些年份还会附带一个config或data.cfg文件，用来描述每个测试点的分值、时间限制、空间限制以及是否开启特殊评测。
我一般拿到一份数据后，第一件事不是急着跑，而是先看目录结构和配置文件。因为配置文件里往往藏着关键信息：比如某个测试点是不是只做答案比对、有没有开 SPJ（Special Judge，特殊评测）、内存限制是不是被单独调过。这些细节直接决定你后面写校验脚本时要不要做浮点误差处理、要不要忽略行末空格。
# 查看数据目录的典型结构 find ./NOI2013_data -maxdepth 2 -type d | sort # 输出示例： # ./NOI2013_data # ./NOI2013_data/day1 # ./NOI2013_data/day1/problem_a # ./NOI2013_data/day1/problem_b # ./NOI2013_data/day2 # ./NOI2013_data/day2/problem_c上面这段命令只是把目录层级列出来，目的是让你先建立空间感。真正要关注的是每个题目文件夹里的文件数量和命名是否连续。如果发现编号跳号，比如从problem_a5.in直接跳到problem_a7.in，那大概率是数据在流传过程中丢了文件，或者原题本来就只有 9 个测试点但编号不连续。这种情况在非官方渠道获取的数据里非常常见，后面做批量评测时会直接导致结果对不上。
2.2 不同题型的测试点设计差异：为什么有的数据“看起来很简单”
NOI2013 的题目类型覆盖了传统算法竞赛的主要门类：有需要复杂数据结构维护的，有考察动态规划优化的，也有偏重计算几何或字符串处理的。不同题型对应的数据设计思路完全不同。比如一道图论题，它的测试点往往会按图的规模分层：小规模随机图、中等规模稠密图、大规模稀疏图、以及专门卡某些错误贪心的特殊构造图。而一道字符串题，数据里可能大量出现周期性重复串、全相同字符、或者极端长度的边界串。
我见过不少人拿到数据后直接跑一遍自己的程序，发现前几个点秒过，就以为稳了，结果后面几个点全部超时或者答案错误。问题就出在没有先分析测试点的分布规律。一个实用的做法是写个脚本统计每个测试点输入文件的大小和行数，快速判断数据规模梯度。
import os def stat_testcases(root_dir): """统计每个测试点输入文件的大小和行数，用于判断数据规模分布""" for dirpath, _, filenames in os.walk(root_dir): for fname in sorted(filenames): if fname.endswith('.in'): fpath = os.path.join(dirpath, fname) size = os.path.getsize(fpath) with open(fpath, 'r', encoding='utf-8', errors='ignore') as f: lines = sum(1 for _ in f) print(f"{fpath}: {size} bytes, {lines} lines") # 调用示例 stat_testcases('./NOI2013_data')这段脚本的逻辑很直白：遍历目录下所有.in文件，输出文件字节数和总行数。参数上唯一需要注意的是编码问题，竞赛数据里偶尔会出现非 UTF-8 字符，所以用errors='ignore'兜底。跑完之后你会得到一张规模分布表，如果发现某个题目前 5 个点都在 1KB 以下，后 5 个点突然跳到几 MB，那说明数据有明显的规模分界，你的程序必须能同时处理小规模精确解和大规模近似或优化解。
2.3 数据校验的第一个动作：确认输入输出配对完整性
在把数据接入任何评测系统之前，必须确认每个.in都有对应的.out，而且编号一致。这一步听起来很基础，但实际流传的数据包里缺文件、文件名大小写不一致、甚至.out内容为空的情况都出现过。我一般会写一个配对检查脚本，把不匹配的项直接列出来。
import os def check_pairing(root_dir): """检查每个 .in 是否有对应的 .out，输出缺失列表""" missing = [] for dirpath, _, filenames in os.walk(root_dir): in_files = {f[:-3] for f in filenames if f.endswith('.in')} out_files = {f[:-4] for f in filenames if f.endswith('.out')} only_in = in_files - out_files only_out = out_files - in_files for name in sorted(only_in): missing.append(f"缺少输出: {os.path.join(dirpath, name)}.out") for name in sorted(only_out): missing.append(f"缺少输入: {os.path.join(dirpath, name)}.in") return missing # 执行并打印 for item in check_pairing('./NOI2013_data'): print(item)这个脚本的核心是集合差运算。in_files和out_files分别收集去掉扩展名后的文件名集合，然后做差。如果输出为空，说明配对完整；如果有输出，那这些测试点就不能直接用，要么补文件，要么从评测配置里剔除。参数上没有什么需要调的，唯一要注意的是有些数据包会把输入输出放在不同子目录，这时候需要先统一目录结构再跑。
3. 在本地把NOI2013数据跑起来：评测环境搭建与批量执行
3.1 最小评测机的选型：为什么我不建议一上来就上重型系统
很多人一想到本地评测，第一反应是去搭一套完整的 Online Judge，比如装个评测机、配数据库、写 Web 界面。但如果你只是想把 NOI2013 数据跑一遍、验证自己的算法实现，这套流程太重了。我一般会先用一个最小化的批量执行脚本，直接对每个测试点调用可执行文件，比对输出，记录时间和内存。等确认数据没问题、算法逻辑也对了，再考虑要不要接入正式评测系统。
最小评测机的核心就三件事：对每个测试点运行程序、限制运行时间和内存、比对输出。在 Linux 环境下，可以用subprocess配合resource模块实现；在 Windows 下则可以用subprocess加超时参数做简化版。下面给一个跨平台可用的 Python 批量评测脚本框架。
import subprocess import time import os import sys def run_one_case(exe_path, in_file, out_file, time_limit=1.0): """运行单个测试点，返回 (状态, 耗时, 实际输出)""" with open(in_file, 'r') as fin: start = time.time() try: proc = subprocess.run( [exe_path], stdin=fin, stdout=subprocess.PIPE, stderr=subprocess.PIPE, timeout=time_limit ) elapsed = time.time() - start actual = proc.stdout.decode('utf-8', errors='ignore').strip() except subprocess.TimeoutExpired: return ('TLE', time_limit, '') with open(out_file, 'r') as fout: expected = fout.read().strip() if actual == expected: return ('AC', elapsed, actual) else: return ('WA', elapsed, actual) def batch_evaluate(exe_path, data_dir, time_limit=1.0): """批量评测一个题目目录下的所有测试点""" results = [] for fname in sorted(os.listdir(data_dir)): if not fname.endswith('.in'): continue base = fname[:-3] in_file = os.path.join(data_dir, fname) out_file = os.path.join(data_dir, base + '.out') if not os.path.exists(out_file): results.append((base, 'MISSING_OUT', 0, '')) continue status, elapsed, _ = run_one_case(exe_path, in_file, out_file, time_limit) results.append((base, status, elapsed, '')) return results # 使用示例 if __name__ == '__main__': exe = sys.argv[1] # 你的可执行文件路径 data = sys.argv[2] # 题目数据目录 for case, status, elapsed, _ in batch_evaluate(exe, data): print(f"{case}: {status} ({elapsed:.3f}s)")这段代码的关键参数是time_limit，单位是秒。NOI2013 的题目原始时间限制一般在 1 到 2 秒之间，但本地机器性能差异很大，我建议先用 2 倍限制跑一遍，看看哪些点接近边界，再决定要不要收紧。另外subprocess.run的timeout参数在 Windows 上也能用，但精度不如 Linux 下的resource模块，做粗略筛选足够了。
3.2 输出比对的细节：行末空格、浮点误差与多解处理
直接字符串相等比对是最简单的方式，但竞赛数据里经常出现一些“看起来一样但比对不过”的情况。最常见的是行末空格和换行符差异。有些题目的标准输出文件在行末带了空格，而你的程序没有输出，或者反过来。这种情况下，严格比对会判 WA，但实际上答案是对的。
处理方式有两种：一是在比对前对每一行做rstrip()，去掉行末空白；二是如果题目明确说明“行末空格不影响结果”，那就统一规范化。但要注意，有些题目恰恰要求输出格式严格一致，比如输出一个矩阵，空格数量有明确规定，这时候就不能随便去空白。
浮点误差是另一个高频问题。如果题目输出浮点数，标准做法是设置一个误差限，比如1e-6，然后逐项比较。下面是一个带容差的比对函数。
def compare_float(actual_str, expected_str, eps=1e-6): """按行比对，支持浮点数容差""" a_lines = actual_str.strip().split('\n') e_lines = expected_str.strip().split('\n') if len(a_lines) != len(e_lines): return False for a_line, e_line in zip(a_lines, e_lines): a_tokens = a_line.split() e_tokens = e_line.split() if len(a_tokens) != len(e_tokens): return False for a_tok, e_tok in zip(a_tokens, e_tokens): try: a_val = float(a_tok) e_val = float(e_tok) if abs(a_val - e_val) > eps: return False except ValueError: if a_tok != e_tok: return False return True这个函数的逻辑是逐行、逐 token 比对。如果 token 能转成浮点数，就用容差比较；否则按字符串严格比较。参数eps默认1e-6，对于大多数竞赛题足够。如果题目要求更高精度，比如1e-9，那就把eps调小，但要注意浮点数本身的表示误差，调太小反而会导致正确解被判错。
3.3 批量执行时的资源控制：别让一个测试点拖垮整台机器
批量跑数据时，最容易翻车的地方是某个测试点因为程序死循环或者内存泄漏，把整台机器的资源吃满。我自己的习惯是在批量脚本里加两层保护：一是每个测试点单独设超时，二是用resource模块限制子进程的内存上限。Linux 下可以这样写。
import resource import subprocess def set_limits(memory_mb=256): """在子进程启动前设置资源限制""" def _limit(): resource.setrlimit(resource.RLIMIT_AS, (memory_mb * 1024 * 1024, memory_mb * 1024 * 1024)) return _limit # 在 subprocess.run 中使用 preexec_fn proc = subprocess.run( ['./your_program'], stdin=open('test.in'), stdout=subprocess.PIPE, timeout=2.0, preexec_fn=set_limits(256) )这里RLIMIT_AS限制的是进程的虚拟内存总量，单位是字节。memory_mb设成 256 表示最多 256MB，超过就会触发内存分配失败，程序通常会异常退出，从而被判定为 MLE 或 RE。需要注意的是，preexec_fn在 Windows 上不可用，所以这套方案只适合 Linux/macOS 环境。如果你在 Windows 下做本地评测，建议直接用 WSL 或者虚拟机跑 Linux，省去很多兼容性麻烦。
4. 避坑与排查：NOI2013数据使用中的五个血泪教训
4.1 坑一：数据文件编码不统一导致读入异常
现象：程序在本地跑某些测试点时，读入的字符串出现乱码，或者直接抛出解码异常，但换一个测试点又正常。
原因：竞赛数据在多年流传过程中，可能被不同操作系统和编辑器处理过，导致部分文件是 GBK 编码，部分是 UTF-8。尤其是包含中文注释或特殊符号的题目，编码问题更常见。
解决：在读入文件时不要假设编码，用errors='ignore'或者显式尝试多种编码。更稳妥的做法是在评测脚本里统一转码，把所有输入输出文件转成 UTF-8 后再跑。我一般会先跑一遍编码检测，把非 UTF-8 的文件列出来单独处理。
4.2 坑二：测试点编号不连续导致批量脚本漏跑
现象：批量评测结果显示 AC 了 8 个点，但你知道这套数据应该有 10 个点，剩下两个点不知道去哪了。
原因：数据包里的文件编号可能不是从 1 到 N 连续排列，比如跳过了 4 和 7，或者用了01、02这种带前导零的命名，而你的脚本按整数排序时把10排在了2前面。
解决：不要假设编号连续，也不要用整数排序。直接用sorted(os.listdir())按文件名字符串排序，然后逐个处理。如果发现编号跳跃，去检查原始题面或配置文件，确认是数据缺失还是本来就这样。
4.3 坑三：时间限制设得太紧，本地机器背锅
现象：同样的代码，在评测机上能 AC，在你本地跑却 TLE。
原因：本地机器的 CPU 性能、编译器优化选项、甚至后台进程都会影响运行时间。NOI2013 的数据是按当年的评测机性能设计的，放到现在的机器上通常更快，但如果你用的是低功耗笔记本或者虚拟机，反而可能更慢。
解决：本地评测时把时间限制放宽到原始限制的 2 到 3 倍，先看算法逻辑对不对，再逐步收紧。如果某个点始终在边界附近，用time命令多跑几次取平均值，排除偶然波动。
4.4 坑四：忽略 SPJ 导致多解题被误判
现象：你的程序输出和标准输出不一样，但你觉得自己的答案也是对的，结果被判 WA。
原因：有些题目存在多解，标准输出只是其中一种。如果数据包里没有附带 SPJ 脚本，而你又用严格比对，那多解题就会被误判。
解决：先看题目描述里有没有“输出任意一组解”之类的说明。如果有，那就需要自己写一个校验器，或者直接跳过这些点的输出比对，只检查解是否满足题目约束。NOI2013 里这类题不多，但遇到了就很头疼。
4.5 坑五：内存限制没设，程序把机器跑崩
现象：跑某个测试点时，机器突然卡死，风扇狂转，最后程序被系统杀掉。
原因：程序里可能有死循环导致内存持续分配，或者算法本身的空间复杂度过高，而你的评测脚本没有设置内存上限。
解决：在 Linux 下用resource.setrlimit限制子进程内存，在 Windows 下用Job Object或者直接依赖超时机制兜底。更重要的是，在跑批量之前先用小规模数据验证程序的内存行为，确认没有泄漏再上大规模数据。
5. 把数据用出更大价值：构造等价测试集与自动化回归
5.1 从“跑一遍”到“造一批”：用生成器扩展测试覆盖
NOI2013 的原始数据虽然经典，但测试点数量有限，而且你无法知道每个点具体卡的是什么错误。如果你想更彻底地验证自己的算法，一个有效做法是写数据生成器，针对每道题的约束条件生成随机测试集，然后用自己的暴力程序或者已知正确解来产生标准输出。这样你就能得到任意数量的测试点，覆盖原始数据可能没覆盖到的边界。
以一道图论题为例，生成器需要控制节点数、边数、连通性、边权范围等参数。下面是一个简单的随机图生成器框架。
import random def gen_graph(n, m, max_weight=100): """生成 n 个节点 m 条边的无向图，边权在 [1, max_weight]""" edges = set() while len(edges) < m: u = random.randint(1, n) v = random.randint(1, n) if u == v: continue if u > v: u, v = v, u edges.add((u, v)) lines = [f"{n} {m}"] for u, v in edges: w = random.randint(1, max_weight) lines.append(f"{u} {v} {w}") return '\n'.join(lines) # 生成一个小规模测试 print(gen_graph(10, 15))这个生成器的参数n和m分别控制节点数和边数，max_weight控制边权上限。你可以通过调整这些参数来生成不同规模、不同密度的图。关键是要保证生成的图满足题目约束，比如不能有自环、不能有重边。生成之后，用暴力程序跑出标准输出，再和你的优化程序比对，就能发现很多原始数据没暴露的问题。
5.2 自动化回归：把每次修改都跑一遍全量测试
当你开始频繁修改算法实现时，手动跑测试会变得很低效。我一般会搭一个简单的回归测试流程：把所有测试点（原始数据加自生成数据）放在一个目录里，每次改完代码就自动编译、批量评测、输出结果摘要。这样能在几秒内知道这次修改有没有引入新的错误。
#!/bin/bash # 自动化回归脚本示例 set -e g++ -O2 -o solution solution.cpp python3 batch_evaluate.py ./solution ./testdata > result.txt grep -c "AC" result.txt grep "WA\|TLE\|RE" result.txt || echo "全部通过"这个脚本的逻辑是：先编译，再跑批量评测，然后统计 AC 数量和异常项。set -e保证编译失败时直接退出，不会继续跑旧的可执行文件。grep -c统计 AC 行数，grep过滤异常状态。如果输出为空，说明没有异常，打印“全部通过”。这套流程虽然简单，但在我反复调参和优化算法时省了大量时间。
5.3 一个具体技巧：用差分比对定位输出差异
当你的程序输出和标准输出不一致时，直接看两个大文件很难找到差异点。我常用的技巧是用diff命令做逐行比对，然后只看前几处差异。
diff <(./solution < test.in) test.out | head -20这条命令把程序输出和标准输出做 diff，head -20只显示前 20 行差异。如果差异很多，通常说明是格式问题或者整体逻辑错误；如果只有零星几处，那可能是边界条件没处理好。配合diff的-w选项可以忽略空白差异，-B可以忽略空行差异，根据题目要求选用。
我自己在复现 NOI2013 数据的过程中，最大的教训是不要假设数据是完美的。流传多年的数据包或多或少都有缺失、编码混乱、编号跳跃的问题，先花半小时做完整性检查和规模分析，比直接跑程序然后对着 WA 发呆要高效得多。另一个习惯是每次修改算法后都跑一遍全量回归，哪怕只改了一行，因为竞赛题的测试点之间往往存在隐藏的关联，你以为只影响一个点，实际上可能把另一个点的边界条件破坏了。希望帮到你。
本文还有配套的精品资源，点击获取
