简介包含103976个英文单词的翻译库面向开发者、英语学习者及需要批量词库数据的运维与教研人员可省去从零整理词条、反复清洗数据的重复劳动。资源同时提供SQL脚本、CSV与Excel三种载体SQL文件支持在phpMyAdmin中直接导入也可在SQL Server、MySQL等主流数据库执行建表CSV与Excel便于筛选、排序和二次编辑方便做进一步加工。压缩包共8个文件含sql、csv、png预览图及md说明文档整体仅4.63MB轻量易分发预览图涵盖总数统计、表结构展示与各文件预览下载前即可核对数据字段和格式。单词表字段涵盖英文单词、中文翻译、词性及多种词义每条记录区分名词、动词、形容词等词性并保留多种释义结构清晰一条导入命令即可生成可用数据表适合直接接入词典查询、背单词应用、词频分析或翻译预处理等项目。目前已有1603人学习下载可快速获得高质量中英词库基础数据。1. 103976 个英文单词翻译库一份能直接塞进业务系统的离线词表103976 个英文单词翻译库不是什么黑科技它是一份把英文单词、音标、中文释义按行整理好的结构化数据同时给了 SQL、CSV、Excel 三种格式。你不需要半夜调在线翻译 API也不用从爬虫日志里拼词表导入后就能在本地做批量查询、背单词、教学词库甚至给 App 提供离线接口。我最早接触这类数据是想给内部工具加一个「选中英文 → 弹中文释义」的功能在线接口一怕限流二怕延迟最后用了 10 万级离线词库效果立竿见影查询毫秒级流量为零。适合谁后端开发、做数据分析的、英文教研的老师、还有自己折腾量化词频的爱好者。前提是你愿意花二十分钟把格式摸透否则 10 万行数据会给你上一课。2. 三种格式怎么选SQL、CSV、Excel 各自的适用边界和表结构设计同样是 103976 行数据放在不同容器里玩法完全不同。不是「哪个格式更好」而是「你打算怎么用它」。先把字段和表结构定下来后续所有步骤都围绕这展开。常见做法是词表包含至少四列单词、音标、中文释义、来源标记。有的版本会带词频、词性、例句但核心三列够用了。拿到手的第一件事不是导入而是打开看前 20 行确认分隔符、是否带表头、有没有 BOM。2.1 SQL 版最适合做服务端查询先看建表语句和索引SQL 版不是指某个特定数据库而是能导入任意关系型数据库的脚本。你在 SQL Server、MySQL、PostgreSQL 里都能建出同样的结构。我的习惯是先建一张干净的业务表-- 词库表id 自增word 唯一音标允许为空中文释义不允许为空 CREATE TABLE dict_en_zh ( id INT IDENTITY(1,1) PRIMARY KEY, word NVARCHAR(255) NOT NULL, phonetic NVARCHAR(255) NULL, meaning NVARCHAR(MAX) NOT NULL, created_at DATETIME2 DEFAULT SYSUTCDATETIME() ); -- 给 word 建唯一索引这也是后续去重和查询的关键 CREATE UNIQUE INDEX uq_dict_word ON dict_en_zh(word);word用 NVARCHAR 而不是 VARCHAR是为了避免 SQL Server 和 UTF-8 中文之间出现字符集转换问题meaning用 NVARCHAR(MAX) 是因为有些翻译很长包含多个义项和例句。phonetic允许 NULL因为不是每个单词都有音标。id自增主键让后续按词频或随机抽样时有个稳定的排序依据。SQL 版的优势是你能直接写 JOIN、子查询、存储过程。比如你有一张用户生词表想查出哪些词在词库里没有一句NOT EXISTS就搞定。劣势是对 SQL 不熟的人容易在导入阶段翻车文件 10 万行直接粘贴到 SSMS 查询窗口会卡死必须走 BULK INSERT 或导入向导。别怕后面第 3 章给你完整步骤。2.2 CSV 版数据交换的事实标准注意编码和字段转义CSV 版是所有格式里最「通用」的因为几乎所有工具都能读写Excel、pandas、SQLite、R、Go、Java 都有现成解析库。我一般把 CSV 当作中间介质从原始文件清洗出一个标准 CSV再转成 SQL 或 Excel。这样出了错CSV 就是后悔药重新跑一遍脚本就行。但 CSV 有个坑它没有强类型。单词是字符串释义里如果包含逗号、引号、换行解析器一不留神就把一列拆成三列。解决方法是要求数据本身用双引号包裹字段并且在解析时设置QUOTE选项。另一个坑是编码。Windows 上的 Excel 默认用 GBK/ANSI 打开 CSV如果文件是 UTF-8中文会全部变成ä¸Â这类乱码。所以你要先确认 CSV 是 UTF-8 带不带 BOMpandas 读取时指定encodingutf-8导入 SQL Server 时指定CODEPAGE65001。2.3 Excel 版适合人工校对但别拿它当数据库用Excel 版适合做三件事人工校对、做 VLOOKUP 批量查词、给不懂 SQL 的同事用。你可以同时打开词库 Excel 和一张生词 Excel用一把 VLOOKUP 把中文释义拉进来。10 万行对 Excel 来说压力不算大熟练的 Excel 用户完全能够驾驭。但别拿 Excel 版当数据库用。103976 行虽然不算海量但如果你在 Excel 里逐个单元格改翻译改完很难追溯多人同时编辑更是不现实。我见过有人把词库放在共享盘里让实习生每天更新「新增单词」最后 10 万行的文件膨胀到几十 MB打开一次要半分钟。正确用法是把 Excel 当作人工修正的输入工具修正完导回 CSV再做一次入库。Excel 内部用 xlsx 格式存储本质是 zip 包版本历史并不友好。三种格式对比下来规律很清楚要跑服务端SQL 版优先要做数据搬运和程序处理CSV 是中间层要给人看不给机器看Excel 最方便。别混用更别把 Excel 当数据库。3. SQL 版落地把 10 万级词库导入 SQL Server 和 MySQL 的完整步骤标题里给了 SQL 版但你电脑上不一定装了数据库。常见做法是直接在 SQL Server 或 MySQL 里建库导入。下面两个流程我都跑过差异主要在语法和编码处理上。提前说结论10 万行属于中小数据量用什么工具都能导进去真正麻烦的是编码、引号和重复数据。3.1 导入前准备先建库表再决定用 BULK INSERT 还是 LOAD DATA不管用哪个数据库第一步永远是把 CSV 弄干净。我的检查顺序是确认表头、确认列数、确认换行符、确认最后的空行。直接用记事本或 VS Code 打开 CSV看前几行word,phonetic,meaning abandon,/əˈbændən/,v. 放弃抛弃 abandoned,/əˈbændənd/,adj. 被抛弃的废弃的如果你发现meaning字段里有一堆逗号比如v. 放弃抛弃, 常用词那 CSV 解析器会把常用词当成下一列的单词。理论上标准的 CSV 应该用双引号包住含逗号的字段但很多词库导出工具不守规矩。此时要做的是预处理把英文逗号替换成中文逗号或者统一给 meaning 加双引号。我一般用 Python 先洗一遍因为 10 万行用 Excel 替换会卡。import pandas as pd df pd.read_csv(raw_en_dict.csv, encodingutf-8, dtypestr) # 把释义里的英文逗号统一替换成中文逗号避免导入时错列 df[meaning] df[meaning].str.replace(,, , regexFalse) df.to_csv(clean_en_dict.csv, indexFalse, encodingutf-8-sig)dtypestr防止自动把数字列变成 floatencodingutf-8-sig带 BOM 导出方便之后直接给 Excel 看。清洗后确认df.shape和 103976 对一下行数再进数据库。3.2 SQL Server 的导入BULK INSERT 与 bcp 的踩坑参数SQL Server 导入大文本最稳的是BULK INSERTSSMS 导入向导也快但向导一到映射界面就让人犯晕。直接上脚本反而可控。假设你已经建好了第 2 章的表-- BULK INSERT 从本地文件导入注意路径和文件权限 BULK INSERT dict_en_zh FROM D:\data\clean_en_dict.csv WITH ( FIELDTERMINATOR ,, ROWTERMINATOR \n, FIRSTROW 2, CODEPAGE 65001, TABLOCK, KEEPIDENTITY );FIELDTERMINATOR指定列分隔符这里用的是逗号如果 CSV 里用双引号包裹字段BULK INSERT本身不能识别引用包裹它会把双引号当成普通字符一起导入。所以前面预处理才要及时。ROWTERMINATOR是行分隔符Windows 上有些文件是\r\n你要看文件实际换行。FIRSTROW 2跳过表头。CODEPAGE 65001对应 UTF-8如果你的 CSV 是 UTF-8这个参数必须加否则中文全变问号。TABLOCK让导入走表级锁能快不少KEEPIDENTITY保留 CSV 里的 id 列如果 CSV 没有 id这个参数就别加。如果你不想动数据库权限可以用bcp命令行工具bcp dict_en_zh in D:\data\clean_en_dict.csv -S localhost -d dictdb -U sa -P password -c -t , -r \n -F 2 -C 65001-c表示字符模式-t指定列分隔符-F 2跳过表头-C 65001同理。bcp 的好处是能写进批处理脚本坏处是密码明文仅限开发环境。导入完成后立即检查SELECT COUNT(*), COUNT(DISTINCT word) FROM dict_en_zh;如果总数和 distinct 数不一致说明有重复单词先看第 5 章。3.3 MySQL 的导入LOAD DATA 和 csv 编码的配合MySQL 的对应命令是LOAD DATA LOCAL INFILE它比 SQL Server 更宽容支持OPTIONALLY ENCLOSED BY 所以带引号的 CSV 可以直接导不需要先把逗号换成全角。-- 先设置客户端编码避免写入时中文变成乱码 SET NAMES utf8mb4; LOAD DATA LOCAL INFILE /home/user/data/clean_en_dict.csv INTO TABLE dict_en_zh CHARACTER SET utf8mb4 FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY LINES TERMINATED BY \n IGNORE 1 ROWS (word, phonetics, meaning);SET NAMES utf8mb4是很多新手忽略的一步少了它数据虽然写进去SELECT 出来却可能是一堆问号。CHARACTER SET utf8mb4告诉 MySQL 文件本身是 UTF-8。FIELDS TERMINATED BY ,指定字段分隔符OPTIONALLY ENCLOSED BY 允许字段被双引号包起来MySQL 会自动去掉引号这是比 SQL Server 舒服的地方。IGNORE 1 ROWS跳过表头。最后的(word, phonetics, meaning)是列映射顺序如果 CSV 第一列是 id要加到列表里。MySQL 导入后同样验证但注意COUNT(DISTINCT word)会受排序规则影响。如果建表时用了utf8mb4_general_ci可能出现Abandon和abandon被当成同一个词的情况。这不算 Bug而是排序规则决定的对大小写和重音敏感度。做精确词库建议用utf8mb4_bin或者utf8mb4_0900_as_cs区分大小写。3.4 查询的正确姿势索引、LIKE 和慢 SQL 优化导入成功只是开始查询慢才是很多人没想到的坑。10 万行全表扫描在 MySQL 里大约几百毫秒看起来不慢但你如果写一个用户生词接口每天被调用几万次几百毫秒就是灾难。词库表必须给word建唯一索引这也是唯一的重点索引。-- MySQL 和 SQL Server 通用按单词精确查询走索引毫秒级 SELECT word, phonetics, meaning FROM dict_en_zh WHERE word abandon;精确查询走唯一索引没问题。但如果需求是模糊搜词比如用户输入abando想补全你会写成WHERE word LIKE abando%这个依然能走索引因为前缀匹配。可如果你写的是WHERE word LIKE %bandon%索引直接失效10 万行全表扫MySQL 一般要几十到一百毫秒SQL Server 也快不了多少再叠加上并发就会变成慢 SQL。我的习惯是模糊搜完整单词用word ?前缀搜索用LIKE 前缀%包含搜索要么不加这个功能要么把词库加载到 Redis 或内存里做。另一个思路是上全文索引但 10 万词的词库没必要为这个引入额外复杂度。4. CSV 版和 Excel 版用 pandas、Power Query 和 VLOOKUP 把词库变成工具数据库导入是给后端用的如果你只是做数据分析或日常查词CSV 版和 Excel 版才是主力。这一章讲两件事怎么用 pandas 高效处理 10 万行 CSV以及怎么在 Excel 里不动代码完成批量查询。4.1 pandas 读取 10 万行 CSV参数怎么设内存和耗时差多少10 万行对 pandas 来说是小数据集read_csv 一瞬间就能读完。但读法不同后面处理省不少事。下列是我在项目里最常用的一组参数import pandas as pd df pd.read_csv( en_dict.csv, encodingutf-8, dtype{word: string, meaning: string}, keep_default_naFalse, na_values[, NULL], ) # 过滤空翻译的脏数据 valid_df df[df[meaning].str.strip() ! ] print(len(df), len(valid_df))encodingutf-8对应文件真实编码如果文件带 BOMpandas 也能识别但最好明确写。dtype{word: string}强制这一列是字符串而不是 object这样后面做字符串方法调用时内存更稳。keep_default_naFalse很关键pandas 默认会把N/A、NULL、空字符串都读成NaN这个词库里可能有单词本身就是null你不想误杀。na_values手动声明哪些值值得当成空值。最后用str.strip()去掉首尾空格再判断避免出现一堆只含空格的「空翻译」。如果你担心内存可以用chunksize分批读但 10 万行完全不需要一次读进来就好。真正让内存膨胀的是把 meaning 里的长文本读到 DataFrame每行几百字符10 万行也就几十 MB属于舒适区。4.2 用 Excel 做批量查词VLOOKUP 与 INDEX/MATCH 的取舍Excel 用户最常见场景有一列生词表希望从词库里把中文释义带回来。如果词库表是 Excel 打开的A 列是 wordC 列是 meaning生词在 D2 单元格VLOOKUP 写法如下VLOOKUP(D2, $A$2:$C$103977, 3, FALSE)D2是要查的单词$A$2:$C$103977是词库区域锁死绝对引用防止下拉时区域漂移3表示要取第 3 列也就是 meaningFALSE表示精确匹配。这里有个致命细节VLOOKUP 遇到查不到的词会返回#N/A很多人直接下拉整个表格列表里出现几百个#N/A看着特别刺眼。可以用IFERROR包一层让没查到默认显示空IFERROR(VLOOKUP(D2, $A$2:$C$103977, 3, FALSE), )VLOOKUP 的硬限制是它要求查找列在区域第一列。如果你的词库表里 word 不在 A 列VLOOKUP 就废了得改用INDEX MATCHINDEX($C$2:$C$103977, MATCH(D2, $A$2:$A$103977, 0))MATCH找到 D2 在 A 列中的位置INDEX从 C 列取同一个位置。这套组合查询效率比 VLOOKUP 略好而且列顺序随便摆。10 万行用精确匹配Excel 算起来也就是一两秒的事完全能接受。4.3 导出 Excel 常见陷阱数字格式、UTF-8 乱码和大文件卡顿如果你用 pandas 把 CSV 转成 Excel最省事的是to_excel但引擎选择有讲究。默认openpyxl对 10 万行写入较慢我一般指定xlsxwriterdf.to_excel(en_dict.xlsx, indexFalse, enginexlsxwriter)xlsxwriter写行快还能顺手设置列宽。如果你处理的文件里包含「单词看起来像数字」的词比如2Excel 打开后可能被识别为数字列前导零丢失、科学计数法乱跳。解决方法是写入前强制变成文本df[word] df[word].astype(str)还有一个很常见的问题Excel 打开 UTF-8 编码的 CSV 直接乱码原因是 Excel for Windows 默认用 ANSI 解码。最简单的方案是导出 CSV 时用utf-8-sig也就是前面提到的带 BOM 的 UTF-8这样双击文件也能正常显示。大文件卡顿的问题主要出在「查词区域」而不是「词库区域」。如果你把整个词库 10 万行都放在一张工作表里然后做几千行 VLOOKUPExcel 会重新计算很久。我的习惯是把词库放在一个 sheet查词在另一个 sheet用完全引用这样手动按 F9 重算不会每次输入都卡。10 万行 Excel 其实还在舒适区真正卡是因为有人把整列公式替换成满列引用。缩小数据区域控制在词库实际行数速度立马上来。5. 这 103976 个词不一定干净五个常见坑和排查方法词库数据看似简单实际使用中我踩过不少坑。这一章写我遇到过的真实故障每条都按「现象、原因、解决」来讲。你如果能把这几条提前排雷能省下一整个下午。5.1 重复词条SELECT 出来的行数比 103976 多现象SELECT COUNT(*) FROM dict_en_zh返回 104121比 103976 多了 145 行COUNT(DISTINCT word)却是 103976。原因源 CSV 里存在重复单词词形变化或同形异义会造成同一行出现多次。有些词库为了保留不同词性把同一个单词写了多行但如果你只需要一个翻译这就是重复。解决先确认是否要去重。如果想去重按 word 保留每个词第一行WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY word ORDER BY id) AS rn FROM dict_en_zh ) DELETE FROM ranked WHERE rn 1;ROW_NUMBER()按word分组rn1保留每组第一行。注意先备份表别直接删。如果重复词同时有不同释义比如bow既是「弓」又是「船头」你不应该机械删掉其中一个而是应该把多个释义合并进一个meaning字段里。这才是词库维护。5.2 翻译字段里的逗号和换行Excel 打开一片乱列现象用 Excel 直接打开 CSV词表分成错乱的列word 和 meaning 完全对不上。原因CSV 是普通文本格式如果某个 meaning 字段里包含逗号ABCv. 放弃抛弃这种双引号实际可以正确处理但不少词库导出时没有按 CSV 规范加引号。还有少数词条带换行导致一行被拆成两行。解决用 pandas 先按sepNone的方式读取会直接崩必须确定实际分隔符。更稳妥的是先看原始文本然后用csv模块或 pandas 清洗。对含逗号、换行的字段统一替换或重建引号。示例import pandas as pd # 读取时如果文件规范双引号会被自动处理 df pd.read_csv(raw.csv, encodingutf-8, quotechar) # 对仍可能存在的脏数据把换行替换为空格 df[meaning] df[meaning].str.replace(\r?\n, , regexTrue) df.to_csv(clean.csv, indexFalse, encodingutf-8-sig, quoting1)quoting1表示所有字段都加双引号这是最保守的 CSV 写法Excel 打开绝不会错列。代价是文件体积大一点但 10 万行完全无所谓。5.3 空值 NULL用WHERE meaning 查不到现象导入之后发现很多单词没有翻译但WHERE meaning 查出来是 0 行明明字段显示是空。原因SQL Server 中NULL和空字符串是两回事。如果源 CSV 里对应位置是空白BULK INSERT导入后可能变成NULL也可能变成空字符串取决于表的字段是否允许NULL。WHERE meaning 只匹配空字符串不匹配NULL。解决统一处理SELECT word FROM dict_en_zh WHERE meaning IS NULL OR LEN(LTRIM(RTRIM(meaning))) 0;MySQL 里把LEN改成LENGTH。如果确认这些空翻译词条没什么价值可以直接删但我是建议保留表结构只做标记因为后续可能补音标或释义删了还得找回来。空值处理要放在服务端查询之前因为 10 万行里有几百个空值你在 App 里返回空字符串用户会以为翻译挂了。5.4 中文乱码为什么 SELECT 出来全是问号现象导入后中文全部变成???或者 SQL Server 里显示战之类奇怪字符。原因CSV 是 UTF-8 编码但导入时没有被正确识别。SQL Server 里BULK INSERT默认按数据库排序规则解析如果排序规则是 Chinese_PRC_CI_AS它默认按 GBK 读文件UTF-8 就被读成乱码。MySQL 里则是没有设置CHARACTER SET utf8mb4。解决SQL Server 在BULK INSERT里显式加CODEPAGE65001。如果用了导入向导在「选择数据源」页面的高级选项里也要把字符编码改为 UTF-8。导入前还可以用bcp加-C 65001。MySQL 则是在导入前执行SET NAMES utf8mb4。乱码不是数据坏了是解码错位改完编码重新导入就行别急着改表数据。5.5 10 万行导入超时或 SSMS 卡死现象在 SSMS 里直接执行一个包含 10 万行 INSERT 的 .sql 文件跑了 20 分钟还在转最后超时中断有的人把 Excel 里的 10 万行直接复制粘贴进编辑窗口一秒拖垮 SSMS。原因单条 INSERT 语句插入 10 万行的 SQL 脚本默认每条执行都要做日志记录、约束校验、索引维护SQL Server 还在其中生成大量事务日志当然慢。更别说复制粘贴这种操作会把内存打满。解决用BULK INSERT是正解。如果只能用 INSERT 脚本那就分批提交每 5000 行一个事务BEGIN TRANSACTION; INSERT INTO dict_en_zh(word, phonetics, meaning) SELECT abandon, /əˈbændən/, v. 放弃 WHERE NOT EXISTS (SELECT 1 FROM dict_en_zh WHERE wordabandon); COMMIT;写循环或让客户端生成多条INSERT然后每 5000 条 commit 一次。另一种更快的方式是导入之前先删掉word的唯一索引导完再重建。这样插入时不检查唯一性能快不少。重建索引本身也就一两秒整体比带索引导入快得多。注意导完立刻重建索引否则后续查询慢成蜗牛。6. 只用一条基线校验词库行数、哈希和抽样翻译拿到任何词库我做的第一件事不是导入而是验证。103976 这个数字是撰稿人给的基线但你手里的文件可能因为下载中断、编码转换、Excel 二次保存而发生变化。三个校验方法配合起来能把坑基本填平。6.1 行数校验三个渠道三个数字对不上就逐层查CSV 的行数可以用命令行快速看Windows PowerShell 和 Linux 各一条# Linux 下统计有效数据行数排除表头 tail -n 2 en_dict.csv | wc -l# Windows PowerShell 下同样排除表头 (Get-Content en_dict.csv | Select-Object -Skip 1).Counttail -n 2从第二行开始输出wc -l统计行数。PowerShell 的Get-Content会把整个文件读成数组10 万行不算慢。SQL 数据库里则用SELECT COUNT(*) FROM dict_en_zh;如果三个数字都对不上先查是不是文件尾部多了一个空行或者有字段里包含换行符导致实际物理行数大于词条数。唯一可靠的对账入口是COUNT(DISTINCT word)它才是真正的词条数。行数只是一个参考不要死磕物理行数。6.2 用哈希校验文件完整性Windows 与 Linux 两条命令文件下载了一半、网盘同步被截断这些情况肉眼看不出来但哈希值能一锤定音。如果你是从原发布渠道拿的文件原网页通常会给出 MD5 或 SHA256。Linux 下sha256sum en_dict.csvWindows 下用系统自带的certutilcertutil -hashfile en_dict.csv SHA256输出的一长串十六进制字符串就是哈希。和官方、或者和下载下来的压缩包里的 checksum 文件比对一致就说明文件没坏。如果词库作者没给哈希你就在本地第一次校验后记录下这个值作为自己后续维护的基线。以后改过任何一行哈希都会变这样可以避免「以为换成了最新版其实改坏了」的尴尬。6.3 抽样翻译别全信词库建立自己的维护分支即使哈希一致、行数也对词库内容仍可能有拼写错误或释义过时。我每接手一个新词库都会做一次抽样用 SQL 随机取 30 行人工把单词和翻译过一遍。SQL Server 里可以这样取SELECT TOP 30 word, meaning FROM dict_en_zh ORDER BY NEWID();NEWID()为每行生成随机 GUIDORDER BY NEWID()相当于洗牌。MySQL 用ORDER BY RAND()10 万行上稍慢但只是抽样可以接受。抽到的词如果出现「翻译明显不对、词性缺失、音标为空」等问题你就知道这批数据的质量等级。 30 行里如果有 5 行以上有问题我不建议直接上生产先清洗。少数小问题我习惯在业务系统里加一个「人工修正覆盖表」用用户反馈或自己维护的补丁去覆盖词库值而不是直接改原始词库文件。这样原词库永远是干净的基线修正记录也能追溯。先验证、再上生产这是数据人最基本的肌肉记忆。上面这几步做完你才能放心把这个词库接到自己的脚本里。希望帮到你。本文还有配套的精品资源点击获取
