python123题库资源整理与后端服务实践

简介python123.io平台部分Python题目的答案已整理为压缩包面向正在入门Python或准备后端开发基础练习的学习者内容均为可直接运行的.py脚本。压缩包共32个py文件整体仅14KB轻量易用。资源覆盖整数四则运算、分段函数、阶乘计算、数列求和、成绩转换、三角形面积、鸡兔同笼、百钱买百鸡、一元二次方程等常见题目既有简单累加/累乘的基础写法也包含分支循环、函数定义、格式化输出等核心语法应用适合课后对照复习或考前查漏补缺。已有1246人学习下载题目类型贴近日常教学与作业场景。通过阅读和运行这些代码能快速掌握Python基础语法的实际用法积累常用算法思路为后续接触Flask、Django等后端框架打牢基础。1. 这份 python.zip 到底在整理什么先说清楚它的真实用途“python123.io平台部分题目答案资源整理 后端 - python.zip” 这个标题第一眼容易让人以为是个作弊包但真正做过在线判题平台的人会立刻意识到它其实是一套围绕 python123.io 题库的资源整理工具链抓取题目页、清洗题干与样例、关联参考实现、再做成可被后端服务调用的结构化数据。python123.io 是不少高校 Python 课程的指定练习平台自带自动评测学生卡在某一题时最缺的不是“抄答案”而是“知道这题的边界条件是什么、我的输出为什么和预期差一个空格”。这份资源整理的价值就在这里——把散落在网页里的题目、输入输出样例、判题规则沉淀成本地可检索、可离线运行的数据资产。适合三类人正在刷 python123 题目但反复被评测器判错的初学者、要带实验课或助教工作、需要整理题库数据的开发者以及想把题目资源做成本地自测服务的后端学习者。2. 拿到资源包先别解压把“整理”这件事拆成可复用的工具链2.1 先拆目录骨架文件放哪里决定了你三个月后还能不能用绝大多数人整理题目资源的失败点不在抓取而在目录设计。我见过太多人把几十个 Python 脚本和 JSON 堆在一个文件夹里命名从final_v2.py写到真的不改了.py最后自己都分不清哪个是采集脚本、哪个是清洗脚本。拿到这份资源整理需求时我一般会在动手前先建好这样一个骨架python123-archive/ ├── fetch/ # 采集层请求页面、处理登录态 │ ├── session.py # 会话管理与 Cookie 保持 │ └── downloader.py # 按题目ID批量抓取 ├── parse/ # 解析层HTML → 结构化数据 │ ├── parser.py # BeautifulSoup 解析 │ └── cleaner.py # 清洗题干、样例、答案格式 ├── data/ # 数据层清洗后的 JSON / SQLite │ ├── raw/ # 抓取后的原始 HTML留底 │ ├── json/ # 按题目ID命名的 JSON 文件 │ └── db.sqlite3 # 汇总入库的 SQLite 数据库 ├── server/ # 后端层本地检索与评测服务 │ ├── app.py # Flask 接口 │ └── judge.py # 模拟评测器本地跑分 └── requirements.txt这个结构背后的逻辑是每一层只做一件事。fetch层只负责把页面拿回来parse层只负责把 HTML 变成 JSONserver层只负责被前端调用。这样任何一个环节出了问题你只需要替换对应的模块而不需要重写整套流程。我见过有人把请求、解析、存储写在一个 200 行的脚本里题目量一上来改一个解析规则就要重跑一遍全量抓取纯属给自己挖坑。2.2 用题目 ID 做主键把题目、样例、参考实现绑在同一条记录上整理题目资源的核心是先确定数据的主键。python123.io 的每道题在 URL 和页面里都有一个稳定的题目 ID这个 ID 是关联一切信息的锚点。我在设计 JSON 结构时会强制把题目 ID 作为文件名和记录主键保证一条记录完整包含这些字段{ problem_id: 10204, title: 计算圆面积, difficulty: 简单, description: 输入圆的半径输出圆的面积保留两位小数。, input_desc: 一个浮点数 r, output_desc: 圆的面积 s保留两位小数, samples: [ {input: 1, output: 3.14}, {input: 2, output: 12.57} ], reference_solution: r float(input()); print(f{3.14159*r*r:.2f}), tags: [基础语法, 输入输出], last_updated: 2024-06-15 }这里的逻辑说明problem_id是整个记录的唯一键任何去重、增量更新、前后端关联都以它为基准samples是数组而不是单条字符串因为判题器通常有多个测试点只存一个样例等于没整理reference_solution放参考实现作用是让“整理答案”这件事对应到可运行的代码帮助学习者在本地跑通而不是提供截图式答案。字段设计的原则是宁可多留一个空字段也不要事后发现缺了某个维度再回头抓数据——重抓一次的成本远高于建模时多花十分钟。2.3 环境准备VSCode Python 3 的最小可复现环境动手写脚本之前先把环境固定下来。很多人在资源整理过程中翻车不是因为代码逻辑错而是 Python 版本和依赖库不一致导致的“在我机器上能跑”问题。我本地的配置是 VSCode Python 3.10/3.11 双版本项目里用requirements.txt锁版本# 在项目根目录执行创建虚拟环境并安装依赖 python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install requests beautifulsoup4 lxml flask flask-cors pip freeze requirements.lock参数说明requests是采集层的基础负责维持会话和 Cookiebeautifulsoup4配合lxml解析 HTMLlxml比 Python 自带的html.parser快很多批量抓取时差距明显flask和flask-cors是后面做后端服务时用的一次装齐省得临时补。提示如果你在 Linux 服务器上部署这套工具链安装 lxml 前需要确认系统里有libxml2和libxslt开发包否则会编译报错这是 Python 生态里最常见的环境坑之一。3. 用 Python 采集 python123.io 题目页并洗成 JSON登录态、解析与编码三件事3.1 采集脚本requests 会话与登录态保持python123.io 的题目页面在未登录状态下只能看到题干输入输出描述和判题细节需要登录后才完整。所以采集脚本的第一要务是维持登录态。常见做法是先用浏览器登录一次把 Cookie 导出到本地文件再在脚本里加载避免在代码里硬编码账号密码# fetch/session.py import requests import json class ProblemFetcher: def __init__(self, cookie_filecookies.json): self.session requests.Session() with open(cookie_file, r, encodingutf-8) as f: cookies json.load(f) # 把字典形式的 Cookie 挂到会话上 self.session.cookies.update(cookies) self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 }) def fetch_problem(self, problem_id: str) - str: 按题目ID抓取页面返回 HTML 文本 url fhttps://www.python123.io/student/course/problem/{problem_id} resp self.session.get(url, timeout10) resp.encoding utf-8 if 登录 in resp.text and 用户名 in resp.text: raise RuntimeError(f题目 {problem_id} 返回登录页Cookie 可能已过期) return resp.text逻辑说明requests.Session会自动保存服务端下发的 Cookie配合手动导入的登录 Cookie 使用能覆盖大部分访问场景。resp.encoding utf-8这行很多人会漏掉——如果服务器响应头里没声明 charsetrequests会用默认编码猜测猜错了中文就乱码。判断是否登录失效我用了“检查响应文本里是否包含登录表单关键词”的简单策略虽然粗暴但够用更严谨的做法是检查某个登录后才出现的 DOM 元素。参数说明timeout10是必须设置的不设置的话某个请求卡住会拖垮整个批量任务User-Agent伪装成浏览器可以降低被服务端拒绝的概率但不要伪造得过于激进保持正常的浏览器标识即可。3.2 页面解析用 BeautifulSoup 提取题干、样例与测试点拿到 HTML 之后的解析是整个流程里最依赖“现场情况”的部分。python123.io 的页面结构在不同课程、不同题型下会有差异所以我不会建议你把选择器写死而是先跑一个探测脚本看页面里到底有哪些可提取的块。这里给出一套相对通用的提取逻辑# parse/parser.py from bs4 import BeautifulSoup def parse_problem_page(html: str, problem_id: str) - dict: soup BeautifulSoup(html, lxml) # 题干通常在 markdown 渲染区优先找 .problem-content 和 .markdown content_el soup.select_one(.problem-content) or soup.select_one(.markdown-body) description content_el.get_text(\n, stripTrue) if content_el else # 输入输出样例通常放在 pre 或 code 标签里 samples [] pre_blocks soup.select(pre) for i in range(0, len(pre_blocks) - 1, 2): samples.append({ input: pre_blocks[i].get_text(stripTrue), output: pre_blocks[i 1].get_text(stripTrue) }) title_el soup.select_one(h1) or soup.select_one(.problem-title) return { problem_id: problem_id, title: title_el.get_text(stripTrue) if title_el else , description: description, samples: samples }逻辑说明select_one按 CSS 选择器找第一个匹配元素.problem-content和.markdown-body是两个不同主题下的常见题干容器用or串联做降级匹配。样例提取用了“相邻的 pre 块两两配对”的假设这在很多在线评测题目页里成立但如果页面里只有一个 pre 块比如只有一个输入说明配对逻辑就会错位。参数说明get_text(\n, stripTrue)里的换行分隔符非常关键——题干里的列表、代码块如果不用换行分隔会被压成一大段话后续想按行清洗就无从下手。3.3 清洗规则把“网页上的文字”变成“后端能用的数据”解析出来的数据不能直接用。网页里的题干会带多余空白、全角半角混用、HTML 实体残留而评测答案最敏感的就是空白字符。这是整个资源整理链路里最脏最累的一步也是最值得写脚本的一步# parse/cleaner.py import re def clean_text(text: str) - str: 统一空白字符去掉不可见字符保留换行 # 把全角空格转成半角 text text.replace(\u3000, ) # HTML 实体反转义 text text.replace(nbsp;, ).replace(lt;, ).replace(gt;, ) # 连续空白压缩成单空格但保留换行 lines [re.sub(r[ \t], , line).strip() for line in text.splitlines()] return \n.join(line for line in lines if line) def clean_sample(sample: dict) - dict: 样例清洗统一换行符去首尾空行但保留每个测试点的原始输出格式 return { input: sample[input].strip(\r\n), output: sample[output].strip(\r\n) }清洗逻辑的要点是区分“内容性空白”和“格式性空白”。题干里的连续空格是排版造成的可以压缩但输出样例里的换行和缩进是评测要对比的内容不能动。所以clean_sample只做 strip不做内部压缩。这是踩过坑的人才会有的警惕判题器对比的是字节流答案整理里最贵的错误就是改了样例的空白导致本地自测永远通不过。4. 避坑整理题目答案资源时最常踩的 5 个坑4.1 坑一本地跑通的代码提交到 python123 后判错现象参考实现和样例答案在本地反复验证都正确但提交到 python123 平台却被判 Wrong Answer。原因平台的隐藏测试点比公开样例多而且判题器对输出格式的要求严格到“输出最后一行的尾随空格也算错”。本地验证用的样例覆盖不到边界情况比如输入 0、负数、超大数。解决整理答案时不要把“能过样例”作为完成标准。我在reference_solution里会额外记录“边界情况说明”字段比如“输入为 0 时输出0.00而不是0”。更重要的是写完后自己构造至少 3 组非样例输入做验证。注意本地自测通过只是必要条件不是充分条件整理资源时要把这个认知写进 README 里防止使用者误以为资源包能保证满分。4.2 坑二Cookie 过期导致批量抓回来一整个登录页现象脚本跑了一个小时打开数据目录一看几百个 JSON 文件内容全是登录页的 HTML。原因Cookie 有有效期通常是几小时到一天不等批量任务跨时段运行时很容易过期而且某些操作比如频繁请求会触发服务端强制失效。解决在fetch_problem里加登录态检查是兜底但更实际的做法是分批抓取。每抓 50 道题暂停几秒检查最近一个响应是否正常发现登录失效就停下重新导出 Cookie 后从断点继续。断点续传的实现靠文件名抓取前先检查data/raw/{problem_id}.html是否已存在存在就跳过。提示不要硬撑着一口气跑完脚本崩溃不可怕可怕的是没有从断点恢复的能力。4.3 坑三Windows 下 JSON 文件写入乱码现象用open(file.json, w)写入数据文件里中文全变成乱码。原因Windows 下 Python 打开文件默认使用系统本地编码GBKJSON 里包含中文时没指定encodingutf-8就会出问题。解决所有文件读写操作统一显式声明编码with open(fdata/json/{problem_id}.json, w, encodingutf-8) as f: json.dump(record, f, ensure_asciiFalse, indent2, sort_keysTrue)参数说明ensure_asciiFalse的作用是让中文以中文形式写入文件而不是\uXXXX转义序列否则文件可读性极差、diff 时根本看不出改动indent2让 JSON 有结构化的缩进方便用 Git 看变更sort_keysTrue能让同名 JSON 的顺序固定下来避免因为键顺序不同导致 diff 噪音——这一点在做增量更新时尤其重要。我见过太多人因为漏了ensure_asciiFalse整理出来的资源包被使用者嫌弃“全是转义符没法看”。4.4 坑四做题解服务时后缀白名单写死上传功能形同虚设现象我后来把整理好的资源包做成一个本地刷题服务支持上传自己的答案做评测。结果上传.py文件总是失败报错信息不明不白。原因为了安全我把上传后缀白名单写得过于严格只允许.txt把.py排除了更糟的是有些服务端用了黑名单逻辑漏掉了大小写变体和多重后缀的情况。解决改成“白名单 大小写归一化 只取最后一个后缀”的组合策略ALLOWED_SUFFIX {.py, .txt} filename uploaded_filename.lower() if not filename.endswith(tuple(ALLOWED_SUFFIX)): raise ValueError(仅支持 .py 和 .txt 文件)注意不要用黑名单if not filename.endswith(.sh)这种黑名单永远有遗漏也不要用split(.)取后缀然后拼接路径../路径穿越一拼就出事。这个坑在原资源整理脚本里并无影响但一旦你像我一样把它做成后端服务就一定会碰到。4.5 坑五把参考答案放在前端可直连的静态目录里现象用 Flask 的static文件夹存放整理好的 JSON结果浏览器直接访问/static/10204.json就能看到全部题目和参考实现。原因Flask 默认把static/目录下的文件无鉴权暴露出去资源包里的答案数据等于裸奔。解决把数据文件放到 Flask 应用目录之外的data/文件夹只通过接口按需返回并且返回前做权限判断app.route(/api/problems/problem_id) def get_problem(problem_id): # 校验登录态后从 data/json/ 下读取并返回 data load_problem_data(problem_id) # 是否返回参考答案由请求参数控制默认不返回 if request.args.get(with_solution) 1 and not is_teacher(request): abort(403) return jsonify(data)这个坑对“后端 - python.zip”这个方向尤其关键整理出来的答案资源如果没有后端做隔离和过滤分发出去等于没整理——使用者看到的全是未经校验的原始文件既没有权限控制也没有使用指引价值大打折扣。5. 把整理结果做成后端服务Flask 判题接口与 Nginx 转发要点5.1 用 Flask 起一个本地判题服务输入输出对比是最小可用实现资源整理完成后价值最大化的方式是把它变成一个可自测的本地判题服务。用户提交代码后端返回“通过几个用例”。这里不需要复杂的沙箱隔离先把输入输出对比跑通# server/judge.py import subprocess, signal def run_code_with_input(code: str, input_data: str, timeout: int 3) - dict: 在本地子进程里运行用户代码传入 stdin 并捕获 stdout try: proc subprocess.run( [python, -c, code], inputinput_data, capture_outputTrue, textTrue, timeouttimeout, encodingutf-8, errorsreplace ) return {code: proc.returncode, stdout: proc.stdout, stderr: proc.stderr} except subprocess.TimeoutExpired: return {code: -1, stdout: , stderr: 运行超时}逻辑说明subprocess.run是本地评测最简单可靠的方式input参数会把测试输入通过 stdin 传给子进程capture_outputTrue同时捕获 stdout 和 stderr。timeout3防止死循环代码拖死服务进程。参数说明encodingutf-8一定要加否则 Windows 下子进程输出的中文会乱码errorsreplace的作用是遇到非法编码字符时用?替换而不是直接抛异常保证一个思路清奇的代码不会让整个服务崩溃。5.2 评测入口把用户输出和期望输出做归一化对比判题的核心是“怎么算对”。直接字符串相等过于严格python123 平台也会忽略行尾空格和末尾空行。我的对比策略# server/judge.py续 def normalize_output(text: str) - str: 去掉每行尾部空格去掉末尾多余空行统一换行符 lines [line.rstrip() for line in text.splitlines()] return \n.join(lines).strip(\n) def judge(problem: dict, user_code: str) - dict: results [] for idx, sample in enumerate(problem[samples]): run_result run_code_with_input(user_code, sample[input]) if run_result[code] ! 0: results.append({**run_result, passed: False, reason: 运行出错}) continue passed normalize_output(run_result[stdout]) normalize_output(sample[output]) results.append({**run_result, passed: passed}) total len(problem[samples]) passed_count sum(1 for r in results if r[passed]) return {passed: passed_count, total: total, details: results}这里的归一化规则需要仔细斟酌去掉行尾空格和末尾空行是通用规则但如果某个题目的输出样例本身要求输出尾随空格极少见这套规则就会误判。所以归一化逻辑应该做成可配置项而不是写死。经验上先按通用规则跑一遍再针对落败的用例人工检查这比一开始就追求完美匹配更实际。5.3 部署到服务器Nginx 需要关注的三个信息和一个跨域坑如果要把这套服务部署到公网给组员用Nginx 配置是绕不开的。后端部署时 Nginx 通常只需要你知道三件事监听端口、代理目标地址、静态文件目录。把 Flask 跑在127.0.0.1:5000然后让 Nginx 把 80 端口的请求转发过去# /etc/nginx/sites-available/python123-archive server { listen 80; server_name your-domain.com; location /api/ { proxy_pass http://127.0.0.1:5000; # 转发给 Flask proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }参数说明proxy_pass后面的地址必须以http://开头且如果 location 结尾带斜杠Flask 路由里也要对应处理前缀proxy_set_header是给后端传递真实 IP 和域名用的做访问日志和权限控制时依赖这两个头。跨域坑如果你用 Vue3 单独起一个前端页面访问接口浏览器会发起跨域请求。Flask 侧用flask-cors的CORS(app, resources{r/api/*: {origins: http://localhost:5173}})放开开发环境跨域生产环境则让 Nginx 把前端静态页和/api/走同一个域名从根源上避免跨域。前端页面连接后端时BASE_URL 写成相对路径/api不要写死http://localhost:5000否则换个环境部署就得改前端代码。6. 抽检与版本管理让整理好的答案资源长期可用整理完成不等于交付。你需要两套习惯保证资源长期可用抽检机制和版本管理。抽检的方式是随机抽样重新评测。我习惯在每次新增或修改一批题目后写一个简单的校验脚本# 随机抽 20 道题逐个用参考实现跑一遍样例统计通过率 python -m server.verify --sample-size 20 --data-dir data/json验证脚本内部做的事情是遍历 JSON 文件取reference_solution和samples走一遍judge流程然后输出“20 题中 18 题通过、2 题失败”的报告。失败的题多半是清洗样例时把输出格式改坏了或者参考实现本身有质量问题。建立随机抽检习惯之后我会按“修改后必抽检、每周全量跑一次”的节奏维护资源包确保它不会在不知不觉中腐烂。版本管理层面这个大原则值得坚持数据文件和代码文件分仓管理fetch/、parse/、server/进 Gitdata/里的 JSON 可以入库但不要把整个data/目录频繁提交否则每一次全量更新的 diff 会大到没法看。更可控的方式是发布时打 tag比如v1.0-20240615对应某个时间点的完整资源快照增量修改用单独分支管理。这些习惯一开始会觉得麻烦但资源量到几百道题之后没有版本控制的整理就是给自己埋雷。回到这份“python123.io平台部分题目答案资源整理 后端 - python.zip”本身最值得投入的方向不是把答案抄完而是把这套“采集 → 清洗 → 存档 → 服务化”的链路沉淀成自己的工具箱。我自己的血泪经验是第一次整理时图省事把全部题目塞进一个 JSON 文件后面每一次检索和更新都在和那个庞大的文件搏斗后来改成“一题一文件 SQLite 汇总索引”不管是检索还是增量更新都轻松了一个量级。希望这个思路能帮到你少走一段弯路。本文还有配套的精品资源点击获取