簡介這份韓語詞匯表資源包面向韓語學(xué)習(xí)者、詞典研究與自然語言處理開發(fā)者提供可直接用的韓語詞條原始數(shù)據(jù)與結(jié)構(gòu)化詞典。壓縮包內(nèi)共五份文件含兩個JSON詞典文件、兩個TXT單詞列表和一份Markdown說明文檔整體體積約28.37MB。wordslist.txt收錄完整單詞列表包含重復(fù)項wordslistUnique.txt為去重后的單詞集合兩個JSON文件分別對應(yīng)整理前后的詞條與釋義描述結(jié)構(gòu)清晰便于用Python、JavaScript等語言直接解析。資源還附帶README使用說明并給出查詢國立韓國語標(biāo)準(zhǔn)韓語詞典的示例鏈接方便用戶核驗詞條拼寫、釋義及來源也可借此擴展更多詞條。目前已有391人學(xué)習(xí)下載適合需要構(gòu)建韓語詞庫、制作背詞應(yīng)用、進行詞匯頻率統(tǒng)計或基礎(chǔ)文本分析的學(xué)習(xí)者與開發(fā)者可顯著減少數(shù)據(jù)收集與清洗的時間成本。1. korean_wordlist 是什么一份干凈的韓語詞庫能幫你做什么做韓語學(xué)習(xí)工具或者文本處理的時候最先攔住你的往往不是算法而是一份能直接用的韓語詞匯表。korean_wordlist 這個韓語詞匯表項目就是把散落在 TOPIK 考綱、教材單詞表和語料庫里的韓語詞條整理成帶讀音、詞性、釋義和等級的 JSON 詞庫讓拿到手的人省掉寫爬蟲和清洗數(shù)據(jù)的體力活。如果你正準(zhǔn)備做背單詞 App、詞典查詢接口、歌詞或新聞生詞標(biāo)記這個方向值得先評估清楚再投入。這類詞匯表的價值不在于“有多少個詞”而在于字段是否規(guī)范、等級是否可排序、詞元是否做了原形歸一。我見過不少從零爬詞表的團隊光清洗就耗掉兩周最后還被“同詞多義”“活用形態(tài)匹配不上”這些細節(jié)卡住。這篇筆記會先把詞表的結(jié)構(gòu)講明白再給出加載、篩選、導(dǎo)出和覆蓋率分析的腳本最后列幾個我實際踩過、你大概率也會碰到的坑。2. 詞匯表的數(shù)據(jù)組織方式字段設(shè)計、來源與清洗邏輯把韓語詞匯表當(dāng)普通詞表用最容易翻車的點就是字段不統(tǒng)一。有的詞條只有韓語和中文沒有詞性沒有等級連讀都沒有這種數(shù)據(jù)只能做最粗糙的詞典展示一旦要做等級篩選或者按詞性分組立刻歇菜。所以拿到任何一份 korean_wordlist先搞清楚它的字段設(shè)計再決定怎么接入自己的業(yè)務(wù)。2.1 一個詞條該有哪幾個字段詞元、讀音、等級與釋義的取舍一個最少可用、能支撐大部分場景的詞條至少需要五個字段word 存韓語原形romanization 存羅馬音meaning 存中文釋義pos 標(biāo)詞性level 標(biāo)難度等級。這五個字段已經(jīng)足夠覆蓋“查詞、背單詞、按等級篩詞”三件事。如果要做更深的 NLP 處理建議再加 example 例句和 vtype 動詞活用類型。詞元的選擇直接決定后續(xù)匹配效率。韓語詞典按原形收錄詞條比如“??”是原形而“???”“??”“???”都是它的活用形態(tài)。詞表里必須存原形查詢階段再通過活用映射或詞形還原把文本歸一到原形。如果當(dāng)初存的是“???”用戶查“??”就永遠匹配不到這是詞匯表項目最常見的硬傷。等級字段建議直接用“TOPIK1”到“TOPIK6”這種可排序字符串不要用“初級”“中級”“高級”這種模糊標(biāo)簽。原因是字符串可以按字典序或自定義映射做篩選而“初級”這類標(biāo)簽無法直接參與排序邏輯。下面是一個典型詞條結(jié)構(gòu){ word: ??, romanization: hada, pos: verb, level: TOPIK1, meaning: 做進行, example: ??? ??. }這個 JSON 示例里example 字段不是必選。做純查詢工具可以不要但做學(xué)習(xí)類 App 最好保留因為例句能幫用戶理解上下文。另外一個取舍是 romanization如果你只做韓語文本分析羅馬音是冗余字段如果你面向初學(xué)者這個字段就是剛需因為不是所有用戶都熟練韓文讀寫。2.2 從原始詞表到干凈詞庫清洗和去重的三個關(guān)鍵步驟常見詞表來源有三類TOPIK 官方公布的考綱詞、教材單元詞匯表、從語料庫按詞頻抽出的高頻詞。官方考綱詞干凈但字段少教材詞表帶著單元編號和課文例句語料庫詞表則混入大量人名地名。三類數(shù)據(jù)合并之后清洗工作基本逃不掉。清洗經(jīng)驗可以歸納為三步。第一步做格式規(guī)范化把全角半角、多余空白、行尾符號統(tǒng)一處理第二步以 word 字段為主鍵去重同一個詞元的多條釋義用分號合并第三步削除空值條目比如沒有釋義、沒有讀音的“死詞”。import re from collections import defaultdict def normalize_text(text: str) - str: 規(guī)范化文本去除兩端空白把連續(xù)空格折疊為單個 return re.sub(r\s, , text.strip()) def dedup_entries(entries: list[dict]) - list[dict]: 以 word 為主鍵去重并把同一詞元的釋義合并 merged defaultdict(list) for entry in entries: word entry.get(word, ).strip() if word: merged[word].append(entry) result [] for word, items in merged.items(): base items[0].copy() meanings [item.get(meaning, ) for item in items if item.get(meaning)] if meanings: base[meaning] .join(meanings) result.append(base) return resultnormalize_text 里的正則\s會把換行、Tab 和連續(xù)空格統(tǒng)一折疊成單個空格這是清洗的基本功。dedup_entries 的主鍵默認(rèn)是 word如果你的詞表里有同詞形不同詞性的條目比如“??”既是動詞也是助動詞的搭配那主鍵就要改成 (word, pos) 二元組否則會錯誤合并。這個細節(jié)是最容易被忽視的。2.3 韓語詞元化為什么動詞必須和詞尾分開存韓語動詞和部分形容詞的活用形態(tài)非常豐富。以“??”為例常見變體有“??”口語體、“???”正式禮貌體、“???”過去時。如果詞表只存原形“??”在文本里遇到“???”時做字符串完全匹配是必定失敗的而做包含匹配也匹配不上因為“???”的字符序列里并沒有連續(xù)的“??”。嚴(yán)謹(jǐn)做法是對文本做形態(tài)分析把“???”還原成詞干“?”再去詞表比對。但這依賴韓語 NLP 庫對純詞匯表項目來說偏重。折中方案是把常用活用形態(tài)直接預(yù)置進詞表用 forms 字段枚舉出來查詢時先查原形、再查 forms兼顧了精度和實現(xiàn)成本。def search_word(words: list[dict], text_word: str): 先匹配原形再匹配 forms 里的活用形態(tài) for w in words: if text_word w.get(word): return w if text_word in w.get(forms, []): return w return None這段代碼假定詞表在清洗時已經(jīng)補齊了 forms 字段比如“??”的條目下掛著[???, ??, ???]。實際構(gòu)建時forms 數(shù)據(jù)可以來自教材自帶的變化表也可以自己寫腳本收集常見活用。成本不高但能解決學(xué)習(xí)工具里大部分“搜不到”的困擾。如果你對精度要求高、不介意依賴再上形態(tài)分析器也不遲。3. 用 Python 操作 korean_wordlist加載、篩選與查詢的實用腳本這一章寫給想立刻跑起來的讀者。我統(tǒng)一用 JSON 格式的 korean_wordlist 作為輸入腳本保持最小依賴只用到標(biāo)準(zhǔn)庫。三個小節(jié)分別解決“讀取文件”“按等級篩選”“模糊查詢”三個日常動作腳本可以直接抄進項目里改參數(shù)用。3.1 把 JSON 詞匯表加載成 Python 對象的最小腳本加載詞匯表本身不復(fù)雜但有幾個細節(jié)會坑人文件路徑不存在、JSON 最外層是字典而不是列表、文件編碼不是 UTF-8。一個健壯的加載函數(shù)應(yīng)該把這三件事都處理掉而不是等到出錯再排查。import json from pathlib import Path DEFAULT_PATH Path(korean_wordlist.json) def load_vocabulary(path: Path DEFAULT_PATH) - list[dict]: 加載詞表 JSON兼容最外層為列表或字典兩種結(jié)構(gòu) if not path.exists(): raise FileNotFoundError(f未找到詞表文件: {path}) with path.open(r, encodingutf-8) as f: data json.load(f) return data if isinstance(data, list) else data.get(words, [])path 參數(shù)是 Python 3.6 引入的 pathlib.Path 類型用字符串路徑也能隱式轉(zhuǎn)換。encoding 參數(shù)寫“utf-8”是因為絕大多數(shù) korean_wordlist 項目都按 UTF-8 發(fā)布如果你從 Windows 拿到舊數(shù)據(jù)可能要用“utf-8-sig”才能去掉 BOM 頭。返回值統(tǒng)一成列表是考慮到后續(xù)篩選、統(tǒng)計邏輯只依賴列表結(jié)構(gòu)。加載之后建議先看幾條樣本確認(rèn)字段名和自己的預(yù)期一致。我常用的調(diào)試方式是打印一條load_vocabulary()[0]如果word和meaning的鍵名對不上后邊所有腳本都會報 KeyError。3.2 按 TOPIK 等級篩選詞匯的三個參數(shù)等級篩選是所有學(xué)習(xí)類功能里最常用的操作用戶說“我只想背初級詞”你就要把 TOPIK1 和 TOPIK2 的詞都拉出來。這里提供一個帶三個參數(shù)的篩選函數(shù)分別是 level、include_higher 和 limit。def filter_by_level( words: list[dict], level: str TOPIK2, include_higher: bool False, limit: int | None None ) - list[dict]: 篩選指定等級詞條可包含更高等級可限制返回數(shù)量 valid_levels {level} if include_higher: level_no int(level.replace(TOPIK, )) valid_levels {fTOPIK{i} for i in range(level_no, 7)} filtered [w for w in words if w.get(level) in valid_levels] if limit: filtered filtered[:limit] return filteredlevel 參數(shù)傳“TOPIK2”是精確匹配include_higher 設(shè)為 True 時會返回 TOPIK2 到 TOPIK6 的全部詞條適合做“進階”功能。limit 是給調(diào)試用的先看 10 條確認(rèn)數(shù)據(jù)結(jié)構(gòu)再放開全量。注意level.replace(TOPIK, )依賴等級字段命名規(guī)范如果你的詞表用的是“topik2”小寫需要先做一次 upper() 歸一。實際項目中這三個參數(shù)足夠覆蓋絕大多數(shù)篩選需求。如果你需要按詞性過濾可以在函數(shù)里再加一個 pos 參數(shù)邏輯完全一致只是判斷條件從w.get(level)換成w.get(pos)。3.3 模糊查詢與詞干匹配處理搜索不到的常見原因詞匯表接入搜索功能時用戶輸入的詞往往和詞表里的原形不完全一致。最常見的情形是輸入了活用形態(tài)比如輸入“???”但詞表存的是“??”。這類問題有兩條路一是先做活躍形式匹配二是用字符串相似度做模糊搜索兜底。Python 標(biāo)準(zhǔn)庫里的 difflib.SequenceMatcher 可以完成簡單的相似度評分對韓語這種音節(jié)文字效果一般但作為兜底已經(jīng)夠用。下面的函數(shù)返回按相似度排序的結(jié)果列表from difflib import SequenceMatcher def fuzzy_search(words: list[dict], query: str, threshold: float 0.6) - list[dict]: 基于序列相似度的模糊查詢返回按匹配分?jǐn)?shù)排序的詞條 results [] for w in words: score max( SequenceMatcher(None, query, w.get(word, )).ratio(), SequenceMatcher(None, query, w.get(romanization, )).ratio() ) if score threshold: results.append((score, w)) results.sort(keylambda x: x[0], reverseTrue) return [w for _, w in results]threshold 參數(shù)控制嚴(yán)格程度0.6 能容忍明顯的拼寫差異但也會把無關(guān)詞放進來0.8 以上基本只留同根詞。建議在 UI 層把 threshold 設(shè)成可調(diào)節(jié)的滑條搜索無結(jié)果時自動降低到 0.5 再查一次。和上一章的 forms 匹配組合使用搜索體驗會好很多。這個函數(shù)對短詞的匹配效果一般因為“??”和“??”的長度只有兩三個字符SequenceMatcher 的評分區(qū)分度不足。所以我的習(xí)慣是優(yōu)先走原形和 forms 的精確匹配模糊搜索只作為最后的兜底。4. 把 korean_wordlist 接進學(xué)習(xí)工具與文本分析三個可直接跑的方案詞匯表本身不產(chǎn)生價值接進實際場景才有價值。這一章講三個最常見的落地路徑導(dǎo)出 Anki 卡片、做文本覆蓋率分析、作為本地詞典服務(wù)的詞庫源。每段都會給出可直接運行的腳本和參數(shù)調(diào)整方法。4.1 生成 Anki 卡片導(dǎo)入 CSV讓詞匯表變成每日任務(wù)Anki 是很多背詞類工具的事實標(biāo)準(zhǔn)而 korean_wordlist 正好可以當(dāng)作卡片數(shù)據(jù)源。常見的做法是把篩選后的詞條導(dǎo)出成一個 CSV再通過 Anki 的文件導(dǎo)入功能建立牌組。腳本的關(guān)鍵是把字段順序固定下來并且用 utf-8-sig 編碼避免 Excel 打開亂碼。import csv def export_to_anki( words: list[dict], output_path: str korean_deck.csv, fields: tuple (word, romanization, meaning, level) ) - None: 導(dǎo)出 Anki 可導(dǎo)入的 CSV 文件字段順序由 fields 控制 with open(output_path, w, encodingutf-8-sig, newline) as f: writer csv.writer(f) writer.writerow(fields) for w in words: row [w.get(field, ) for field in fields] writer.writerow(row)用 utf-8-sig 而不是 utf-8是因為 Excel 打開 UTF-8 文件時默認(rèn)按 GBK 解析中文和韓文會直接亂碼。newline是 Windows 下避免 CSV 每行后邊多一個空行的關(guān)鍵參數(shù)很多人在這一步栽過。fields 元組的順序就是 Anki 導(dǎo)入時的字段映射順序默認(rèn)四列已經(jīng)夠用。導(dǎo)入 Anki 前記得在 Anki 的導(dǎo)入對話框里勾選“允許 HTML”并把第一行是否包含標(biāo)題設(shè)為“否”。如果不希望出現(xiàn)標(biāo)題行可以把writer.writerow(fields)那一行刪掉Anki 會按順序自動映射到卡片模板的字段。4.2 做文本覆蓋度分析用詞表判斷一篇韓語文章的水平文本覆蓋度分析是“這篇文章我能不能讀下來”的量化方法把文章分詞后統(tǒng)計有多少比例的韓語詞條命中詞表。命中率越高說明文章越接近你掌握的詞匯范圍。做法很簡單用正則把韓文音節(jié)塊切出來再和詞表的 word 集合做交并集計算。import re def coverage_ratio(text: str, words: list[dict]) - float: 估算文本中命中詞表的詞條比例返回 0 到 1 的小數(shù) tokens re.findall(r[?-?], text) if not tokens: return 0.0 word_set {w[word] for w in words} hits sum(1 for t in tokens if t in word_set) return hits / len(tokens)正則[?-?]覆蓋了 Korean Unicode 音節(jié)塊的全部范圍能切出“?”“?”“?”這類單個音節(jié)。注意這個邏輯是把每個連續(xù)韓文片段當(dāng)成一個 token不會做真正的形態(tài)分析所以“???”會被當(dāng)做一個整體最終覆蓋率會比實際偏低。要改善的話可以配合上一章的 forms 字段做展開匹配。這個函數(shù)適用于評估文本難度比如 0.9 以上說明文章對當(dāng)前等級用戶很友好0.5 以下則明顯超綱。你也可以在詞表里只有 TOPIK1 和 TOPIK2 時用它判斷一篇新聞稿對初學(xué)者是否可讀。做閱讀輔助工具的話這是最能立竿見影的功能。4.3 作為本地詞典查詢服務(wù)的詞庫源如果你的應(yīng)用需要毫秒級查詢響應(yīng)就不要每次都掃描整個列表。常見做法是在進程啟動時把詞表加載成內(nèi)存索引word 和 romanization 各建一個倒排映射。Python 的 dict 自帶哈希索引對幾千條詞來說查詢耗時可以忽略不計。class KoreanDict: 基于詞匯表構(gòu)建的內(nèi)存詞典支持雙鍵查詢 def __init__(self, words: list[dict]): self.by_word {w[word]: w for w in words if w.get(word)} self.by_romanization {} for w in words: rom w.get(romanization) if rom: self.by_romanization[rom] w def lookup(self, key: str) - dict | None: 按韓語原形或羅馬音查詢詞條查不到返回 None return self.by_word.get(key) or self.by_romanization.get(key)這個類的內(nèi)存開銷大約等于詞表大小的兩倍因為詞條對象被兩個 dict 引用但 Py 的對象引用本身很輕幾千條詞完全無壓力。查詢時先試韓語鍵再試羅馬音鍵兩者都失敗返回 None接口簡單清晰。如果詞表規(guī)模到了十萬級考慮換 SQLite FTS5用 SQL 的 LIKE 查詢做前綴匹配。我實際用它做過一個命令行查詞工具啟動時加載詞表不到 0.2 秒之后每次查詢都在 1 毫秒內(nèi)體驗遠好于每次調(diào)用都重讀 JSON。這個方案唯一要注意的是詞表更新機制建議用版本號加緩存清理策略避免舊數(shù)據(jù)長期駐留。5. korean_wordlist 踩坑記錄五個高頻問題與排查方法這一章不寫泛泛的“注意編碼”之類建議而是按“現(xiàn)象 → 原因 → 解決”的格式記錄我在實際使用 korean_wordlist 過程中真正遇到過的問題。每一條都短小直接你可以直接對照自己的癥狀來排查。5.1 韓文在終端或 Excel 里變成亂碼現(xiàn)象Python 打印詞條時終端顯示一串問號或者打開導(dǎo)出的 CSV 后韓文亂碼。原因多數(shù)情況是 Windows 控制臺默認(rèn)代碼頁是 GBK而詞表文件是 UTF-8 編碼兩者不匹配。另一種情況是 CSV 導(dǎo)出的編碼用了 utf-8 而不是 utf-8-sigExcel 按本地編碼解析出現(xiàn)亂碼。解決在運行腳本前執(zhí)行chcp 65001切換終端到 UTF-8 代碼頁或在 Python 啟動時手動設(shè)置標(biāo)準(zhǔn)輸出編碼。導(dǎo)出 CSV 時一律用encodingutf-8-sig這是和 Excel 兼容最簡單的方式。5.2 搜索單詞原形找不到文本里的活用形式現(xiàn)象詞表里有“??”用戶輸入“???”或“??”時查詢結(jié)果為空覆蓋率分析的結(jié)果明顯偏低。原因詞表按原形收錄而實際文本中大量出現(xiàn)活用形態(tài)字符串完全匹配必然失敗。解決先用原形查一遍失敗后再去 forms 字段里找。如果詞表里沒有 forms 字段可以在查詢函數(shù)里對輸入詞做最常見活用映射比如把結(jié)尾“???”“???”去掉再匹配。形態(tài)分析是最終方案但如果只是做學(xué)習(xí)工具預(yù)置 forms 的成本更低。5.3 同一詞條出現(xiàn)在多個 TOPIK 等級里現(xiàn)象按等級統(tǒng)計詞數(shù)時總詞數(shù)比去重后的詞條數(shù)多出不少用戶背完初級詞表后發(fā)現(xiàn)結(jié)果里混入了高級詞。原因清洗時只按 word 去重沒有考慮同一詞元在多個來源里被標(biāo)成了不同等級后寫入的數(shù)據(jù)覆蓋了前一條。解決把去重邏輯改成“保留最低等級”或“保留最高等級”取決于業(yè)務(wù)目標(biāo)。建議在清洗腳本里增加一個等級合并策略參數(shù)默認(rèn)保留更常用的較低等級并把高等級數(shù)據(jù)合并到 forms 字段里。5.4 一個詞對應(yīng)多個不同釋義篩選邏輯被搞亂現(xiàn)象查“??”返回“去進行通向”時想過濾“去”這個釋義的用戶被其他釋義干擾按釋義統(tǒng)計時詞條被重復(fù)計數(shù)。原因詞匯表把一詞多義合并到一個字段用分號分隔。做展示時沒問題做選擇和統(tǒng)計時字符串包含判斷會把不相關(guān)語義也命中。解決在數(shù)據(jù)清洗階段把多義詞拆成多條記錄每條帶一個 sense_id 字段區(qū)分詞義或者查詢時返回全部釋義讓上層業(yè)務(wù)自行消歧。如果只是做背單詞卡片保留合并狀態(tài)是可以接受的但做語義搜索就一定要拆分。5.5 清洗后的詞庫仍有空字段導(dǎo)致后續(xù)解析報錯現(xiàn)象json.load成功但執(zhí)行w[meaning]時拋出 KeyError或w.get(level)在排序時因為 None 報錯。原因部分詞條缺少某個字段而后續(xù)代碼用了硬索引而不是get方法。詞表文件本身可能有空行、注釋行或結(jié)構(gòu)不完整的條目。解決在加載函數(shù)之后加一道 schema 校驗把必填字段缺失的條目剔除或補默認(rèn)值。代碼里統(tǒng)一使用w.get(field, )避免 KeyError。校驗?zāi)_本建議放在數(shù)據(jù)構(gòu)建階段而不是業(yè)務(wù)運行時否則每次錯誤都是在運行時才暴露。6. 進階技巧把詞匯表變成一份按難度漸進的學(xué)習(xí)清單把 korean_wordlist 當(dāng)作靜態(tài)數(shù)據(jù)用只是發(fā)揮了一半價值。進階用法是把詞表按 TOPIK 等級和詞性重新排序生成一份可以直接照著背的漸進式學(xué)習(xí)清單。這個輸出可以是一份 Markdown 學(xué)習(xí)計劃也可以繼續(xù)導(dǎo)成 Anki 牌組配合每日 20 詞的學(xué)習(xí)節(jié)奏使用。def build_study_plan( words: list[dict], words_per_day: int 20, group_by_pos: bool True ) - str: 生成按等級優(yōu)先、詞性分組的每日學(xué)習(xí)清單 level_order {fTOPIK{i}: i for i in range(1, 7)} ordered sorted( words, keylambda w: level_order.get(w.get(level), 99) ) if group_by_pos: pos_order {noun: 0, verb: 1, adjective: 2, adverb: 3} ordered.sort(keylambda w: pos_order.get(w.get(pos), 9)) lines [] for i in range(0, len(ordered), words_per_day): day_no i // words_per_day 1 lines.append(f## Day {day_no}) for w in ordered[i:i words_per_day]: lines.append( f- {w[word]} ({w.get(romanization, )}) {w.get(meaning, )} ) return \n.join(lines)words_per_day 參數(shù)直接控制學(xué)習(xí)節(jié)奏我一般取 20 到 30 之間低于 10 會讓戰(zhàn)線拉得過長超過 50 則不適合長期堅持。group_by_pos 開啟后同一天的詞條會按名詞、動詞、形容詞、副詞分組呈現(xiàn)這樣針對性更強特別是動詞和形容詞對韓語活用學(xué)習(xí)最重要。生成結(jié)果可以直接存成study_plan.md配合 Anki 的批量導(dǎo)入做兩輪復(fù)習(xí)。我自己的習(xí)慣是每隔兩周重新跑一次這個腳本因為詞表更新或等級調(diào)整后學(xué)習(xí)路線也跟著變。早期我拿到新詞表總急著寫業(yè)務(wù)邏輯結(jié)果在亂碼和空字段上耗到半夜。后來養(yǎng)成的固定動作是先清洗、再統(tǒng)計等級分布、最后才寫查詢和服務(wù)代碼。這個順序能省下大量調(diào)試時間希望對正在評估這個方向的你也有幫助。本文還有配套的精品資源點擊獲取