简介：这份大学日本语期末考试题doc文档，面向高校日语学习者及备考期末的在校学生，用于检验和巩固日语基础知识。试题系统覆盖汉字读音、平假名与汉字转换、片假名含义、语法填空、词汇综合运用及阅读理解等模块，例如「企業」读作「きぎょう」、「にんぎょう」对应「人形」、「ピアノ」意为钢琴，并涉及助词选择、外来语理解与短文信息提取等典型考点。资源包共1个doc文件，大小约29KB，内容为完整试卷结构，含题目、分值标注与阅读篇章，便于直接打印练习或对照复习。目前已有140人学习浏览。通过逐题演练，读者可系统梳理汉字音读、假名书写、助词用法与阅读分析等薄弱环节，在词汇量、语法运用和篇章理解方面获得针对性提升，为日语后续学习打下扎实基础。
1. 一份“大学日本语期末考试题.doc”背后，藏着多少技术债
期末周前三天，某高校教务系统里突然多出一批命名高度相似的文档：“大学日本语期末考试题.doc”“大学日本语期末考试题(1).doc”“大学日本语期末考试题_最终版.doc”。任课教师想批量核对题目重复率，教务想统一归档，学生想确认复习范围——三方都盯着同一堆文件，却没人能说清里面到底有多少道题、哪些是重复的、格式为什么一打开就乱。这不是日语教学问题，是典型的非结构化文档处理问题：标题里这个 .doc 后缀，意味着二进制复合文档格式，而不是现在常见的 .docx。很多人第一反应是“用 python-docx 读一下”，结果直接翻车——python-docx 只认 OOXML，对老式 .doc 基本无能为力。这篇笔记就围绕“大学日本语期末考试题.doc”这类文件，讲清楚怎么在本地把一批 .doc 试卷稳定解析成结构化题目、怎么处理日文编码和表格混排、以及哪些参数不调就会在期末周集体翻车。适合手里有一堆旧版试卷文档、需要做题库整理或重复率检查的开发者，也适合想搞清楚 .doc 与 .docx 处理边界的熟手。
2. 先搞清楚 .doc 到底难在哪：格式、编码与结构三层拆解
2.1 为什么 python-docx 打开“大学日本语期末考试题.doc”会直接报错
python-docx 的底层依赖是 OOXML 解析，它把 .docx 当成一个 zip 包，里面是 XML 描述的文字、样式和关系。而 .doc 是微软早期的 OLE 复合文档，二进制流里混着文本、格式控制符、嵌入对象和摘要信息。你拿 python-docx 去 open 一个 .doc，它连 zip 头都找不到，抛出的异常通常是PackageNotFoundError或BadZipFile。这不是库的 bug，是格式代差。
常见做法是先用格式转换层把 .doc 转成 .docx 或纯文本，再进入解析流程。转换工具的选择直接决定后面日文假名和表格能不能保住。我一般会分两步：第一步用 LibreOffice 的无头模式做批量转换，第二步用 python-docx 或直接读 XML 做结构化抽取。为什么不一步到位用 antiword 或 catdoc？因为它们对表格和日文全角符号的支持不稳定，试卷里常见的“次の文を読んで、質問に答えなさい”这种题干一旦被拆成乱码，后面所有题目边界都会错位。
2.2 日文编码在 .doc 里的三种常见形态与检测方法
“大学日本语期末考试题.doc”这类文件，编码问题比格式问题更隐蔽。我实际处理过的样本里，日文内容通常以三种形态存在：第一种是 Shift_JIS 编码的纯文本流，常见于早期在日文 Windows 环境创建的文档；第二种是 UTF-16LE 带 BOM，多见于后来跨语言环境保存的版本；第三种是混合编码，题干是 Shift_JIS，但表格里的注音或选项被转成了 GBK 或 CP936，打开就是“文字化け”。
检测方法不能只靠 chardet 猜。chardet 对短文本和混合编码的准确率在期末周这种批量场景下不够用。我一般会写一个多级探测：先看文件头有没有 BOM，再用chardet.detect对前 64KB 做初判，最后用日文假名 Unicode 区间（平假名 U+3040–U+309F，片假名 U+30A0–U+30FF）做命中率校验。如果假名命中率低于 60%，就强制按 Shift_JIS 和 CP936 各试一次，取假名和汉字比例更合理的那个。
import chardet def detect_japanese_encoding(raw_bytes: bytes) -> str: # 先看 BOM if raw_bytes.startswith(b'\xff\xfe'): return 'utf-16-le' if raw_bytes.startswith(b'\xfe\xff'): return 'utf-16-be' # 取前 64KB 做初判，避免大文件拖慢 sample = raw_bytes[:65536] guess = chardet.detect(sample) enc = guess.get('encoding') or 'shift_jis' # 用假名命中率做二次校验 for candidate in [enc, 'shift_jis', 'cp936', 'utf-8']: try: text = sample.decode(candidate, errors='ignore') kana = sum(1 for ch in text if '\u3040' <= ch <= '\u30ff') if kana / max(len(text), 1) > 0.05: return candidate except Exception: continue return 'shift_jis' # 兜底这段代码的关键参数是errors='ignore'和假名比例阈值 0.05。errors='ignore'保证解码不中断，但会丢字符，所以只用于探测阶段，真正解析时要换成errors='replace'并记录替换位置。阈值 0.05 是我在几十份试卷样本上试出来的，低于这个值说明假名太少，可能是纯汉字题干或编码判断错了。注意：不要用errors='strict'做探测，一个字节不对就抛异常，批量处理时你会收到一屏红色报错。
2.3 试卷文档的典型结构：题干、选项、答题区怎么区分
“大学日本语期末考试题.doc”不是普通文章，它有固定的题目结构。我见过的试卷大致分三类区块：题干区（问题文）、选项区（A/B/C/D 或 ①②③④）、答题区（下划线、括号或表格）。如果直接按段落抽文本，选项会和题干混在一起，后面做去重或题库导入时根本分不开。
我的做法是先转成 .docx，再用 python-docx 按段落和表格分别遍历。段落里用正则识别题号模式，比如^[0-9]+[．.]或^[一二三四五]、，表格则单独处理，因为很多试卷把选项放在表格单元格里。识别到题号就开一个新题目对象，后续段落归入当前题目，直到下一个题号出现。表格里的内容按行合并成选项文本，保留单元格顺序。
import re from docx import Document QUESTION_PATTERN = re.compile(r'^(\d+)[．.]\s*(.+)') def parse_exam_docx(path: str): doc = Document(path) questions = [] current = None for para in doc.paragraphs: text = para.text.strip() if not text: continue m = QUESTION_PATTERN.match(text) if m: if current: questions.append(current) current = {'number': int(m.group(1)), 'stem': m.group(2), 'options': []} elif current is not None: # 选项行：以 A/B/C/D 或 ①-④ 开头 if re.match(r'^[A-DＡ-Ｄ①-④]', text): current['options'].append(text) else: current['stem'] += ' ' + text if current: questions.append(current) # 处理表格中的选项 for table in doc.tables: for row in table.rows: cells = [c.text.strip() for c in row.cells if c.text.strip()] if cells and current is not None: current['options'].extend(cells) return questions这里QUESTION_PATTERN只匹配阿拉伯数字题号，因为“大学日本语期末考试题.doc”里的大题常用“一、二、三”做分区，小题用数字。如果你处理的试卷小题也用汉字数字，需要把正则改成^([一二三四五六七八九十]+)、并单独维护题号映射。表格处理放在段落循环之后，是因为 python-docx 的doc.paragraphs不包含表格内段落，必须单独遍历doc.tables。注意：合并单元格会导致row.cells出现重复文本，去重时用dict.fromkeys保序去重，不要用 set，否则选项顺序会乱。
3. 把 .doc 批量转成可解析格式：LibreOffice 无头模式与参数调优
3.1 一条命令完成单文件转换，但批量时要注意进程隔离
LibreOffice 的无头转换命令本身很简单：
soffice --headless --convert-to docx --outdir ./converted ./raw/大学日本语期末考试题.doc这条命令在单文件上基本不会出问题，但期末周你面对的是几十上百份文件。如果直接写个 for 循环反复调 soffice，你会遇到两个坑：第一，soffice 默认会复用已有进程，第二个文件开始可能直接返回而不转换；第二，并发调用时用户配置目录冲突，报“另一个实例正在运行”。解决办法是给每个转换进程指定独立的-env:UserInstallation目录，并且串行执行，不要图快开多进程。
#!/bin/bash RAW_DIR="./raw" OUT_DIR="./converted" mkdir -p "$OUT_DIR" i=0 for f in "$RAW_DIR"/*.doc; do i=$((i+1)) profile="file:///tmp/lo_profile_$i" soffice --headless \ -env:UserInstallation="$profile" \ --convert-to docx \ --outdir "$OUT_DIR" \ "$f" done-env:UserInstallation后面的路径必须是 file:// 开头的 URI，写成普通路径在某些版本上会被忽略。串行执行虽然慢，但稳定。如果你有几百份文件，可以按 4 到 6 个一批做有限并发，每批之间 sleep 1 秒，给 LibreOffice 留出释放 profile 的时间。我一般会在脚本里加一个转换结果校验：检查输出 .docx 是否存在且大小大于 0，否则记录到失败列表，后续单独重试。
3.2 转换参数怎么设：字体、编码与表格保留的取舍
LibreOffice 转换时默认会做字体替换，如果原 .doc 里用了日文字体而系统没装，转换后的 .docx 里假名可能变成方框。这不是编码问题，是字体缺失。处理办法是在转换前确认系统里有日文字体，比如 Noto Sans CJK JP 或 Takao 系列。没有的话，转换参数里加--convert-to docx:"MS Word 2007 XML"并不能解决字体替换，只能靠安装字体。
另一个参数是--infilter，它可以在转换前指定输入过滤器。对于“大学日本语期末考试题.doc”这种老式 .doc，一般不需要手动指定，LibreOffice 会自动识别。但如果遇到转换后表格全变成纯文本，可以试--infilter="MS Word 97"强制走旧版解析路径。编码方面，LibreOffice 会尽量保留原文档的字符集，转换后 .docx 内部是 UTF-8，所以日文不会丢，前提是字体和编码探测都正确。
提示：转换前先拿一份样本文件手动跑一遍，用 LibreOffice 打开转换后的 .docx，确认假名、表格和题号都在。批量脚本一旦跑起来，中间某个文件转换失败不会中断整个循环，但失败文件会被静默跳过，所以一定要加日志。
3.3 转换失败时的排查顺序：从文件头到 profile 目录
转换失败的现象通常是：命令返回 0 但输出目录没有文件，或者直接报错退出。排查顺序我一般按这个来：第一，用file命令看原文件头，确认它真的是 OLE 复合文档而不是改了后缀的 RTF 或 HTML。第二，检查-env:UserInstallation目录是否可写，/tmp 在某些容器环境里可能被挂载为 noexec。第三，看 LibreOffice 版本，太老的版本对某些 .doc 变体支持不好，但不要盲目升级，先确认失败文件是否是个例。第四，如果只有部分文件失败，把失败文件单独拿出来，用soffice --headless --convert-to txt试纯文本转换，能出文本说明格式可读，问题在 docx 转换的样式层。
我遇到过一种情况：文件头显示是 OLE，但内部流被加密或损坏，LibreOffice 直接卡住不返回。这种文件不要硬转，先用antiword或catdoc试着抽文本，能抽多少算多少，抽不出来就标记为人工处理。期末周时间紧，不要在单个坏文件上耗超过 5 分钟。
4. 从转换后的文档里抽题目：正则、表格与日文分词的配合
4.1 题号识别的正则怎么写才不漏不误
题号识别是整条流水线的关键。漏一个题号，后面题目边界全错；误判一个，会把题干里的数字当成新题。我的经验是分两层：第一层匹配行首的题号模式，第二层用上下文校验。比如“大学日本语期末考试题.doc”里常见“1．次の文の下線部の読み方を答えなさい。”，行首是数字加全角句点。但题干里也可能出现“1990年代”这种数字开头，如果正则写成^\d+就会误判。
改进后的正则是^(\d{1,2})[．.、]\s*\S，限制题号是 1 到 2 位数字，后面必须跟全角句点、半角句点或顿号，再跟非空白字符。这样“1990年代”因为数字是 4 位且后面没有句点，不会被匹配。另外，题号后面如果直接跟空格再跟文字，也要考虑，所以\s*不能省。对于汉字题号“一、二、三”，单独用^([一二三四五六七八九十]+)、匹配，并且只在文档前 20% 区域生效，因为大题号通常出现在开头。
import re ARABIC_Q = re.compile(r'^(\d{1,2})[．.、]\s*(\S.*)') CHINESE_Q = re.compile(r'^([一二三四五六七八九十]+)、\s*(\S.*)') def is_question_start(text: str, position_ratio: float): m = ARABIC_Q.match(text) if m: return ('arabic', int(m.group(1)), m.group(2)) if position_ratio < 0.2: m2 = CHINESE_Q.match(text) if m2: return ('chinese', m2.group(1), m2.group(2)) return Noneposition_ratio是当前段落索引除以总段落数，用来限制汉字题号只在前 20% 出现。这个阈值可以根据实际试卷调整，如果大题号出现在中间，就放宽到 0.5。注意：不要把re.match换成re.search，否则题干中间的“1．”也会被当成题号。
4.2 表格里的选项怎么按行合并成完整选项文本
试卷里的选项经常放在表格里，一行四个单元格，对应 A/B/C/D。python-docx 读表格时，row.cells返回的是单元格对象列表，但合并单元格会导致同一个单元格对象重复出现。我的处理方式是：先按行取cells，用dict.fromkeys去重并保持顺序，然后把每个单元格文本 strip 后拼成选项列表。如果一行只有一个单元格，说明是跨列合并的题干或答题区，单独处理。
def extract_table_options(table): options = [] for row in table.rows: cells = [c.text.strip() for c in row.cells] # 保序去重，处理合并单元格 seen = list(dict.fromkeys(cells)) seen = [c for c in seen if c] if len(seen) >= 2: options.extend(seen) elif len(seen) == 1: # 单单元格行，可能是题干或答题区，跳过或归入题干 pass return options这里len(seen) >= 2才认为是选项行，因为单个单元格的行大概率是题干或分隔行。如果你处理的试卷选项是竖排的，每行一个选项，那这个逻辑要改成按列遍历。参数上，dict.fromkeys比 set 多一步保序，在 Python 3.7+ 上字典有序，所以可以直接用。
4.3 日文题干里的全角空格与标点归一化
日文文本里全角空格 U+3000 和半角空格混用很常见，标点也有全角半角两套。如果不归一化，后面做重复率比对时“次の文を読んで”和“次の文を読んで ”会被当成不同字符串。归一化规则我一般定三条：全角空格转半角空格，连续多个空格合并成一个，全角标点保留但统一逗号句号的全角形式。不要把所有全角都转半角，因为日文里全角假名和汉字不能动，只处理空格和标点。
def normalize_japanese(text: str) -> str: # 全角空格转半角 text = text.replace('\u3000', ' ') # 连续空格合并 text = re.sub(r' +', ' ', text) # 全角逗号句号统一（保留全角形式，只去重复） text = text.replace('．．．', '…') text = text.replace('。。', '。') return text.strip()\u3000是日文全角空格，直接 replace 比用正则快。．．．转…是为了处理省略号的不同写法，试卷里常见。注意：不要用unicodedata.normalize('NFKC', text)做全局归一化，它会把全角假名转成半角，日文文本会变得不可读。
5. 避坑与排查：期末周批量处理时最容易翻车的 5 个点
5.1 现象：转换后的 .docx 里假名全变成问号
原因：原 .doc 是 Shift_JIS 编码，LibreOffice 转换时按默认编码解析，没有正确识别。解决：在转换前先用 2.2 节的探测脚本确认编码，如果确认是 Shift_JIS，可以在 LibreOffice 转换参数里加--infilter="MS Word 97:UTF-8"强制指定，但更稳的做法是先用 Python 把 .doc 里的文本流按 Shift_JIS 抽出来，再走纯文本解析路径。注意：不要直接改文件后缀，改后缀不解决编码。
5.2 现象：题号识别把“1990年代”当成第 1990 题
原因：正则没有限制题号位数和后续标点。解决：用 4.1 节的\d{1,2}加标点约束，并且对匹配到的题号做连续性校验——如果新题号和上一个题号差值大于 5，就标记为可疑，人工确认。这个校验能拦住大部分误判。
5.3 现象：表格选项顺序错乱，A 选项跑到 D 后面
原因：合并单元格导致row.cells重复，去重时用了 set 而不是保序去重。解决：用dict.fromkeys保序去重，并且在拼接选项前按单元格的_tc元素顺序排序，不要依赖row.cells的返回顺序。如果还是乱，直接读 XML 里w:tc的顺序。
5.4 现象：批量转换到第 37 个文件时 LibreOffice 卡死
原因：profile 目录没有隔离，或者 /tmp 空间被写满。解决：每个文件用独立 profile 目录，转换完成后删除 profile；监控 /tmp 剩余空间，低于 500MB 就暂停。另外，LibreOffice 转换大文件时内存占用会涨，如果文件超过 50MB，建议拆分成多个小文件再转。
5.5 现象：日文题干里的注音（ルビ）丢失
原因：.doc 里的注音是以特殊字段存储的，LibreOffice 转 .docx 时可能丢弃。解决：如果注音对题目理解很重要，不要走 LibreOffice 转换，直接用antiword -m UTF-8.txt抽文本，注音会以括号形式保留。但 antiword 对表格支持差，所以只对含注音的题目单独处理。这是一个取舍：要注音就丢表格，要表格就丢注音，看你的下游用途。
6. 进阶：把抽出来的题目做成可检索题库，以及一个我常犯的错
题目抽出来只是第一步，真正有价值的是能按关键词、题号、重复率检索。我一般会把解析结果存成 JSON Lines，每行一个题目对象，包含number、stem、options、source_file和normalized_stem。然后用 SQLite 建一个 FTS5 全文索引表，对normalized_stem做分词检索。日文分词不要用 jieba，它面向中文，日文假名和汉字混合时切分很糟。可以用fugashi或janome，如果不想装额外依赖，就按字符 bigram 建索引，召回率够用，精确率靠后续过滤。
import sqlite3, json def build_index(jsonl_path: str, db_path: str): conn = sqlite3.connect(db_path) conn.execute('CREATE VIRTUAL TABLE IF NOT EXISTS questions USING fts5(stem, options, source_file)') with open(jsonl_path, 'r', encoding='utf-8') as f: for line in f: obj = json.loads(line) conn.execute( 'INSERT INTO questions(stem, options, source_file) VALUES (?, ?, ?)', (obj['normalized_stem'], ' '.join(obj['options']), obj['source_file']) ) conn.commit() conn.close()建完索引后，查重复率就是SELECT stem, COUNT(*) FROM questions GROUP BY normalized_stem HAVING COUNT(*) > 1。注意：FTS5 默认对日文按空格分词，日文没有空格，所以要么在入库前把题干按 bigram 拆成空格分隔的 token，要么用tokenize='unicode61'并接受召回率下降。我一般选 bigram，虽然索引变大，但期末周查重时不会漏。
最后说一个我常犯的错：每次处理新一批“大学日本语期末考试题.doc”，我都想直接上全自动流水线，结果总在编码探测那一步翻车。后来我养成了一个习惯——先拿 3 份样本文件手动跑完整条链路，确认题号、选项、假名都对了，再写批量脚本。这 10 分钟的手动验证，能省掉后面两小时的排查。希望帮到你。
本文还有配套的精品资源，点击获取
