簡(jiǎn)介德國(guó)民法典中文譯本文檔適合法律專業(yè)學(xué)生、法學(xué)研究者以及需要系統(tǒng)查閱德國(guó)法條文的實(shí)務(wù)人士使用。壓縮包內(nèi)共有1個(gè)doc文件體積約368KB內(nèi)容為1896年公布、1998年6月29日最近一次修改的德國(guó)民法典全文條文按編章結(jié)構(gòu)編排。正文從總則部分的自然人制度展開(kāi)涵蓋姓名權(quán)、住所與成年年齡社團(tuán)法人設(shè)立、董事代表權(quán)以及物權(quán)、債權(quán)、合同、侵權(quán)行為、繼承等各大板塊具體涉及權(quán)利能力的開(kāi)始、物權(quán)的取得與保護(hù)、債權(quán)的契約或繼承取得、合同意思表示規(guī)則、侵權(quán)損害賠償、遺囑繼承與法定繼承等完整法律條文。該doc文本便于離線檢索與直接引用可作為比較法研究、法律史梳理或德國(guó)法入門學(xué)習(xí)的基礎(chǔ)資料目前已有113人學(xué)習(xí)/下載。1. 拿到《德國(guó)民法典全文.doc》之后別急著雙擊打開(kāi)一個(gè)名為《德國(guó)民法典全文.doc》的文件拿到的第一時(shí)間我只做一件事先查它的格式和編碼而不是雙擊。這不是矯情。我接過(guò)不少這類“法律文獻(xiàn)存檔doc”的活十次里有三次雙擊后是滿屏亂碼兩次用腳本提取時(shí)發(fā)現(xiàn)只讀出了半部條文剩下的全卡在文檔內(nèi)部結(jié)構(gòu)里。問(wèn)題從來(lái)不在正文本身而在三處文件到底是老版 Word 二進(jìn)制 doc、改擴(kuò)展名的 docx、還是純文本偽裝正文用了什么字符集轉(zhuǎn)換過(guò)程中條款結(jié)構(gòu)能不能保住。這篇筆記就按這三步走先識(shí)別文件真身再選提取路線最后處理德文特殊字符和結(jié)構(gòu)。適合接了文檔數(shù)字化任務(wù)、想把舊 doc 內(nèi)容導(dǎo)進(jìn)語(yǔ)料庫(kù)或檢索系統(tǒng)的人。2. 先查家底這個(gè) .doc 到底是哪種 .doc用文件頭識(shí)別再選工具鏈擴(kuò)展名是 .doc但這個(gè)后綴在真實(shí)環(huán)境里掩蓋了至少三種完全不同的文件結(jié)構(gòu)。選錯(cuò)工具鏈的代價(jià)不是白跑一次腳本而是你對(duì)著亂碼和丟行數(shù)據(jù)反復(fù)翻車最后才發(fā)現(xiàn)第一步就走錯(cuò)了。2.1 同名 .doc 的三種內(nèi)核二進(jìn)制 OLE、偽裝的 docx、純文本老版 Word 97-2003 保存的 doc 文件本質(zhì)上是一個(gè) OLE2 復(fù)合文檔十六進(jìn)制文件頭固定是D0 CF 11 E0 A1 B1 1A E1。這種文件內(nèi)部像一個(gè)微型文件系統(tǒng)正文存放在名為 WordDocument 的流里旁邊還要帶上 Table 流、Data 流配合解析段落和字符格式。Word 程序打開(kāi)時(shí)不是“讀全文”而是按目錄結(jié)構(gòu)拼接這些流所以民間腳本想直接讀這種 doc十有八九會(huì)漏掉內(nèi)容。第二種是 docx 改擴(kuò)展名偽裝成 doc。docx 本質(zhì)是一個(gè) ZIP 壓縮包文件頭是50 4B 03 04正文是壓縮后的 XML。有人從網(wǎng)盤下載了 docx手滑改名為 doc或者某些舊系統(tǒng)強(qiáng)制要求 .doc 后綴于是文件擴(kuò)展名和真實(shí)格式對(duì)不上。處理這種文件可以用解壓工具直接解開(kāi)也可以用 python-docx 讀完全不用走老 doc 的解析路線。第三種是純文本直接偽裝成 doc。這類文件沒(méi)有任何 Word 結(jié)構(gòu)可能是一段帶編碼的 UTF-8 或 Windows-1252 文本卻被存成了 .doc 后綴。它沒(méi)有固定的文件頭魔數(shù)用編輯器打開(kāi)能看到可讀的文字。判斷它是文本還是 RTF 偽裝的 doc只要看文件開(kāi)頭是不是{\rtf這個(gè)方法便宜有效。為什么要先分清這三種因?yàn)楹罄m(xù)的工具鏈完全不同python-docx 只能讀 docxLibreOffice 能通吃但轉(zhuǎn)換慢還吃資源純文本型直接做編碼還原就行。不識(shí)別就動(dòng)手等于閉著眼睛選路。2.2 用 file 和 xxd 在轉(zhuǎn)碼前確認(rèn)文件頭在 Linux 或 macOS 上最快的方式是file命令直接讀出類型和編碼信息再用xxd看前 16 字節(jié)做二次確認(rèn)。Windows 上可以用 Git Bash 或 WSL 跑同樣命令。file --mime 德國(guó)民法典全文.doc xxd 德國(guó)民法典全文.doc | head -n 1--mime參數(shù)會(huì)讓 file 輸出完整的 MIME 類型與字符集信息xxd輸出十六進(jìn)制視圖拿第一行和下面的表對(duì)照判斷。如果系統(tǒng)里沒(méi)有 xxd可以用od -A x -t x1z -v 德國(guó)民法典全文.doc | head -n 1代替效果一樣。十六進(jìn)制文件頭實(shí)際格式后續(xù)路線d0 cf 11 e0 a1 b1 1a e1OLE2 復(fù)合文檔老版二進(jìn)制 docLibreOffice 或 antiword50 4b 03 04ZIP 容器docx 改名或偽裝python-docx 或 LibreOffice無(wú)明顯魔數(shù)但可見(jiàn) UTF-8 文本純文本偽裝成 doc直接做編碼檢測(cè)與還原7b 5c 72 74 66RTF 富文本偽裝成 doc用 pandoc 或 LibreOffice 轉(zhuǎn)換需要注意file 輸出里的“Composite Document File v2 Document”就是指 OLE2 老 doc這是它的歷史名稱別看到不認(rèn)識(shí)就慌。encoding 字段如果顯示us-ascii、utf-8、iso-8859-1那基本可以判斷是文本型偽裝文件。2.3 識(shí)別結(jié)果決定工具鏈LibreOffice、python-docx 還是 iconv拿到識(shí)別結(jié)果后我一般按三條路線分配工具。老版 OLE doc 優(yōu)先交給 LibreOffice 無(wú)頭模式導(dǎo)出純文本一次過(guò)docx 偽裝就交給 python-docx按段落和表格精確提取純文本型則直接交給編碼檢測(cè)工具decode 完再寫回 UTF-8。路線選擇決定你后面能不能保住結(jié)構(gòu)。還要提醒一點(diǎn)識(shí)別時(shí)要連帶看文件大小和字符集信息。純文本型的民法典全文通常在 1MB 以下老 doc 因?yàn)橛袃?nèi)嵌結(jié)構(gòu)會(huì)更大但有限docx 偽裝形態(tài)則能直接被unzip -l列出來(lái)。把這些信息匯總能幫你判斷這份文檔是不是被反復(fù)轉(zhuǎn)換過(guò)。識(shí)別結(jié)果首選工具備選工具消耗老版 OLE docLibreOffice headlessantiword中需裝 LibreOfficedocx 偽裝python-docxLibreOffice輕量純文本偽裝chardet iconv編輯器批量另存極輕識(shí)別這一步最快只需要兩分鐘卻能避免后面幾小時(shí)的踩坑。我習(xí)慣把文件頭信息記成一個(gè)文本備注隨原始文件一起留存方便交接給下一個(gè)人時(shí)不用重新猜。3. 把民法典全文提取成文本三條可復(fù)現(xiàn)的路線格式認(rèn)清后下一步就是把正文“請(qǐng)”出文件。這里沒(méi)有萬(wàn)能命令因?yàn)椴煌袷綄?duì)應(yīng)的提取機(jī)制完全不同。下面三條路線是實(shí)踐中跑得最穩(wěn)的組合按前面識(shí)別到的類型選一條按步驟執(zhí)行即可。3.1 路線A用 LibreOffice 無(wú)頭模式轉(zhuǎn)出純文本LibreOffice 的 headless 模式可以不開(kāi)圖形界面直接轉(zhuǎn)換文檔對(duì)老版 OLE doc 的兼容性是目前開(kāi)源方案里最穩(wěn)妥的。命令如下soffice --headless --convert-to txt:Text (encoded):UTF8 --outdir ./out 德國(guó)民法典全文.doc轉(zhuǎn)換完成后去./out目錄看同名.txt文件。--headless表示不啟動(dòng) GUI--convert-to指定輸出格式txt:Text (encoded):UTF8里的encoded子過(guò)濾器允許你直接指定輸出編碼UTF8 就是寫入 UTF-8 文本。--outdir指定輸出目錄避免生成到當(dāng)前目錄污染源文件位置。我一般不省略編碼參數(shù)因?yàn)槟J(rèn)值未必是 UTF-8。轉(zhuǎn)換執(zhí)行完后立刻跑一條驗(yàn)證file --mime out/德國(guó)民法典全文.txt wc -l out/德國(guó)民法典全文.txtwc -l看行數(shù)是快速判斷轉(zhuǎn)換是否完整的辦法。如果行數(shù)只有幾十行很可能內(nèi)容被壓到了一行里說(shuō)明段落符沒(méi)有正確映射需要看原始 doc 的換行邏輯。如果文件頭顯示us-ascii且原文是德文說(shuō)明字符集被降級(jí)有字符被替換要回到編碼檢查。LibreOffice 轉(zhuǎn)換的優(yōu)點(diǎn)是省心缺點(diǎn)是對(duì)帶復(fù)雜樣式的 doc 處理時(shí)間稍長(zhǎng)。民法典這類純條文型文檔屬于簡(jiǎn)單排版轉(zhuǎn)換質(zhì)量通常很高。3.2 路線Bdocx 用 python-docx老版 doc 交給 antiword如果識(shí)別結(jié)果是 docx 偽裝直接用 python-docx 讀正文from docx import Document doc Document(德國(guó)民法典全文.doc) with open(bgb_paragraphs.txt, w, encodingutf-8) as f: for p in doc.paragraphs: f.write(p.text \n) for table in doc.tables: for row in table.rows: for cell in row.cells: f.write(cell.text \n)邏輯說(shuō)明docx 的正文不僅存在于 paragraphs 里還可能散落在表格中所以循環(huán)里同時(shí)處理了 tables。如果只遍歷 paragraphs條文里嵌在表格內(nèi)的內(nèi)容就會(huì)靜默丟失這是 python-docx 最常見(jiàn)的翻車點(diǎn)。寫入時(shí)用了encodingutf-8避免 Windows 默認(rèn)的 GBK 編碼污染文件。老版 OLE doc 不推薦用 Python 直接解析WordDocument 流里的二進(jìn)制格式是出了名的難啃?，F(xiàn)實(shí)中我通常直接調(diào)用 antiwordantiword -m UTF-8.txt 德國(guó)民法典全文.doc bgb_antiword.txt-m UTF-8.txt指定字符映射文件用于把文檔內(nèi)部的編碼映射成 UTF-8 輸出。注意 antiword 對(duì)老 doc 的段落符默認(rèn)按\r輸出后面清洗時(shí)要統(tǒng)一換行符。如果 antiword 報(bào)錯(cuò)說(shuō)無(wú)法識(shí)別的文檔版本那這份 doc 的兼容性可能有問(wèn)題轉(zhuǎn)頭走 LibreOffice 路線更穩(wěn)。3.3 路線C文本型 doc 先用 chardet 檢測(cè)編碼再還原純文本偽裝型 doc 的處理核心不是格式解析而是編碼檢測(cè)。德文文本常見(jiàn)編碼是 Windows-1252、ISO-8859-15 和 UTF-8其中 Windows-1252 與 ISO-8859-15 都兼容 ASCII但彼此存在小范圍差異選錯(cuò)會(huì)造成少量符號(hào)錯(cuò)亂。import chardet with open(德國(guó)民法典全文.doc, rb) as f: raw f.read(5000) result chardet.detect(raw) print(檢測(cè)編碼:, result[encoding], 置信度:, result[confidence]) with open(德國(guó)民法典全文.doc, rb) as f: raw_all f.read() text raw_all.decode(result[encoding], errorsreplace) with open(bgb_clean.txt, w, encodingutf-8) as f: f.write(text)參數(shù)說(shuō)明f.read(5000)用前 5000 字節(jié)做檢測(cè)速度更快errorsreplace可以把無(wú)法解碼的字節(jié)替換成保證腳本不中斷。但這里要特別指出errorsreplace是“后悔藥”只適合應(yīng)急不能作為最終交付質(zhì)量。檢測(cè)到編碼后先用raw_all.decode(...)解碼再以 UTF-8 寫回完成統(tǒng)一編碼。如果chardet報(bào)出ISO-8859-1而文本里包含歐元符號(hào)€要考慮實(shí)際是 Windows-1252因?yàn)?ISO-8859-1 標(biāo)準(zhǔn)中 0x80 處沒(méi)有定義字符Windows-1252 則把 0x80 定義為 €。處理德文文檔我默認(rèn)把 ISO-8859-1 視為 Windows-1252 處理能少踩不少坑。4. 德文特殊字符與條款結(jié)構(gòu)提取后最該檢查的兩件事文本提取出來(lái)只是第一步德文文檔的字符集和條文結(jié)構(gòu)會(huì)在這時(shí)候開(kāi)始考驗(yàn)?zāi)恪?、?、ü、?、?引號(hào)“、§ 符號(hào)任何一個(gè)在編碼轉(zhuǎn)換里翻車都會(huì)讓你得到的文本不堪一用。這一章講兩個(gè)最該檢查的點(diǎn)。4.1 ? ? ü ? 與 ?引號(hào)“的編碼陷阱從亂碼反推原編碼德文里最頻繁出現(xiàn)的特殊字符是 ?、?、ü、? 和帶音調(diào)的變?cè)暨@些都是非 ASCII 字符。當(dāng)一份 doc 的中轉(zhuǎn)文本出現(xiàn)?¤、??、??這樣的雙字符亂碼基本可以斷定原字節(jié)是 UTF-8 編碼卻被按 Windows-1252 或 Latin-1 解碼了。這個(gè)現(xiàn)象在實(shí)際操作中極其常見(jiàn)我至少見(jiàn)過(guò)五六回。修復(fù)這種兩輪錯(cuò)位要沿著亂碼方向反推回去with open(bgb_garbled.txt, encodingutf-8) as f: garbled f.read() raw_bytes garbled.encode(cp1252, errorssurrogateescape) fixed_text raw_bytes.decode(utf-8, errorsreplace) with open(bgb_fixed.txt, w, encodingutf-8) as f: f.write(fixed_text)邏輯說(shuō)明第一步讀入的是“被錯(cuò)誤解碼后保存”的文本它本身是合法的 UTF-8。第二步把文本重新編碼回cp1252這一步得到的是最初被誤讀的原始字節(jié)序列。第三步用utf-8解碼這些原始字節(jié)才拿到真正的德文文本。整個(gè)修復(fù)過(guò)程跟解套一樣要一層一層剝。如果解碼后某個(gè)字符仍然是?說(shuō)明源字節(jié)在某個(gè)環(huán)節(jié)已經(jīng)被替換成了 ASCII 問(wèn)號(hào)原始信息已經(jīng)不可逆。這時(shí)候只能回到最開(kāi)始的 doc 文件重新提取這也就是我反復(fù)強(qiáng)調(diào)保留原始文件的原因——任何一步處理都在消耗原始信息處理前最好復(fù)制出一個(gè)備份把它當(dāng)原始膠片對(duì)待。德文引號(hào)也容易出問(wèn)題。德語(yǔ)使用 ?“ 作為上位引號(hào)Windows-1252 里分別是 0x84 和 0x93而 UTF-8 里是三個(gè)字節(jié)。轉(zhuǎn)換后如果引號(hào)變成a€?或類似奇怪形態(tài)說(shuō)明又發(fā)生了編碼錯(cuò)位。統(tǒng)一處理方法是先在文本里搜引號(hào)位看它是不是成對(duì)出現(xiàn)再?zèng)Q定是否手動(dòng)替換。4.2 條款編號(hào)和段落縮進(jìn)清洗時(shí)保留可讀結(jié)構(gòu)的三個(gè)正則民法典按條編號(hào)原文中通常用 § 后接數(shù)字表示條目下面再分段落。這部分結(jié)構(gòu)在純文本轉(zhuǎn)換中容易丟失常見(jiàn)表現(xiàn)是“所有內(nèi)容連成一大塊”或“大量空行夾在中間”。我的習(xí)慣是清洗時(shí)不過(guò)度加工只做三步import re with open(bgb_clean.txt, encodingutf-8) as f: text f.read() text re.sub(r\r\n?, \n, text) # 統(tǒng)一換行符 text re.sub(r[ \t]\n, \n, text) # 去掉行尾空格 text re.sub(r\n{3,}, \n\n, text) # 壓縮多余空行 with open(bgb_normalized.txt, w, encodingutf-8) as f: f.write(text)第一條正則把\r\n和單獨(dú)的\r統(tǒng)一成\n解決 Windows 與 Unix 換行混雜問(wèn)題。第二條刪除每行末尾的殘留空格和制表符避免后續(xù)檢索時(shí)文本不一致。第三條把連續(xù)三個(gè)以上換行壓縮成兩個(gè)保留段落間隙但不強(qiáng)行歸并段落。為什么不在這里把整份文檔切成結(jié)構(gòu)化字段因?yàn)榉晌谋镜目s進(jìn)和分段背后有語(yǔ)義盲目用正則切分會(huì)把“款”和“項(xiàng)”的層級(jí)切碎。我們的目標(biāo)是可讀、可檢索的文本不是數(shù)據(jù)庫(kù)表。過(guò)度清洗反而破壞原文信息。要結(jié)構(gòu)化應(yīng)該等文本穩(wěn)定后再用專門的解析邏輯處理而不是在清洗階段做。5. 避坑處理這個(gè)文檔最常見(jiàn)的 4 個(gè)翻車現(xiàn)場(chǎng)這一章專門記錄我在處理民法典 doc 時(shí)遇到的典型問(wèn)題每一條都按“現(xiàn)象、原因、解決”展開(kāi)。你在復(fù)現(xiàn)流程時(shí)如果碰到相似癥狀直接對(duì)號(hào)入座。5.1 雙擊全是黑塊現(xiàn)象用 WPS 或舊版 Word 打開(kāi)文件正文區(qū)域顯示成方塊或亂碼滑鼠標(biāo)滾輪也沒(méi)有好轉(zhuǎn)。原因老版 OLE doc 內(nèi)部帶有字體表如果文檔聲明了當(dāng)前系統(tǒng)不存在的字體比如某個(gè)版本專用轉(zhuǎn)碼字體渲染層就會(huì)顯示占位塊。更常見(jiàn)的是文檔本體其實(shí)是 docx 改名但個(gè)別軟件對(duì)它做了錯(cuò)誤的格式探測(cè)。解決不再用編輯器硬開(kāi)改用 LibreOffice 無(wú)頭轉(zhuǎn)換輸出純文本。如果確認(rèn)是字體問(wèn)題可以在轉(zhuǎn)換前用fc-list :langde檢查德文字體是否完整再為 LibreOffice 安裝 DejaVu 或 Liberation 字體套裝這類開(kāi)源字體對(duì)德語(yǔ)變?cè)糁С滞晟啤?.2 腳本只提取了半部條文現(xiàn)象用自寫 Python 腳本讀取老版 doc正文只出來(lái)前幾百行后面的內(nèi)容消失了。用記事本打開(kāi)輸出文件發(fā)現(xiàn)結(jié)尾是正常文本半截?cái)嚅_(kāi)。原因老版 OLE doc 的正文可能分布在多個(gè)流里主文本流讀完后還有表格流或補(bǔ)充流的內(nèi)容未拼接。簡(jiǎn)單腳本通常只解析了主文本流后面的部分就被丟掉了。解決不再用自寫解析腳本讀老 doc交給 antiword 或 LibreOffice。這兩個(gè)工具實(shí)現(xiàn)了 Word 的流拼接邏輯能拿到完整正文。如果庫(kù)里有textract且環(huán)境允許也可以嘗試但它依賴較多系統(tǒng)包不如前兩者可靠。5.3 德文字母變成 ?¤現(xiàn)象輸出文本里 ? 顯示成 ?¤? 顯示成 ??整篇德文像被“外星文字符”替換了一遍。原因這是典型的雙重編碼錯(cuò)位。源文件里的 ? 是 UTF-8 編碼某個(gè)環(huán)節(jié)把它按 Windows-1252 解碼再保存成 UTF-8于是原本的單字符變成了兩個(gè)字符的亂碼組合。解決用 4.1 節(jié)的反推腳本先encode(cp1252, errorssurrogateescape)還原原始字節(jié)再decode(utf-8)恢復(fù)文本。如果腳本報(bào)了 UnicodeEncodeError說(shuō)明亂碼文本里混入了無(wú)法映射的字符考慮改用errorsbackslashreplace定位具體位置再?zèng)Q定是否保留那個(gè)字符。5.4 \r 段落符讓按行切分失效現(xiàn)象用for line in f.readlines()遍歷文本結(jié)果整篇內(nèi)容粘成一行連條目的換行全部失效。原因antiword 以及部分轉(zhuǎn)換工具對(duì)老版 doc 的段落符默認(rèn)輸出\r而不是\n。Python 的readlines()只認(rèn)\n于是每條文本都算在同一行里。解決讀取后先用text.replace(\r\n, \n).replace(\r, \n)做一次全局歸一化。把這一步放在清洗流程的最前面后面所有按行操作才能正確工作。這是一個(gè)很小但能影響全局的細(xì)節(jié)順序錯(cuò)了后面所有正則都可能掉進(jìn)“一行文本”的黑匣子里。6. 進(jìn)階把民法典全文導(dǎo)進(jìn) FTS5 做本地全文檢索文本清洗到可讀狀態(tài)后一次更實(shí)用的操作是把全文導(dǎo)入 SQLite 的 FTS5 虛擬表做成一個(gè)可以秒查的本地語(yǔ)料庫(kù)。這樣你就不用在幾百 KB 的文本里反復(fù)搜索而是用 SQL 做全文匹配、片段高亮。這會(huì)直接提升后續(xù)使用體驗(yàn)。先確認(rèn)當(dāng)前 Python 的 sqlite3 支持 FTS5import sqlite3 conn sqlite3.connect(bgb.db) try: conn.execute(CREATE VIRTUAL TABLE bgb USING fts5(content, tokenizeunicode61)) print(FTS5 supported) except sqlite3.OperationalError as e: print(FTS5 unavailable:, e)tokenizeunicode61讓分詞器按 Unicode 字母識(shí)別詞德語(yǔ)的變?cè)?? ? ü ? 都是字母會(huì)被正確切分成可檢索的 token。這一步如果直接建表成功說(shuō)明環(huán)境支持 FTS5可以繼續(xù)往下走。接下來(lái)把清洗好的文本按條款分節(jié)插入。我習(xí)慣用關(guān)鍵詞 § 配合數(shù)字作為分節(jié)邊界import sqlite3, re conn sqlite3.connect(bgb.db) conn.execute(CREATE VIRTUAL TABLE IF NOT EXISTS bgb USING fts5(content, tokenizeunicode61)) text open(bgb_normalized.txt, encodingutf-8).read() sections re.split(r(?§\s?\d), text) for sec in sections: sec sec.strip() if sec: conn.execute(INSERT INTO bgb(content) VALUES (?), (sec,)) conn.commit() print(Inserted sections:, len(sections))邏輯說(shuō)明正則用(?§\s?\d)做零寬斷言在“§ 數(shù)字”前切開(kāi)把每條條文或條款分節(jié)存為一行保證不丟內(nèi)容。插入后提交事務(wù)之后的檢索就能精確到節(jié)。查詢示范SELECT snippet(bgb) FROM bgb WHERE content MATCH Gericht; SELECT count(*) FROM bgb WHERE content MATCH Vertrag;snippet返回命中的上下文片段避免了整條長(zhǎng)文本刷屏count(*)幫你確認(rèn)命中次數(shù)。驗(yàn)證提取質(zhì)量時(shí)我會(huì)先檢幾個(gè)德文常用詞再檢一個(gè)帶變?cè)舻脑~例如Gl?ubiger確認(rèn)分詞器沒(méi)有把變?cè)艚財(cái)唷Ｗ鐾赀@套流程我用下來(lái)的體會(huì)是原始 doc 永遠(yuǎn)留底轉(zhuǎn)換出的文本按日期或編碼版本分開(kāi)命名別覆蓋也不要把來(lái)源和清洗步驟寫丟。一個(gè)好的文本處理習(xí)慣能幫你省掉大量事后補(bǔ)救的時(shí)間。希望這套路線對(duì)你處理同類文檔也有幫助。本文還有配套的精品資源點(diǎn)擊獲取