简介一份包含103976个英文单词的翻译库同时提供SQL、CSV、Excel三种格式面向英语学习者、翻译工作者及软件开发者。库表内置英文单词、中文翻译、词性及多种词义执行SQL语句即可生成表支持SQL Server、MySQL等主流数据库SQL脚本可直接在phpMyAdmin中导入便于快速部署。压缩包共8个文件以SQL脚本和CSV数据为主体另有Excel预览、说明文档以及单词库表展示、文件预览等截图整体大小仅4.63MB轻量高效。目前已有1612人学习下载。通过这份资源可快速搭建本地单词数据库满足词典查询、批量检索、统计分析或二次开发需求Excel/CSV版本便于人工查阅、编辑和迁移适合无数据库经验者直接使用。附带截图可辅助核对数据完整性与表结构减少导入后的调试成本文件目录简洁导入后即可开展查询与统计工作。1. 103976 个英文单词翻译库一份数据三种格式先想清楚在哪用手头拿到这份 103976 个英文单词翻译库的时候第一反应别是打开 Excel 数行数而是先想清楚我要在什么环境里消费这批数据。做背单词 App 要的是数据库写文本预处理脚本要的是 CSV人工校对词条释义则离不开 Excel。这份资源把同一批词条拆成 SQL、CSV、Excel 三种格式就是为了让不同角色各取所需。适合谁用需要英文单词到中文翻译映射的开发者、做词典查询功能的学生、搞自然语言处理前要一个基础词表的从业者。它不是词典软件是一份能直接喂给程序的数据源拿到手先别急着导入把格式边界搞清楚再动手。2. 三种格式不是简单重复数据组织方式与应用场景的差异2.1 同样是词条数据三份文件的存储思路完全不同先明确一个容易被忽略的事实SQL、CSV、Excel 三份文件里装的内容理论上是一致的但组织方式决定了它们各自的适用边界。CSV 是纯文本结构每一行是一条记录字段之间用逗号分隔。它的优点是任何语言、任何工具都能读几十兆的文件用记事本也能打开看前几行。缺点也很直接没有数据类型、没有索引、没有约束数据对不对完全靠使用者自己保证。而且 CSV 文件本身不携带编码声明UTF-8 编码的 CSV 用 Excel 双击打开中文翻译大概率直接乱码这不是文件坏了是编码处理机制的问题。Excel 版本质上是一个二维表格有工作表、有单元格格式适合人眼审阅。你可以直接拉筛选、做条件格式、在列上做排序这些都是 CSV 和 SQL 没法给的工作台体验。但 Excel 不适合作为程序的数据源因为读取 xlsx 格式需要额外的解析库数据量大了以后打开和保存都明显变慢而且 Excel 在单元格里塞长文本时容易遇到换行符和引号被截断的问题。SQL 版则把数据放进真正的关系型数据库里强调结构化和查询能力。导入后可以做关联查询、加索引、做去重和聚合统计。它对应的使用场景是生产环境你的程序需要频繁查询某个单词的翻译或者你要把词库跟用户表、学习记录表做关联。SQL 文件的体积通常比 CSV 更小因为它包含建表语句和批量插入语句数据经过数据库引擎管理查询效率天花板也更高。2.2 数据内容的边界先看表头再谈使用这份资源所谓的“翻译库”核心内容是英文单词或短语与中文释义的对应关系。我在拆这类资源时第一步永远是先看表头而不是看数据本身。一般这类词库文件里可以看到的关键列包括英文词条、中文翻译有些版本会附带词性标注或音标。但请注意不同来源的词库字段设计不一致你拿到的这份不一定包含音标和词性可能只有最核心的两列。不要假设字段齐全打开后核对一下再继续。还有一点值得留意数据里除了单词往往会混入一些短语、词组甚至短句。这本身不是错误但会影响你的使用策略。如果你要做分词或者拼写检查短语混入会干扰统计结果如果是做翻译对照短语反而是加分项。我一般会先统计一下词条长度分布看看有没有明显超出“单词”范畴的记录再决定是整体使用还是拆出来单独处理。另外要确认编码。SQL 文件通常是 UTF-8 编码CSV 文件则有可能是 UTF-8 也可能是 GBK具体以文件内容为准。识别方法很简单用 VS Code 打开看乱不乱码或者查看文件字节流特征。这一步判断错了后面所有操作都会跟着翻车。2.3 选型判断什么场景该用哪一份我的习惯是画一条线程序运行期要用的数据一律进数据库离线分析或脚本一次性处理用 CSV涉及人工审阅、校对、讨论翻译是否准确才打开 Excel。举几个具体场景。你做一个单词查询接口用户输入一个英文词返回中文释义这种高频点查必须用 SQL 版建个索引后查询是毫秒级。你跑一个语料清洗任务要把文本里的英文单词批量替换成中文标签这种批处理任务用 CSV 就够了Python 里 pandas 读进来是 DataFrame处理起来比连数据库还方便。你打算人工校对词义或者给学生出一份易混淆词汇表那就用 Excel筛选、排序、标注都在一个文件里完成。选型没有绝对的对错但有一条建议适用所有人不要把 Excel 另存为 CSV 交给程序去读也不要把一个 CSV 直接当数据库去高频查询。工具选错了后面每一步都是在给前面的决策买单。3. SQL 版落地从建库到导入再到写查询3.1 导入前先做两件事确认表结构与环境字符集先说环境。SQL 文件本身只是文本它需要在一个数据库实例里执行。常见做法是导入到 MySQL也可以导入到 SQLite 或 PostgreSQL但如果你拿到的 SQL 文件里带有 MySQL 专属的语法比如反引号和 ENGINEInnoDB 这类声明那放在 MySQL 里是最省事的。我一般会先看一眼 SQL 文件的前 50 行确认建表语句和表名。这个动作很有必要因为有些资源打包者在导出时把数据库名、表名写得很随意你不看就直接 source可能创建出来的表名和你预期的不一致后面写查询语句全是坑。再确认字符集。这个决定影响中文翻译能否正确显示。MySQL 导入前先建好数据库指定 utf8mb4 字符集这是最稳妥的做法。# 登录 MySQL这里 root 是管理员账号实际使用请按你的环境调整 mysql -u root -p # 创建数据库字符集使用 utf8mb4排序规则用 unicode_ci 适合英文字母排序 CREATE DATABASE IF NOT EXISTS dict_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE dict_db;这段命令里dict_db是我习惯用的库名你完全可以改成其他名称。关键是utf8mb4字符集它比旧版utf8支持更完整的 Unicode 字符能避免一些生僻词或特殊符号变成问号。unicode_ci排序规则则让英文大小写在比较时被视为等价对后续查询友善。然后执行 SQL 文件。如果当前已经在 MySQL 交互终端里可以用source命令source /path/to/english_words.sql;也可以直接在系统命令行里导入适合文件较大时用# 第一个参数是路径第二个参数是 SQL 文件名 重定向让 MySQL 读取文件内容 mysql -u root -p dict_db /path/to/english_words.sql这里有个容易忽略的点如果 SQL 文件内部已经包含了CREATE DATABASE和USE语句那么命令行里再指定库名可能会导致混乱。建议先打开文件看开头几行再决定用哪种导入方式。3.2 导进去之后先做三件事验证数据完整性导入成功不代表万事大吉。SQL 文件在执行过程中可能手滑也可能原数据本身就缺行所以要验证。第一步看表名和行数。第二步随机抽样看几条数据是否乱码。第三步看有没有明显的空字段和重复词条。-- 查看当前库里的所有表确认导入的表名 SHOW TABLES; -- 查看表结构确认有哪些字段列 DESC english_words; -- 统计总行数判断是否接近 103976 SELECT COUNT(*) FROM english_words;如果COUNT(*)和资源描述的 103976 偏差较大检查 SQL 文件是否被部分执行。执行时遇到报错会中断常见的报错原因是某一行数据里含有未转义的单引号或特殊字符。再抽几行看看-- 随机取 5 条看看翻译是否正常显示 SELECT * FROM english_words ORDER BY RAND() LIMIT 5;注意这里的ORDER BY RAND()在十万行数据上会慢一些但只查一次完全能接受没必要为了这么一条验证语句去做优化。看到的翻译若是问号或乱码说明导入时的连接字符集设置有问题回到导入步骤重新指定--default-character-setutf8mb4。3.3 常用查询语句与参数细节数据落地以后真正高频的操作是查词。这里的查询写法和普通业务表没有区别但词库数据有些特殊的坑写语句时要注意。精确查一个词的翻译-- 精确匹配单词大小写不敏感因为排序规则是 unicode_ci SELECT word, translation FROM english_words WHERE word abandon;模糊查一批前缀相同的词-- 前缀匹配可以命中 abandoned、abandonment 等词 SELECT word, translation FROM english_words WHERE word LIKE abandon% ORDER BY CHAR_LENGTH(word) LIMIT 20;LIKE abandon%这种写法在 10 万行数据上表现还可以因为前缀匹配能走索引。但如果你写成%abandon%中间匹配那就是全表扫描数据量小无所谓但养成好习惯没坏处。CHAR_LENGTH是统计字符数而不是字节数对英文单词来说二者一样但如果你想按词长筛选用它更严谨。按词长筛选短词适合制作儿童词表或基础词表-- 只取 3 到 6 个字母的单词过滤带空格和特殊符号的词条 SELECT word, translation FROM english_words WHERE CHAR_LENGTH(word) BETWEEN 3 AND 6 AND word REGEXP ^[a-zA-Z]$ LIMIT 200;这里的REGEXP ^[a-zA-Z]$是筛掉含有空格、连字符、数字的词条排除短语干扰。这个正则写法和 Python 里的正则基本一致你在 MySQL 8.0 里可以直接用5.7 版本对 REGEXP 的支持也够。导出子集到 CSV用于交接给其他同事做人工核对-- 把基本动词按首字母分组导出注意 INTO OUTFILE 有服务器目录权限限制 SELECT word, translation FROM english_words WHERE word LIKE re% INTO OUTFILE /tmp/re_words.csv FIELDS TERMINATED BY , ENCLOSED BY LINES TERMINATED BY \n;重点说明一下INTO OUTFILE它要求 MySQL 的secure_file_priv变量允许写入而且输出文件是写在你数据库服务器本机上的不是你的客户端电脑。权限不足会报The MySQL server is running with the --secure-file-priv option。遇到这个报错查一下SHOW VARIABLES LIKE secure_file_priv再决定路径或者干脆把查询结果复制出来在客户端工具里另存。4. CSV 与 Excel 版实战不写 SQL 也能把词库用起来4.1 用 Excel 做筛选和比对注意编码转换Excel 版适合人工操作但如果打开后发现中文乱码别急着删文件先检查是不是直接双击打开的。CSV 和 Excel 在编码处理上有本质差异Excel 打开一个纯 UTF-8 编码的 CSV 时默认按系统区域编码解析中文字符会变成乱码。解决方案有两个一是用 Excel 的“数据 → 从文本/CSV”导入功能手动选择文件原始格式为 UTF-8二是用文本编辑器把 CSV 重新保存为带 BOM 的 UTF-8这样 Excel 双击打开时能正确识别。在 Excel 里常见的操作是筛选。假设你想找所有以 “bio” 开头的生物类词汇直接在“英文词条”列上做文本筛选前缀为 “bio”几秒钟就能得到结果。再比如你想查看翻译长度异常的记录在“中文翻译”列上按字符数排序能快速定位到那些可能混入例句解释的条目。VLOOKUP 是 Excel 用户最常用的工具。如果你有一个自己的英文词表想在新表里批量补充中文翻译可以在旁边的列写公式VLOOKUP(A2, 词库表!A:B, 2, FALSE)公式里A2是你的待查词所在单元格词库表!A:B指向翻译库工作表的英文列和中文列2表示取第二列也就是翻译FALSE表示精确匹配。用的时候注意VLOOKUP 对查找值的大小写不敏感但要求词库表的首列必须是英文词条且数据范围里不能有重复项否则只返回第一个匹配结果。4.2 用 Python 直接吃 CSVpandas 一步到位CSV 版最大的价值在于程序化处理不依赖数据库环境。我用 pandas 读取这类文件已经是固定动作。import pandas as pd # 读取 CSV指定编码为 utf-8如果报错就试 gbk 或 utf-8-sig df pd.read_csv(english_words.csv, encodingutf-8) # 查看形状和前五行确认列名和内容 print(df.shape) print(df.head()) # 查看列名清单 print(df.columns.tolist())df.shape会输出类似(103976, 2)或(103976, 4)的结果行数能直接验证资源完整性。encoding参数需要你根据文件实际情况调整utf-8-sig专门用来处理带 BOM 的文件遇到兼容性问题可以优先试它。接着做一次去重和清洗这是 CSV 做数据分析必须的一步# 去重英文词条完全相同的情况下保留第一条 df df.drop_duplicates(subset[word], keepfirst) # 去掉翻译为空的记录 df df[df[translation].notna()] # 去掉词条里包含空格的短语如果你只需要单词的话 df_words_only df[~df[word].str.contains( , naFalse)] print(df_words_only.shape)这里的逻辑是先按英文词条去重再过滤空翻译最后把含有空格的短语剔除。~是取反符号表示“不包含空格”。你如果是想专门提取短语把~去掉即可。把清洗后的数据导出成 JSON 给前端用# 转成 JSON 数组格式force_asciiFalse 保证中文不被转义成 \uXXXX df_words_only.to_json(words_clean.json, orientrecords, force_asciiFalse)这个导出动作在前后端分离的项目里很常用。前端拿到 JSON 可以直接做本地搜索不再需要每次查后端。force_asciiFalse这个参数值得记住它控制是否把中文输出成 Unicode 转义序列默认是True不改成False的话导出的 JSON 可读性极差。4.3 把 CSV 合成到自己的数据集里另一个高频需求是把词库和你自己的数据合并。举个例子我做过一个背单词打卡工具用户会记录自己想背的单词我拿了这份翻译库来做外键关联在界面上显示每个单词的中文释义。# 用户学习记录表里有一个 word 字段现在关联翻译库 user_words pd.read_csv(user_session.csv, encodingutf-8) merged user_words.merge(df_words_only[[word, translation]], onword, howleft) # 检查哪些单词没匹配上翻译 unmatched merged[merged[translation].isna()] print(unmatched)核心逻辑是merge操作howleft表示以左边用户表为准保留用户的所有记录右边翻译库能匹配就填上匹配不上就留空。没匹配上的记录通常是用户拼写错误或者词库里确实没有收录。这时候可以用一个简单的模糊匹配兜底比如计算编辑距离但这属于进阶玩法基础关联先跑通再说。5. 避坑指南字符集、重复词条与字段不一致的典型翻车现场5.1 字符集翻车打开全是乱码导入后也是乱码现象CSV 文件用 Excel 双击打开中文翻译全部变成“鎴戞槸”这类乱码SQL 文件导入 MySQL 后查询结果也是问号。原因CSV 文件是 UTF-8 编码Excel 默认用本地 ANSI 编码解析解析错位导致乱码。SQL 文件本身没问题但导入时 MySQL 客户端连接字符集设成了默认的 latin1或者数据库表字符集用了旧版 utf8。解决CSV 用 Excel 的“从文本/CSV 导入”功能选 UTF-8 编码或者用文本编辑器另存为带 BOM 的 UTF-8 格式。SQL 导入时在 mysql 命令行加--default-character-setutf8mb4参数建表时指定utf8mb4字符集。这个步骤在上一章已经详细展开这里不再重复但要记住以后接手任何词库类资源第一步先验编码别信文件后缀。5.2 同一个词出现多行翻译互相矛盾现象查test这个单词返回了好几行翻译有“测试”“试验”“考查”还有一行翻译是“测试试验检验”格式完全不统一。原因词库在整理时没有做多义词合并同一个词的不同义项分别保留了多条记录。这本身不算错误但如果程序按单词查翻译并展示单条结果就会随机返回其中一条。解决根据使用场景决定策略。做展示类应用可以按词性分组把多行合并成一条带多个义项的记录做统计类应用则要做drop_duplicates按第一个匹配保留。我是用词频信息来排序的优先保留更常用的那个翻译但这个前提是你有额外的词频数据源没有的话就保留第一个或合并显示。5.3 SQL 导入到一半报错后面数据全没进去现象执行 SQL 文件时终端在一半左右的进度突然报语法错误再往下全是连续报错导入结束后查行数发现只有几万条远少于 103976。原因SQL 文件里某一行数据包含未转义的单引号、反斜杠或特殊 Unicode 字符导致 MySQL 把后面的内容误认为是语法关键字。也可能原始数据里某个词条包含换行符把一条 INSERT 语句拆成了两截。解决先定位报错行号用文本编辑器跳到那一行人工检查大概率能看到异常字符。直接编辑 SQL 文件修补是最快的方法但修补前做好备份。更稳妥的通用做法是绕过 SQL 文件直接把 CSV 转成 LOAD DATA 格式导入因为 LOAD DATA 对特殊字符的容忍度更高且支持自定义转义符。不过这里要说清楚这份资源给的是 SQL 版理论上导出时已经处理过转义遇到这种问题通常是你用的 MySQL 版本或sql_mode和导出环境不一致可以试着SET sql_mode关闭严格模式后重试。5.4 全表查询很快加了个模糊搜索就卡死现象查单个单词秒出结果用LIKE %ing查所有以 ing 结尾的单词时查询耗时几十秒。原因精确匹配走了索引中间匹配无法走 B-Tree 索引只能全表扫描。10 万行不算大但没有索引加持的LIKE %xxx仍然会让 MySQL 做全量字符串匹配慢在磁盘 IO 和 CPU 计算。解决优先改写查询为前缀匹配先建索引再用LIKE ing%这种方式。如果确实需要后缀匹配考虑把英文词条反转存储一个冗余列再对反转列建索引这条路我在这类词库项目里用过效果立竿见影。另外把LIMIT加上会让查询更快因为它中途就可以停止扫描。5.5 词条里混入短语和整句导致翻译字段过长现象本意是筛选“单词”做统计结果发现数据里混入了“take a break”“as a matter of fact”这类短语甚至还有完整的例句翻译字段从两个字到三十个字都有。原因这类综合词库通常收录了大量常用短语和表达而不仅仅是孤立单词。这对翻译库来说是丰富的但对需要做词汇量统计、拼写检查、单词长度分析的人来说是噪音。解决在清洗阶段用正则过滤掉包含空格的词条如同 4.2 节里演示的那样。保留短语还是过滤短语没有标准答案取决于你项目的目标场景。我自己的习惯是做词频统计或拼写纠错时只要单一单词做翻译功能时保留短语反而更有价值用户查“take a break”比查“take”更符合真实需求。6. 进阶把词库改造成一个可用的查询接口数据落在 CSV 里只解决了离线问题真正把它当生产数据用还是得起一个轻量服务。这里我给一个最小可运行的思路Python SQLite Flask。先把 CSV 转成 SQLite 数据库这样避免依赖重型 MySQL 服务适合个人项目和教学用途。import sqlite3 import pandas as pd # 读取清洗后的 CSV df pd.read_csv(words_clean.csv, encodingutf-8) # 建立 SQLite 连接文件不存在时自动创建 conn sqlite3.connect(words.db) # to_sql 会自动建表if_existsreplace 表示表存在就重建 df.to_sql(words, conn, if_existsreplace, indexFalse) # 给单词列加索引显著提升查询速度 conn.execute(CREATE INDEX idx_word ON words(word)) conn.commit() conn.close()这段的关键在to_sql它把 pandas DataFrame 直接推成数据库表免去了手写建表语句的麻烦。indexFalse表示不把 DataFrame 的索引写进去否则会多出一列无意义的自增列。加索引那一步必须在推完数据进行否则十万行数据to_sql后再CREATE INDEX执行时间会明显偏长。然后起一个最简查询接口from flask import Flask, jsonify, request import sqlite3 app Flask(__name__) def query_word(word): conn sqlite3.connect(words.db) cur conn.cursor() cur.execute(SELECT word, translation FROM words WHERE word ?, (word,)) row cur.fetchone() conn.close() return row app.route(/api/translate) def translate(): word request.args.get(word, ).strip().lower() if not word: return jsonify({error: word is required}), 400 row query_word(word) if row: return jsonify({word: row[0], translation: row[1]}) return jsonify({error: word not found}), 404 if __name__ __main__: app.run(host0.0.0.0, port5000)这里有几个参数值得解释。?是 SQLite 的占位符用它代替字符串拼接能避免 SQL 注入这类查词接口很容易被人拿来测试注入所以养成用占位符的习惯很重要。strip().lower()把用户输入前后空格清掉并统一小写因为词库里的词条大多数是小写形式这一步能大幅降低匹配失败率。host0.0.0.0允许局域网访问你在本机调试的话改成127.0.0.1更安全。接口跑起来后在浏览器输入http://localhost:5000/api/translate?wordabandon返回的就是这个词的中文翻译。如果你想加批量查询把接口改成接收 JSON 数组循环调用query_word就能实现。这个改造把静态的词库文件变成了一个标准的 HTTP 服务前端、小程序、爬虫脚本都能接入。我后面每次拿到新的词库资源都会走一遍同样的流水线验编码、看字段、去重清洗、入 SQLite、起接口。这套流程帮我挡掉了很多后续联调时的脏数据问题。从那以后我每次拿到词库文件都强制先跑一遍字符集和重复项检查这个习惯救了不少项目。希望帮到你。本文还有配套的精品资源点击获取