简介内置103976个英文单词的中英翻译词库配套SQL、CSV、Excel三种主流格式适配不同使用场景。对开发者而言可在应用、网站或学习软件中快速集成单词查询与词义匹配功能对英语学习者而言可用作批量背诵、词频统计与翻译练习的数据底库。库表结构包含英文单词、中文翻译、词性及多种词义执行SQL语句即可自动生成完整数据表支持SQL Server、MySQL等主流数据库也可通过phpMyAdmin直接导入极大降低了部署门槛。资源共8个文件压缩包仅4.63MB以sql建表脚本、csv数据文件、png预览图与md说明文档为主sql文件负责一键建表csv文件既可用Excel打开编辑也可作为通用数据格式导入其他系统png截图便于快速确认表结构与数据样式。目前已有1612人学习下载作者还配套提供README说明方便使用者理解字段含义、导入流程与文件关系整体轻量实用适合需要现成中英词库做二次开发或语言数据处理的人群。1. 十万级英文单词翻译库离线词典数据的三种格式与正确落地顺序做本地词典或者背单词工具最尴尬的时刻不是没有数据而是词库里明明躺着十几万条英文单词和中文翻译你却不知道哪一列是音标、哪一列是释义更不敢直接把它接进项目。手头这份 103976 个英文单词翻译库把常用离线英翻中词条按三种格式各给了一份SQL 版直接进 MySQL 或 SQLiteCSV 版给脚本做批处理Excel 版留给人工查阅、筛选和导出。它解决的是三个实际痛点批量获取单词翻译不依赖在线接口、十万级数据支持本地秒查、同一份数据在不同工具链里都能落地。适合正在做背单词 App、文本预处理、术语库校对以及 NLP 数据清洗的开发者。下面按“看结构 → 导数据 → 查词 → 避坑 → 进阶”的顺序讲透。2. 先看清数据家底字段结构、版本差异与数据完整性核对拿到任何词库类资源第一件事都不是建表而是看清楚文件头部的字段。这类词典库最常见的是“id 单词 音标 词性 中文释义”五列结构有些版本还会在末尾带一列词频或者词源标记但核心信息基本不变。CSV 和 Excel 的第一行大概率是表头SQL 文件里则对应着建表语句的字段清单。我建议你把word、phonetic、pos、translation这四列当作基准列后续所有操作都围绕它们展开。2.1 词条结构与五列字段拿到文件后先看前面五行确认字段顺序。不同分发版本的列顺序可能不同有的是id, word, phonetic, pos, translation有的是word, translation, pos, phonetic混排这会直接影响后面导入语句的列映射。字段名常见类型说明idint内部序号不代表词频或优先级wordvarchar英文原词可能含大小写混写phoneticvarchar音标可能为空值posvarchar词性标记如 n. / v. / adj.也可能是组合写法translationtext中文释义多义项之间通常用分号或逗号分隔这里有三件事要特别注意。第一音标字段不是每行都有空值不能当成脏数据处理。第二translation 字段内部可能自带逗号甚至分号这就是为什么 CSV 必须用引号把字段包起来后面用 Excel 直接打开也容易在这一列上翻车。第三同一个英文单词很可能出现多行比如run既是动词又是名词部分导出工具会把不同词性拆成独立行这意味着 word 列天然存在重复。2.2 三个版本怎么选同一份词库导出成三种格式不是重复劳动而是三种完全不同的消费方式。SQL 版的前提是你本地已经有数据库服务适合做联表查询、按条件批量抽取、给后端接口提供持久化数据源CSV 版是最干净的纯文本格式适合 Python、Java、Shell 脚本做批处理管道也是各数据库之间搬数据的中转格式Excel 版则明显是给人工操作准备的筛选、排序、肉眼比对都方便但在程序读取时反而要多绕一层。版本打开方式适合场景使用成本SQL 版MySQL / SQLite 等数据库联表查询、后端接口、业务系统嵌入中需要数据库环境CSV 版任意文本编辑器 / 脚本批处理、导入导出、数据清洗低最通用Excel 版Excel / WPS / 表格软件人工查词、筛选、教学备课极低如果是做工具类小项目我一般直接选 CSV因为它不绑数据库拿到就能用 Python 读。如果是要给一个正式系统做词典模块那就把 SQL 版导进库里让业务查询走索引。Excel 版解决的是那些“只查一次”的场景比如老师想按词性筛出一份动词表。2.3 导入前先跑一遍数据体检不管最终走哪条路落地之前先做快速体检。打开终端对 CSV 文件执行三行命令wc -l en_words.csv head -n 25 en_words.csv file en_words.csv第一行统计总行数顺便和标题里的 103976 对一下如果差一行不用慌很可能是表头如果差很多就要检查文件是否被截断。第二行看前 25 行确认表头字段和隔几行就会出现一次的空行或异常行。第三行查看文件编码正常情况下应该是UTF-8如果显示ISO-8859或者ASCII后面的中文导入基本都会出乱码。如果还想粗略看下 word 列的去重数量可以用下面的命令做一个体感判断awk -F, NR1 {c[$1]} END{print length(c)} en_words.csv注意这行命令只适合字段里没有逗号的文件如果 translation 里有逗号awk按逗号切分就会把释义切碎数字偏大是正常的。真正严格地去重统计建议放到后面用 Python 做这里只当一个体感参考。3. SQL 版落地建表、导入与三类高频查询SQL 版本地落地有一个天然优势导入之后可以直接用标准 SQL 做条件过滤、聚合和联表不用自己维护一套查询逻辑。但前提是建表这一步走对否则导入时就会出现乱码、字段截断、重复键报错这些教科书里不会写的问题。3.1 字符集与表结构utf8mb4 是一劳永逸的选择字符集选utf8mb4不要选utf8或者latin1。中文释义、音标里的特殊符号、某些编辑器插入的不可见字符只有utf8mb4能完整兜住。如果用utf8部分音标扩展字符在 INSERT 时可能直接报Incorrect string value我当初第一次导入就因为这个原因中途翻车。CREATE DATABASE IF NOT EXISTS dict_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE dict_db; CREATE TABLE IF NOT EXISTS en_words ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 内部序号, word VARCHAR(96) NOT NULL COMMENT 英文原文, phonetic VARCHAR(255) DEFAULT NULL COMMENT 音标, pos VARCHAR(64) DEFAULT NULL COMMENT 词性, translation TEXT COMMENT 中文释义, PRIMARY KEY (id), KEY idx_word_prefix (word(32)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;word 列用VARCHAR(96)而不是常见的 64是因为十万级词库里偶尔会混进带标注或带空格的复合词短字段会截断导致导入失败。音标列给了 255 的余量实际用不满但音标里带重音符号和上下标字符时不会因为长度报错。索引这里特意没有建UNIQUE KEY原因前面说过同一个单词可能有多个词性行。前缀索引word(32)足够覆盖绝大多数查询需求而且索引体积比整列索引小得多。3.2 两种导入方式source 与 LOAD DATA INFILE拿到 SQL 文件后先打开文件头几十行判断它的形态。如果文件里自带CREATE TABLE和INSERT INTO直接走命令行导入mysql --default-character-setutf8mb4 -u root -p dict_db en_words.sql如果你的使用习惯是在 MySQL 客户端内部操作也可以执行source /path/to/en_words.sql;注意路径要写绝对路径。命令行方式比在图形化工具里粘贴大 SQL 稳得多十万行数据粘贴进工具很容易触发超时。如果 SQL 版文件里只有建表语句数据是单独给的 CSV那就用LOAD DATA走文件导入LOAD DATA LOCAL INFILE /path/en_words.csv INTO TABLE en_words CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 LINES (id, word, phonetic, pos, translation);LOCAL表示文件在客户端机器上需要数据库服务开启local_infile参数OPTIONALLY ENCLOSED BY 是这一条语句里最关键的参数专门处理 translation 里带逗号的情况IGNORE 1 LINES跳过表头。末尾括号里的列列表顺序必须和文件里的实际列顺序一致如果文件只有四列这里就写四个字段名。3.3 查询三板斧精确翻译、模糊匹配、批量映射导入完成后日常用得最频繁的查询就三类精确查一个词、按前缀模糊找词、按一批词批量取翻译。对应 SQL 写成下面这样SELECT word, phonetic, pos, translation FROM en_words WHERE word apple;精确查询走的是前缀索引十万行数据做等值匹配响应时间基本在毫秒级足够支撑本地接口。SELECT word, translation FROM en_words WHERE word LIKE app% ORDER BY CHAR_LENGTH(word) ASC LIMIT 20;前缀 LIKE 也能吃上索引适合做输入框自动补全。注意LIKE %app%这种前后都带百分号的写法会让索引失效要做中间模糊匹配的话十万行全表扫描也能扛住但建议配合缓存使用。SELECT word, translation FROM en_words WHERE word IN (apple, banana, run);批量映射这条适合拿英语句子里的单词列表去查词IN列表里的元素不要一次性放太多建议每批控制在几百个以内。如果是同一个单词多个词性行想把释义合并到一行展示可以这样SELECT word, GROUP_CONCAT(translation SEPARATOR / ) AS all_trans FROM en_words GROUP BY word LIMIT 20;GROUP_CONCAT默认分隔符是逗号这里改成 / 展示起来更干净。注意这个查询会全表扫十万行数据也就几百毫秒可以接受但不要频繁放到热路径上。4. CSV 与 Excel 的日常用法不写代码与写代码的两张牌SQL 版适合正式系统但很多临时任务根本不需要启动数据库。一个单词一个单词地查打开 Excel 反而最快批量翻译几百个词写几行 Python 读 CSV 更省事。这一章按两条线讲人工操作和脚本操作。4.1 Excel 版筛选、排序与 VLOOKUP 查词台Excel 版拿到后先确认一件事第一行是表头还是直接从词条开始。很多词典导出文件自带筛选按钮和冻结首行没带也别急自己加一遍。想筛出所有动词选中词性列点击“数据 → 筛选”在下拉菜单里搜索v.即可。注意词性标记可能混着vt.、vi.、v.三种写法只筛v.可能会漏掉一部分建议用“包含”条件而不是“等于”。想从单词查中文用 VLOOKUP 搭建一个简易查词台。假设词库放在词典数据sheet 的 A 到 E 列当前 sheet 的 D 列放待查单词E 列写公式VLOOKUP(D2, 词典数据!$A:$E, 5, FALSE)参数含义D2是你要查的单词词典数据!$A:$E锁定了词库的查找范围5表示返回该范围第 5 列也就是 translationFALSE强制精确匹配。VLOOKUP 有一个绕不开的破绽如果同一个单词在词库里有多行多词性它只会返回第一行。想要把多个释义合并展示得用TEXTJOIN配合筛选或者干脆把数据拖到 Power Query 里按单词分组聚合。批量查询时把待查单词列填满公式下拉然后筛选一下#N/A行这些就是词库里没收录的词。这个动作在背单词 App 的校对阶段特别有用。4.2 CSV 版用 Python 把词库变成翻译字典CSV 版是脚本批处理的主力。我一般先把 CSV 读进字典结构后续所有单词映射都在内存里完成不反复读写文件。import csv def load_dict(path, encodingutf-8, word_col1, trans_col4): w2t {} with open(path, newline, encodingencoding) as f: reader csv.reader(f) header next(reader, None) for row in reader: if not row or not row[word_col].strip(): continue word row[word_col].strip().lower() trans row[trans_col].strip() if len(row) trans_col else w2t[word] trans return w2t if __name__ __main__: d load_dict(en_words.csv) for w in [apple, banana, cherry, notaword]: print(w, , d.get(w, 未收录))word_col和trans_col默认按第 2 列和第 5 列取如果实际文件列顺序不一样改这两个参数即可。lower()统一转小写避免Apple和apple在字典里分成两个 key。十万行数据加载进内存大概需要几百 MB 级的内存占用普通机器没问题但如果同时开很多大程序注意一下内存峰值。基于这个字典可以顺手做一个句子级单词映射把句子里的英文单词替换成中文import re text I run every morning with an apple. print(re.sub(r[A-Za-z], lambda m: d.get(m.group(0).lower(), m.group(0)), text))正则[A-Za-z]按单词切分并顺手处理了dont这种带撇号的形式lambda里查不到就保留原单词。这是最粗糙的“单词级翻译”不适合直接当机器翻译用但用来做文本预处理、日志关键词提取够用且可控。5. 避坑清单编码、重复词条、导入中断与字段错位的 5 个真实踩坑词库类数据看着简单真正跑起来翻车点比功能代码还多。下面几条都是我在不同项目里实际踩过的每条按“现象 → 原因 → 解决”写清楚。5.1 中文释义全变问号现象SQL 导入成功但SELECT查出来所有中文都是???音标里的特殊符号直接消失。原因建表或连接时的字符集不是utf8mb4。最常见的是 MySQL 服务端默认字符集是latin1客户端连接时又没指定字符集数据在写入前就被转码破坏了。另一种情况是数据库是老库表结构建的时候用了utf8某些音标扩展字符存不进去。解决建库建表统一用utf8mb4命令行导入时加--default-character-setutf8mb4。如果数据已经损坏先ALTER TABLE en_words CONVERT TO CHARACTER SET utf8mb4;再重新导入一次。已经变成问号的字段不会自动恢复必须清空表后重导。5.2 CSV 被 Excel 直接打开后列错位现象双击 CSV 文件Excel 打开后音标列和释义列挤在一起中文释义横跨多列根本没法看。原因CSV 是 UTF-8 编码且不带 BOMExcel 在 Windows 环境下默认用 GBK 解码中文字符全乱同时释义字段内部的引号没被 Excel 正确识别。另一个小原因是字段分隔符不统一有些文件用逗号有些用制表符。解决不要双击打开 CSV。在 Excel 里用“数据 → 自文本/CSV”导入导入时手动选择编码为 UTF-8分隔符选逗号。如果一定要让文件“双击就能正确打开”先用编辑器把文件转成带 BOM 的 UTF-8。VSCode 里右下角点击编码选择“通过编码保存 → UTF-8 with BOM”这是最常用的后悔药。5.3 word 列建了 UNIQUE KEY 导致导入中断现象导入执行到一半报ERROR 1062: Duplicate entry run for key en_words.word然后整批导入回滚。再跑一次依然卡在同一个词。原因word 列天然不唯一。同一个单词有名词、动词、形容词等多个词性行把 word 设成唯一索引就等于强行要求数据里没有重词但十万级词典几乎不可能做到。解决建普通索引而不是唯一索引。如果业务上必须唯一则要提前统计重复情况SELECT word, COUNT(*) c FROM en_words GROUP BY word HAVING c 1 LIMIT 5;先看重复的程度再决定是用word pos做联合唯一还是导入前按业务规则去重。不要跳过统计直接拍脑袋设计索引。5.4 SQL 版导入超时或半途中断现象在图形化数据库工具里粘贴整个 SQL 文件跑了十几秒后工具报连接超时或者 INSERT 只执行了一部分表里只有几万条数据。原因十万级数据的 SQL 文件一次性粘贴客户端和服务端之间的包缓冲被撑爆加上图形工具默认有执行超时限制。部分 SQL 文件还可能是每条 INSERT 一行十万行 INSERT 逐条执行本身就慢。解决优先用命令行mysql dict_db en_words.sql导入不走图形工具。如果网络环境差用sed -n 10001,20000p en_words.sql分段执行。注意分段前先看文件内容别把建表语句截到第二段里。中途失败就DROP TABLE清掉半成品从头再来不要指望在残留数据上续跑。5.5 行数对不上103976 和实际导入数字不一致现象wc -l数出来是 103977但COUNT(*)只能查到 103500差了快 500 行。或者反过来计数少但导入多了。原因文件第一行是表头wc -l多算了一行translation 字段内部如果换行一行词条会被拆成多行wc -l数字偏大SQL 文件里如果带了注释行导入时注释被忽略行数自然对不上。解决数据体检阶段先head看文件结构和空行情况。最终以数据库里的COUNT(*)为准不要强迫自己把外部行数对齐到宣传数字。如果非要一个独立的第三方校验用 Python 读 CSV 统计有效行手动排除表头和完全空白的行得到的数字会比wc -l可信得多。6. 进阶动作把十万词库压成本地查词服务的关键两步数据库不是唯一归宿。很多轻量工具只需要查一个词为它启动 MySQL 太重了。我的习惯是把 CSV 直接转成 SQLite让数据文件跟着项目走交付和备份都简单。import sqlite3, csv conn sqlite3.connect(en_words.db) c conn.cursor() c.execute(DROP TABLE IF EXISTS en_words) c.execute( CREATE TABLE en_words ( id INTEGER PRIMARY KEY, word TEXT NOT NULL, phonetic TEXT, pos TEXT, translation TEXT ) ) with open(en_words.csv, encodingutf-8) as f: reader csv.reader(f) next(reader, None) for row in reader: if len(row) 5: c.execute( INSERT INTO en_words(word, phonetic, pos, translation) VALUES(?,?,?,?), (row[1], row[2], row[3], row[4]) ) conn.commit() conn.close()十万行逐条 INSERT 大概十几秒转换一次以后就不再依赖 CSV。SQLite 文件单文件交付查询逻辑和 Python 标准库直接兼容没有任何外部依赖。这个动作之后理论上可以给命令行工具、本地 Web 服务甚至移动端内置词典共用同一个数据源。数据落库之后别急着接进项目先做一次抽样校准import sqlite3 conn sqlite3.connect(en_words.db) rows conn.execute( SELECT word, translation FROM en_words ORDER BY RANDOM() LIMIT 50 ).fetchall() for w, t in rows: print(f{w}: {t}) conn.close()把打印出来的 50 条逐一和在线词典人工对照如果释义偏差率超过 10%说明这个库只能做辅助参考不适合直接面向用户如果偏差率在 5% 以内说明这份离线数据质量足够进测试环境。从那以后我每次拿到任何词库资源都强制先走一遍字段核对、导入抽测和行数对账三步再决定要不要接进正式项目。十万级的离线词库用得好了很多本地功能根本不需要在线接口。希望帮到你。本文还有配套的精品资源点击获取