简介这份资源是 chinese-poetry 开源诗词数据集的完整本地化压缩包面向从事中文文本处理、数据挖掘与自然语言学习的研究者和开发者。它解决了从 GitHub 直接克隆或下载 zip 速度过慢、难以获取完整数据的问题让需要离线使用诗词语料的人可以快速拿到现成文件。压缩包共 1371 个文件以 1339 个 json 数据文件为主体涵盖唐诗、宋诗、元曲及作者信息等结构化内容另含少量 md 说明、png 配图、yml 配置、py 脚本与 db 数据库文件整体约 84.85MB目录组织清晰便于按朝代或体裁检索。目前已有 1080 人学习下载。对于做诗词检索、文本分类、知识图谱或数据可视化的读者可直接基于这些 json 构建语料库省去爬取与清洗成本同时借助附带的脚本与数据库文件快速搭建本地查询环境是中文古典文学数据处理中较为省心的基础素材。1. 诗词 JSON 库到底能干什么从一次全文检索需求说起前阵子帮朋友做一个诗词主题的静态站点需求很朴素按朝代筛选、按作者聚合、支持全文关键词检索最好还能按体裁绝句、律诗、词牌分类。第一反应是找现成 API但公开接口要么限流、要么字段残缺、要么哪天就没了。折腾一圈后我转向了本地数据方案最后落到了chinese-poetry这个开源项目上——它把从先秦到近代的诗词整理成了结构化的 JSON 文件打包成一个压缩包分发解压即用不依赖任何网络请求。这份资源解决的核心问题就一个把「诗词」这种非结构化文本变成程序能直接查询、过滤、聚合的数据。适合三类人做古文类 App 或小程序的开发者、需要诗词语料做 NLP 实验的学生、以及想离线搭一个诗词检索工具的爱好者。它不提供 UI不提供接口给的就是一堆.json文件怎么用全看你。下面我按「拿到压缩包之后怎么拆、怎么读、怎么查、怎么避坑」的顺序把踩过的坑和能直接抄的代码都摆出来。2. 拆开压缩包目录结构、文件命名与数据规模2.1 先看清压缩包里到底有什么解压后你会看到一个按来源和体裁分层的目录树常见结构大致是这样chinese-poetry/ ├── json/ # 主数据目录 │ ├── poetry/ # 唐诗、宋诗等 │ │ ├── tang/ # 全唐诗 │ │ │ ├── poetryTang0.json │ │ │ ├── poetryTang1.json │ │ │ └── ... │ │ └── song/ # 全宋诗 │ ├── ci/ # 宋词 │ │ ├── ci.song.0.json │ │ └── ... │ ├── shijing/ # 诗经 │ ├── lunyu/ # 论语 │ ├── caocao/ # 曹操集 │ ├── authors/ # 作者信息 │ │ ├── authors.tang.json │ │ └── authors.song.json │ └── ... └── README.md这里有个容易翻车的点不同批次的压缩包子目录命名可能略有差异比如poetry下有的版本用tang、song有的直接平铺。不要硬编码路径先跑一遍目录扫描确认实际结构。我一般会先执行# 列出所有 json 文件确认实际目录层级 find chinese-poetry -name *.json | head -50 # 统计文件总数和总大小 find chinese-poetry -name *.json | wc -l du -sh chinese-poetry逻辑说明find用来摸清文件分布避免后面写死路径导致FileNotFoundError。wc -l给你一个数据规模的直观感受——通常这个项目有上千个 JSON 文件总量在几百 MB 级别。参数上没什么可调的但建议把head -50换成 filelist.txt存下来后面写批处理脚本时直接读这个清单。2.2 单个 JSON 文件的字段长什么样打开任意一个poetryTang0.json你会看到它是一个数组每个元素是一首诗[ { author: 李世民, paragraphs: [ 秦川雄帝宅函谷壮皇居。, 绮殿千寻起离宫百雉馀。 ], title: 帝京篇十首 一, id: 8b7a4f3c-... } ]字段含义很直白author是作者名paragraphs是诗句数组注意是数组不是字符串每句一个元素title是诗题id是唯一标识。词ci的数据结构略有不同通常多一个rhythmic字段表示词牌名。这里第一个坑就来了paragraphs是数组如果你直接拿它做字符串匹配会漏掉跨句的关键词。正确做法是先join再检索后面第 4 章会展开。2.3 用 Python 批量加载并统计拿到数据后第一件事不是急着写查询而是先做一次全量加载和统计确认数据完整、编码正常。我常用的脚本import json import glob from collections import Counter # 按实际路径调整 files glob.glob(chinese-poetry/json/poetry/tang/*.json) author_counter Counter() total_poems 0 for fp in files: with open(fp, r, encodingutf-8) as f: poems json.load(f) # 每个文件是一个数组 total_poems len(poems) for p in poems: author_counter[p[author]] 1 print(f文件数: {len(files)}, 诗总数: {total_poems}) print(高产作者 Top10:, author_counter.most_common(10))逻辑说明glob负责按模式收集文件路径json.load一次性读入整个数组。Counter用来做作者维度的聚合统计。参数上唯一要注意的是encodingutf-8——这个项目的文件全部是 UTF-8如果你在 Windows 上默认用 GBK 打开会直接报UnicodeDecodeError这是新手最常遇到的翻车点之一。跑通这个脚本说明你的环境和数据都没问题可以进入下一步了。3. 把 JSON 读进程序加载策略、内存占用与查询写法3.1 一次性加载还是流式读取数据量摆在那里几百 MB 的 JSON 全量加载进内存对普通开发机来说不是不能承受但要看你怎么用。我的经验是分场景场景推荐策略原因本地脚本、一次性分析全量加载写起来简单查询快Web 服务、常驻进程按需加载 缓存避免启动时内存飙升只做关键词检索预建倒排索引查询从秒级降到毫秒级如果你只是写个脚本跑一次统计全量加载完全没问题。但如果你要搭一个常驻的查询服务建议按朝代或体裁分片加载用到哪个加载哪个。常见做法是用一个字典做缓存import json import os _cache {} def load_poems(dynasty: str): 按朝代加载带缓存 if dynasty in _cache: return _cache[dynasty] path fchinese-poetry/json/poetry/{dynasty} poems [] for fp in os.listdir(path): if fp.endswith(.json): with open(os.path.join(path, fp), r, encodingutf-8) as f: poems.extend(json.load(f)) _cache[dynasty] poems return poems tang_poems load_poems(tang) print(len(tang_poems))逻辑说明_cache字典做进程内缓存同一个朝代第二次调用直接返回不重复读盘。os.listdir遍历目录下所有 JSON 文件并extend合并成一个列表。参数上dynasty传tang、song等目录名即可。注意extend和append的区别——这里每个文件是数组要用extend把元素逐个并入用append会变成嵌套列表后面查询全乱套。3.2 关键词检索的正确写法前面提过paragraphs是数组直接in判断会漏。正确做法是先拼接再匹配同时保留原结构用于展示def search_by_keyword(poems, keyword): results [] for p in poems: full_text .join(p[paragraphs]) # 拼接成完整文本 if keyword in full_text: results.append(p) return results hits search_by_keyword(tang_poems, 明月) for h in hits[:3]: print(h[author], h[title], h[paragraphs][0])逻辑说明.join(p[paragraphs])把诗句数组拼成一个字符串这样跨句的关键词也能命中。keyword就是你要查的词比如「明月」「长安」「秋风」。这个写法简单直接但在全量数据上跑会慢——每次查询都要遍历所有诗并拼接字符串。如果查询频繁建议预先算好full_text存到一个新字段里或者建倒排索引。我一般会在加载阶段就做这一步预处理用空间换时间。3.3 按作者和朝代做聚合查询除了关键词按作者聚合也是高频需求。比如「找出某作者的所有作品」或者「统计各朝代高产作者」from collections import defaultdict def group_by_author(poems): groups defaultdict(list) for p in poems: groups[p[author]].append(p) return groups author_map group_by_author(tang_poems) libai author_map.get(李白, []) print(f李白作品数: {len(libai)}) for poem in libai[:2]: print(poem[title], poem[paragraphs][0])逻辑说明defaultdict(list)省去了判断 key 是否存在的步骤直接append即可。author_map.get(李白, [])用get带默认值避免作者不存在时抛KeyError。参数上没什么特别的但要注意作者名可能有异体字或别名比如「李白」和「李太白」在这个数据集里通常是分开的需要你自己做映射表。4. 避坑与排查编码、路径、内存和字段缺失4.1 现象打开 JSON 报UnicodeDecodeError原因Windows 默认编码是 GBK而数据文件是 UTF-8。解决所有open调用强制加encodingutf-8不要依赖系统默认。如果用的是pandas.read_json也要显式传encodingutf-8。4.2 现象FileNotFoundError找不到文件原因不同批次的压缩包目录结构不一致硬编码路径必然翻车。解决先用find或os.walk扫描实际结构把路径写成配置项而不是写死在代码里。我一般会写一个discover_files(root)函数返回所有 JSON 文件的绝对路径列表后续逻辑只依赖这个列表。4.3 现象全量加载后内存占用过高进程被系统杀掉原因一次性把所有 JSON 读进内存几百 MB 的文件展开成 Python 对象后可能膨胀到几个 GB。解决分片加载 缓存或者改用流式解析ijson库。如果只是做统计可以边读边算不保留原始列表。4.4 现象关键词检索结果为空但明明记得有这句诗原因paragraphs是数组直接对数组做in判断匹配的是元素而不是子串。解决先join再匹配。另外注意标点符号——数据里的标点是全角你搜半角逗号肯定搜不到。4.5 现象作者名对不上统计结果偏差大原因同一作者在不同文件里可能有不同写法或者数据本身存在异体字。解决建一个别名映射表在加载阶段统一规范化。这个没有银弹只能根据实际数据慢慢补。5. 进阶技巧预建索引把查询压到毫秒级前面几章的查询都是线性扫描数据量小的时候无所谓但如果你要做一个交互式检索工具每次查询都遍历几十万首诗体验会很差。我的做法是在加载阶段预建一个倒排索引把每首诗拆成单字或双字词建立「词 → 诗 ID 列表」的映射。查询时先查索引拿到候选集再在候选集里做精确匹配。from collections import defaultdict def build_inverted_index(poems): index defaultdict(set) for i, p in enumerate(poems): text .join(p[paragraphs]) for j in range(len(text) - 1): bigram text[j:j2] # 双字切分 index[bigram].add(i) return index index build_inverted_index(tang_poems) def fast_search(poems, index, keyword): if len(keyword) 2: return [] # 单字查询退化为全扫描 candidates index.get(keyword[:2], set()) results [] for i in candidates: p poems[i] if keyword in .join(p[paragraphs]): results.append(p) return results hits fast_search(tang_poems, index, 明月) print(f命中 {len(hits)} 首)逻辑说明build_inverted_index用双字bigram做切分把每首诗映射到它包含的所有双字词上。fast_search先用关键词前两个字查索引拿到候选集再在候选集里做完整匹配。参数上keyword[:2]取前两字作为索引键所以单字查询无法走索引会退化为全扫描——这是这个方案的边界。索引本身会占额外内存大概和原始文本相当属于典型的空间换时间。实测下来在几十万首诗的规模上线性扫描一次要几秒走索引能压到几十毫秒。这个差距在交互场景里是决定性的。从那以后我每次拿到这类文本数据集第一件事就是先建索引再写查询逻辑而不是等用户抱怨慢了才回头补。希望这套拆包、加载、检索、避坑的流程能帮你少走几个弯路。本文还有配套的精品资源点击获取
