簡介面向需要把純文本數(shù)據(jù)整理為結(jié)構(gòu)化文檔的編程學(xué)習(xí)者與數(shù)據(jù)處理人員這份小工具提供從 txt 到 xml 的轉(zhuǎn)換實現(xiàn)重點解決 txt 缺乏元素層級、屬性描述和跨系統(tǒng)交換能力的問題。壓縮包共 37 個文件、約 65KB以 C# 源碼、WPF 界面文件、項目解決方案與工程配置以及可執(zhí)行程序為主并附少量資源、清單和設(shè)置文件構(gòu)成一個可查看、編譯或運(yùn)行的完整小程序項目。已有 3445 人學(xué)習(xí)下載說明其在文本轉(zhuǎn) XML 這類基礎(chǔ)數(shù)據(jù)加工場景中具有一定參考面。讀者可從中了解 txt 行列數(shù)據(jù)的讀取與解析、XML 元素和屬性的映射、文件 I/O、異常處理與調(diào)試測試思路并依據(jù)自身數(shù)據(jù)布局調(diào)整轉(zhuǎn)換邏輯對不熟悉 XML 的讀者也能借這個小項目熟悉結(jié)構(gòu)化數(shù)據(jù)組織方式與不同系統(tǒng)間的數(shù)據(jù)交換流程。1. txt 轉(zhuǎn) xml 到底在轉(zhuǎn)什么先認(rèn)清三種輸入形態(tài)某公司的巡檢數(shù)據(jù)一線用記事本按「一行一條、制表符分隔」記下來十年攢了幾萬份下游報表系統(tǒng)是早年采購的接口只接受 xml。中間這道轉(zhuǎn)換每天早上要人手跑一遍直到有人寫了這個小工具。txt 數(shù)據(jù)轉(zhuǎn)換為 xml 數(shù)據(jù)難點從來不在「轉(zhuǎn)」這個動作而在于 txt 根本沒有 schema 可言——同一批文件里字段個數(shù)、分隔符、空值寫法可能每份都不一樣。工具的職責(zé)其實是替你把「格式約定」這件事釘死解析行與列映射成節(jié)點路徑再寫出帶聲明、帶縮進(jìn)、編碼明確的 xml。它適合手上已經(jīng)有成堆結(jié)構(gòu)化文本、又必須對接只認(rèn) xml 的老系統(tǒng)或第三方接口的人反過來如果你的數(shù)據(jù)連穩(wěn)定列結(jié)構(gòu)都沒有先補(bǔ)規(guī)范比找工具劃算。2. 拆開這個小工具解析層、映射層、寫出層把腳本從頭到尾讀一遍會發(fā)現(xiàn)它是很干凈的三段式解析層負(fù)責(zé)把一行文本切成列表映射層負(fù)責(zé)把列表下標(biāo)翻譯成 xml 節(jié)點路徑寫出層負(fù)責(zé)序列化、縮進(jìn)和編碼聲明。三層之間只靠一個字典配置和一組列表傳遞數(shù)據(jù)沒有任何一層知道另外兩層的細(xì)節(jié)。這種切法的好處是換數(shù)據(jù)源時只動解析層換下游結(jié)構(gòu)時只動映射配置出問題也能一眼定位是哪一層的鍋不用在幾百行里猜。我見過有人偷懶直接寫字符串模板recordid{}/id/record.format(row[0])樣例數(shù)據(jù)跑得飛快正式數(shù)據(jù)一上來就崩。原因是模板法把三層的邊界全抹平了字段里的、沒轉(zhuǎn)義空值沒兜底節(jié)點層級寫死在字符串里改一次要全文搜索。所以哪怕只是個小工具也值得按層次切開后面加字段、加校驗、加批量處理都是順手的事。2.1 三種 txt 形態(tài)與對應(yīng)的解析策略在動手寫解析器之前先給手上的 txt 分個類這決定了后面用什么讀法。日常遇到的絕大多數(shù)文本逃不出下面三種形態(tài)混著出現(xiàn)的也有通常頭部是鍵值信息、正文是行式數(shù)據(jù)。形態(tài)典型特征推薦解析方式高頻易錯點分隔符行式每行列數(shù)一致csv / tsv / 豎線 / 分號line.split(delim, maxsplit)分隔符被表格軟件換成空格定寬列式主frame程序按字節(jié)位置對齊肉眼看著像空格分開按固定下標(biāo)切片line[a:b]中文字符占位寬度與字節(jié)不一致鍵值塊式keyvalue成段空行分段逐行匹配kv空行切記錄值里本身含有號混合式前若干行是元信息之后才是數(shù)據(jù)表先定位表頭行再按行式處理表頭行位置不固定分隔符行式最省心前提是分隔符真的是你以為的那個。從 Excel 復(fù)制粘貼出來的「制表符分隔」經(jīng)常已經(jīng)變成四個空格肉眼看不出差別split(\t)只會返回一個元素。所以工具里加了一個分隔符嗅探拿前 N 行做投票只有每行列數(shù)完全一致且大于 1 才算候選候選里按「制表符優(yōu)先、空格最后」的順序取。CANDIDATE_DELIMS [\t, |, ,, ;, ] def sniff_delimiter(sample_lines, min_cols2): 用樣本行給候選分隔符投票返回列數(shù)最多的那個無法判斷返回 None scores {} for d in CANDIDATE_DELIMS: cols [len(line.split(d)) for line in sample_lines if line.strip()] if not cols: continue # 列數(shù)必須穩(wěn)定且不少于 min_cols否則視為誤判 if len(set(cols)) 1 and cols[0] min_cols: scores[d] cols[0] if not scores: return None return max(scores, keyscores.get)CANDIDATE_DELIMS的順序是有意排的空格最容易被誤判成合法分隔符放最后制表符最可靠放第一。min_cols默認(rèn) 2如果你的數(shù)據(jù)只有一列整行當(dāng)一個字段嗅探必然失敗這時候要允許人工強(qiáng)制指定--delimiter。函數(shù)返回None不是異常而是給上層一個明確信號這文件得人工看一眼別硬猜。定寬列式是另一個坑。有些老設(shè)備的輸出按固定字節(jié)寬度對齊日志里看著整整齊齊實際是中文字符占了兩到三個字節(jié)寬度按字符下標(biāo)切片全錯位。遇到這種先把文件按utf-8讀進(jìn)來用len(line.encode(utf-8))核對寬度實在不行就退回「按連續(xù)空格壓縮成單分隔符」的寬松模式寧可丟一點精度也別靜默錯位。鍵值塊式通常用于配置類數(shù)據(jù)keyvalue一行一個空行表示一條記錄結(jié)束。解析時要注意值里可能含所以split(, 1)而不是split()。空行切記錄之后還要丟掉純空白的塊否則最后一條記錄后面跟著的換行會多生成一個空節(jié)點。2.2 字段映射把列號寫進(jìn)配置而不是寫進(jìn)代碼映射關(guān)系一旦硬編碼進(jìn)代碼換一個數(shù)據(jù)源就得改腳本改完還要重新測一遍成本比想象中高。所以這個工具把字段映射抽成一份 JSON 配置腳本只認(rèn)配置、不認(rèn)業(yè)務(wù)。{ source: {delimiter: \t, encoding: utf-8-sig, has_header: true}, root: records, record: record, fields: [ {index: 0, path: meta/id, type: str, required: true}, {index: 1, path: meta/time, type: datetime, format: %Y-%m-%d %H:%M:%S}, {index: 2, path: payload/name, type: str, default: }, {index: 3, path: payload/value,type: float, default: 0} ] }這份配置表達(dá)的信息量其實不小source.delimiter為null時啟用自動嗅探has_header決定第一條有效行是表頭還是數(shù)據(jù)path用斜杠表示節(jié)點層級父節(jié)點不存在就自動創(chuàng)建。required的字段取值為空直接拋錯default的字段則靜默補(bǔ)默認(rèn)值——兩者的區(qū)別是「數(shù)據(jù)壞了」和「數(shù)據(jù)缺了」處理策略不該一樣。def build_record(record_el, row, fields): for spec in fields: idx spec[index] raw row[idx].strip() if idx len(row) else if raw and spec.get(required): raise ValueError(必填字段為空: spec[path]) text convert(raw, spec) # 類型轉(zhuǎn)換見 4.3 node record_el for part in spec[path].split(/)[:-1]: child node.find(part) # 顯式判空不要寫 node.find(p) or SubElement(...) if child is None: child ET.SubElement(node, part) node child ET.SubElement(node, spec[path].split(/)[-1]).text text這里有一行注釋值得單獨說不要用node.find(part) or ET.SubElement(node, part)這種簡寫。Element 對象的布爾值取決于它有沒有子元素一個已經(jīng)存在但沒有子節(jié)點的meta會被判成False于是重復(fù)創(chuàng)建同名節(jié)點最后 xml 里出現(xiàn)兩個meta下游用find()只能拿到第一個值全丟。這是標(biāo)準(zhǔn)庫留給所有人的一個坑寫成顯式判空雖然多兩行但省掉的排查時間遠(yuǎn)不止兩行。index用的是列下標(biāo)而不是表頭名看起來不夠優(yōu)雅但對老數(shù)據(jù)更穩(wěn)——很多 txt 的表頭是中文、帶空格、甚至同名重復(fù)按下標(biāo)定位反而不會錯。如果數(shù)據(jù)確實規(guī)范可以在配置里加一個可選name字段加載時用表頭行反查下標(biāo)兩種方式并存。2.3 XML 寫出聲明、縮進(jìn)、編碼三件事寫出層看著最簡單實際上是最容易「本地跑得好、交給下游就報錯」的一環(huán)。要點就三個xml 聲明里的 encoding 必須和實際寫盤的編碼一致縮進(jìn)只影響可讀性但寫出來好看與否直接影響人工核對效率空節(jié)點的寫法x /和x/x在部分老解析器里行為不同要顯式定死。def write_xml(tree, out_path, encodingutf-8): 序列化并落盤encoding 同時決定文件編碼和聲明內(nèi)容 try: ET.indent(tree, space ) # Python 3.9 才有低版本走下面的兜底 except AttributeError: _manual_indent(tree.getroot()) tree.write( out_path, encodingencoding, # 與聲明里的 encoding 屬性保持一致 xml_declarationTrue, # 輸出 ?xml version1.0 encodingutf-8? short_empty_elementsTrue # 空節(jié)點寫成 x /而不是 x/x )xml_declarationTrue不加的話某些只吃嚴(yán)格 xml 的系統(tǒng)會直接拒收encoding傳utf-8時 ElementTree 不會額外寫 BOM這一點對下游比對友好省得文件頭多出三個不可見字節(jié)導(dǎo)致哈希不一致。ET.indent是 3.9 才進(jìn)標(biāo)準(zhǔn)庫的如果運(yùn)行環(huán)境版本不確定就保留那個try/except兜底否則在舊機(jī)器上會直接AttributeError而這行報錯出現(xiàn)在寫盤前前面幾分鐘的解析全白做。還有一個容易忽略的細(xì)節(jié)tree.write()會以二進(jìn)制模式打開文件傳進(jìn)去的encoding只影響序列化方式。如果你的目標(biāo)是「文件本身是 utf-8 無 BOM」這樣寫沒問題如果下游明確要求帶 BOM就得自己用codecs.BOM_UTF8拼一下別指望encodingutf-8-sig能直接生效。3. 跑通第一條轉(zhuǎn)換鏈路命令行參數(shù)與批量目錄單文件轉(zhuǎn)換只是驗證階段真正上線一定是整個目錄批量跑。這一章按「先跑通一個文件 → 再批量 → 最后校驗」的順序推進(jìn)每一步都能獨立驗證出了問題不用一次懷疑全鏈路。參數(shù)設(shè)計上我傾向于把「輸入、輸出、配置」三個必填項顯式化其余全部給默認(rèn)值這樣日常調(diào)用最短特殊場景又能覆蓋。3.1 最小可運(yùn)行腳本與六個必設(shè)參數(shù)命令行接口用argparse就夠了不需要引入第三方框架。參數(shù)不多但每一個都對應(yīng)一類現(xiàn)實需求分隔符要能強(qiáng)制指定嗅探失敗時救命編碼要能指定老文件不是 utf-8出錯策略要能選批量跑的時候不能一條壞數(shù)據(jù)就全停。import argparse def build_parser(): p argparse.ArgumentParser(descriptiontxt - xml 批量轉(zhuǎn)換) p.add_argument(-i, --input, requiredTrue, help輸入文件或目錄) p.add_argument(-o, --output, requiredTrue, help輸出文件或目錄) p.add_argument(-c, --config, requiredTrue, help字段映射 JSON 路徑) p.add_argument(-d, --delimiter, defaultNone, help強(qiáng)制指定分隔符默認(rèn)自動嗅探) p.add_argument(-e, --encoding, defaultauto, help源文件編碼auto 表示探測) p.add_argument(--recursive, actionstore_true, help遞歸遍歷子目錄) p.add_argument(--on-error, choices[skip, abort, report], defaultreport, help單文件失敗時的處理策略) p.add_argument(--chunk, typeint, default5000, help每多少條記錄寫一次盤) return p參數(shù)說明里最需要解釋的是--on-error。skip是壞文件直接跳過、不留痕跡適合每天定時跑、只要結(jié)果能出就行的場景abort是遇到第一個錯誤立刻退出適合調(diào)試期能最快暴露問題report是默認(rèn)值繼續(xù)跑完但把所有失敗文件的路徑和異常收集起來最后統(tǒng)一打印。生產(chǎn)上我一般用report跑完看一眼失敗清單比中途停掉再重跑省事得多。--chunk是為大文件準(zhǔn)備的。默認(rèn) 5000 條記錄落一次盤意味著一個幾十萬行的文件不會在內(nèi)存里堆出一個巨大的 ElementTree也不會因為最后一行崩潰導(dǎo)致前面幾十分鐘白跑。代價是分片寫入需要自己管理根節(jié)點閉合不能用一次性tree.write()得用增量寫法。--delimiter默認(rèn)None而不是\t這個設(shè)計很關(guān)鍵。默認(rèn)給個具體值會讓用戶忘了嗅探的存在而嗅探失敗時必須顯式指定反而更清楚。同理--encoding默認(rèn)auto走探測邏輯探測不出來再報錯讓人指定不要默默按 utf-8 讀那樣只會讀到一堆亂碼而不報錯是更壞的結(jié)果。3.2 批量轉(zhuǎn)換目錄鏡像、命名規(guī)則與失敗清單批量處理的核心約定是「輸出目錄結(jié)構(gòu)和輸入目錄結(jié)構(gòu)鏡像」輸入data/2024/03/a.txt就輸出out/2024/03/a.xml只換擴(kuò)展名、只換根目錄。這樣下游按日期或按設(shè)備號索引的邏輯完全不用改也不用擔(dān)心同名文件互相覆蓋。from pathlib import Path def convert_tree(src_dir, dst_dir, pattern*.txt, recursiveFalse, on_errorreport, convert_oneNone): src_dir, dst_dir Path(src_dir), Path(dst_dir) it src_dir.rglob(pattern) if recursive else src_dir.glob(pattern) failed, done [], 0 for src in sorted(it): rel src.relative_to(src_dir).with_suffix(.xml) dst dst_dir / rel dst.parent.mkdir(parentsTrue, exist_okTrue) # 鏡像目錄缺哪層補(bǔ)哪層 try: convert_one(src, dst) done 1 except Exception as exc: failed.append((str(src), repr(exc))) if on_error abort: raise print(完成 {} 個失敗 {} 個.format(done, len(failed))) return failedsorted(it)不是為了美觀是為了讓失敗清單的順序穩(wěn)定方便和上一次的清單做 diffwith_suffix(.xml)只換最后一個后綴a.txt.bak這種命名會變成a.txt.xml如果數(shù)據(jù)里真有這種備份文件遍歷時用pattern加if src.suffix .txt雙重過濾。dst.parent.mkdir(parentsTrue, exist_okTrue)是鏡像目錄的關(guān)鍵少了它遞歸模式下一進(jìn)子目錄就FileNotFoundError。失敗清單一定要落盤不能只print。跑批任務(wù)經(jīng)常是后臺執(zhí)行終端輸出丟了等下游反饋數(shù)據(jù)缺失時你已經(jīng)無從查起。最簡單的做法是寫一個failed.tsv兩列分別是源路徑和異常摘要下次重跑直接讀這個清單只重跑失敗的比全量重跑快一個數(shù)量級。還有一個隱性約定輸出文件先寫臨時名再原子改名。批量轉(zhuǎn)換中途被 kill 是常態(tài)直接往目標(biāo)路徑寫會留下半截 xml下游讀到解析失敗的殘文件還以為數(shù)據(jù)壞了。寫法是dst.with_suffix(.xml.tmp)寫完再os.replace一行代碼換來的確定性很值。3.3 轉(zhuǎn)換后的校驗回讀、計數(shù)與結(jié)構(gòu)比對轉(zhuǎn)換腳本自己說成功不算成功得讓 xml 解析器說成功。校驗分三層成本從低到高語法層用解析器把文件讀一遍結(jié)構(gòu)層比對記錄數(shù)和關(guān)鍵字段是否存在內(nèi)容層抽幾條和源 txt 逐字段對照。import xml.etree.ElementTree as ET def verify(xml_path, expect_recordsNone, required_paths(meta/id,)): tree ET.parse(xml_path) # 語法錯誤在這一步就會拋 root tree.getroot() records root.findall(record) if expect_records is not None and len(records) ! expect_records: raise AssertionError(記錄數(shù)不符: {} ! {}.format(len(records), expect_records)) for r in records[:50]: # 抽查前 50 條別全量遍歷拖慢流程 for path in required_paths: if r.find(path) is None: raise AssertionError(缺少節(jié)點: path) return len(records)ET.parse是最硬的一道關(guān)任何標(biāo)簽未閉合、非法字符、編碼聲明與實際不符都會在這里炸出來成本極低建議每個文件都跑。記錄數(shù)比對的期望值從哪來最省事的辦法是數(shù)源文件的有效行數(shù)去掉表頭和空行和 xml 里的record節(jié)點數(shù)對齊兩邊差一條就說明某行解析異常被吞了。結(jié)構(gòu)層校驗只抽查前 50 條是刻意的取舍。全量遍歷幾十萬節(jié)點在批量場景下會把總耗時翻倍而結(jié)構(gòu)錯誤幾乎必然出現(xiàn)在頭部抽查足夠發(fā)現(xiàn)系統(tǒng)性問題。真正需要逐條比對的是內(nèi)容層那屬于抽樣人工核對或者單獨寫回歸腳本的范疇不該塞進(jìn)每次跑批的默認(rèn)路徑。如果機(jī)器上有xmllint加一道外部校驗也很劃算。它和 Python 解析器的實現(xiàn)不同能覆蓋一些標(biāo)準(zhǔn)庫容忍但嚴(yán)格解析器不容忍的寫法# 只做語法校驗不輸出內(nèi)容返回非 0 表示文件有問題 find out -name *.xml -print0 | xargs -0 -n1 xmllint --noout-print0配xargs -0是為了應(yīng)付帶空格的文件名批量腳本里凡是遍歷文件的地方都建議這么寫別等某天出現(xiàn)一個report 2024 03.txt才發(fā)現(xiàn)整條流水線斷在空格上。4. 特殊字符與編碼轉(zhuǎn)義、BOM、空值三處最容易翻車的地方前三章跑的是「干凈數(shù)據(jù)」現(xiàn)實里的 txt 從來不干凈。業(yè)務(wù)字段里帶、備注里帶尖括號、從舊系統(tǒng)導(dǎo)出的文件是 GBK、空值有時候是空字符串有時候是NULL有時候干脆缺列。這些問題不會讓腳本立刻崩但會讓下游拿到「能解析、值不對」的 xml排查成本比直接報錯高得多。這一章把三類問題拆開處理。4.1 五個必須處理的字符與 CDATA 的取舍xml 里有五個字符在文本節(jié)點中具有特殊含義、、、、。前兩個不轉(zhuǎn)義會直接破壞文檔結(jié)構(gòu)后三個在屬性值里必須轉(zhuǎn)義、在文本節(jié)點里可轉(zhuǎn)可不轉(zhuǎn)。好消息是只要用序列化器寫節(jié)點這五個字符都會被自動處理你什么都不用做壞消息是很多人會在某一步「優(yōu)化」成字符串拼接把保護(hù)全拆了。# 錯誤示范手工拼接字段里一個 就讓整個文件解析失敗 bad name{}/name.format(name) # 正確做法交給序列化器文本賦值即可 el ET.SubElement(record_el, name) el.text name值得強(qiáng)調(diào)的是el.text賦值和el.set(attr, value)都會自動轉(zhuǎn)義但如果你往el.text里塞的是已經(jīng)轉(zhuǎn)義過的amp;序列化器會再轉(zhuǎn)一次變成amp;amp;下游解析出來就是字面量amp;。這類雙重轉(zhuǎn)義問題在數(shù)據(jù)經(jīng)過兩套系統(tǒng)時特別常見判斷方法很簡單源數(shù)據(jù)里看到amp;就說明上游已經(jīng)轉(zhuǎn)過一次你要做的是還原而不是再轉(zhuǎn)。CDATA 是另一個常見訴求。有人覺得字段里有 html 片段必須用![CDATA[...]]包起來實際上標(biāo)準(zhǔn)庫的 ElementTree 不支持直接輸出 CDATA需要手工拼或者換 lxml。多數(shù)情況下沒必要CDATA 的唯一作用是讓和不用轉(zhuǎn)義而序列化器已經(jīng)幫你轉(zhuǎn)義了下游解析出來的文本內(nèi)容完全一致。只有當(dāng)字段內(nèi)容本身就是一段需要人眼閱讀的 xml/html 片段、且下游明確要求原樣保留時才值得折騰否則純屬給自己加一道工序。真正需要留意的是控制字符。從老設(shè)備或數(shù)據(jù)庫導(dǎo)出的文本里偶爾混入\x00、\x0b這類不可見字符它們在 xml 1.0 里是非法的序列化時不報錯寫出來解析時炸。穩(wěn)妥做法是在賦值前統(tǒng)一過濾import re ILLEGAL re.compile(r[\x00-\x08\x0b\x0c\x0e-\x1f]) def clean(text): return ILLEGAL.sub(, text) if text else text這個正則放過的\x09制表符、\x0a換行、\x0d回車是 xml 允許的別一起干掉否則多行文本會被壓成一行。4.2 編碼探測與 BOMutf-8-sig 與 gb18030編碼問題最氣人的地方在于它經(jīng)常不報錯。用 utf-8 去讀一個 GBK 文件Python 可能直接拋UnicodeDecodeError這是好事但如果文件里恰好全是 ASCII 字符讀進(jìn)來一切正常等某天出現(xiàn)一個中文人名整批數(shù)據(jù)才開始崩。所以編碼處理要分兩步先探測探測不出來就報錯讓人指定絕不靜默降級。def open_text(path, encodingauto): 按指定編碼打開auto 時先看 BOM再按 utf-8 試讀 if encoding and encoding ! auto: return open(path, r, encodingencoding, newline) with open(path, rb) as f: head f.read(4) if head.startswith(b\xef\xbb\xbf): return open(path, r, encodingutf-8-sig, newline) # 吃掉 BOM return open(path, r, encodingutf-8, newline)newline這個參數(shù)容易被忽略。默認(rèn)的通用換行模式會把\r\n統(tǒng)一成\n對多數(shù)場景沒問題但如果某個字段本身要保留原始換行符統(tǒng)一轉(zhuǎn)換就丟了信息。批量轉(zhuǎn)換工具我傾向于關(guān)掉自動轉(zhuǎn)換讓數(shù)據(jù)原樣進(jìn)來需要處理再顯式處理。BOM 是另一個高頻坑。帶 BOM 的 utf-8 文件用encodingutf-8打開第一個字段的開頭會多出一個不可見的\ufeff肉眼完全看不出來但用它做字典鍵、做字符串比較、寫進(jìn) xml 都會出問題。判斷方法repr(row[0])看開頭是不是\ufeff。解決就是utf-8-sig它在讀取時自動剝掉 BOM寫入時不加 BOM。GBK 系文件沒有 BOM 可依靠utf-8試讀失敗來兜底是最簡單的策略def read_with_fallback(path): for enc in (utf-8-sig, gb18030): try: with open(path, r, encodingenc, newline) as f: return f.read(), enc except UnicodeDecodeError: continue raise UnicodeDecodeError(無法確定編碼請用 --encoding 指定: str(path))gb18030而不是gbk是因為前者是超集能覆蓋更多生僻字代價是偶爾會把非 GBK 文件「成功」解成亂碼。所以這個兜底只該在明確知道數(shù)據(jù)源是中文舊系統(tǒng)時啟用不要無腦加進(jìn)通用流程。探測順序也別搞反先 utf-8 再 gb18030反過來會讓很多 utf-8 文件被誤判。4.3 空值、缺字段與類型推斷空值處理是最容易被低估的一節(jié)。同一條記錄字段為空可能有三種含義值確實為空、這個字段在源數(shù)據(jù)里不存在、這個字段本來該有值但采集失敗了。三種情況在 xml 里應(yīng)該有不同的表達(dá)全塞成空字符串等于把信息丟了。工具里的約定是配置里標(biāo)了required的字段為空直接報錯標(biāo)了default的字段為空補(bǔ)默認(rèn)值既沒標(biāo) required 也沒標(biāo) default 的字段為空就寫空節(jié)點。這個規(guī)則簡單到不用記但能覆蓋九成場景。類型轉(zhuǎn)換則要防兩個坑。第一個是浮點數(shù)str(0.1 0.2)會得到0.30000000000000004直接寫進(jìn) xml 下游拿去算金額就出事了第二個是科學(xué)計數(shù)法很小的數(shù)會被str()成1e-05很多只認(rèn)定點小數(shù)的老系統(tǒng)直接報格式錯誤。from datetime import datetime def convert(raw, spec): 按配置把原始字符串轉(zhuǎn)成 xml 文本空值走 default if raw or raw is None: return spec.get(default, ) t spec.get(type, str) if t int: return str(int(raw)) if t float: # 定點格式化保留 6 位后裁掉多余的 0避免科學(xué)計數(shù)法和浮點尾差 return format(float(raw), .6f).rstrip(0).rstrip(.) if t datetime: return datetime.strptime(raw, spec[format]).isoformat() return raw.6f這個精度不是隨便定的。金融和計量場景一般到小數(shù)點后 4 到 6 位再多就是噪聲rstrip(0).rstrip(.)是為了讓1.500000變成1.5、2.000000變成2.再變成2注意順序不能反先裁 0 再裁點否則2.000000裁完點是2.會留下一個非法的小數(shù)點。datetime的format必須寫在配置里而不是代碼里因為源數(shù)據(jù)的日期格式五花八門%Y/%m/%d、%Y-%m-%d %H:%M:%S、甚至20240301都有。統(tǒng)一轉(zhuǎn)成 ISO 8601 再寫進(jìn) xml下游排序和比較都不用再解析一次。5. 避坑記錄五條從現(xiàn)場撿回來的報錯下面這五條都不是理論推演是批量跑真實數(shù)據(jù)時踩出來的。每條按「現(xiàn)象 → 原因 → 解決」寫如果你正準(zhǔn)備跑第一批全量數(shù)據(jù)建議先對照著掃一眼自己的輸入。5.1 所有行只解析出一列分隔符憑空消失現(xiàn)象很典型本地用記事本打開文件肉眼能看到字段之間有明顯間隔腳本跑完卻每條記錄只有一個字段值是一整行拼接后的字符串sniff_delimiter返回None。原因是分隔符在流轉(zhuǎn)過程中被換了。從 Excel 或網(wǎng)頁表格復(fù)制粘貼出來的「制表符」經(jīng)過郵件、聊天工具、某些編輯器保存之后制表符\t會被展開成 4 個或 8 個空格也有的是反過來源文件本來是多個空格對齊被某個工具壓成了一個空格。兩種情況下split(\t)都拿不到多列。解決辦法分兩層。第一層是嗅探函數(shù)必須把空格列進(jìn)候選并且允許「連續(xù)空格視為一個分隔符」的寬松模式用re.split(r , line.strip())處理。第二層是加一道列數(shù)斷言解析出的第一行如果只有 1 列而配置里的fields有 4 個直接報錯退出并打印前 200 個字符的repr讓人一眼看到實際的分隔符是什么。我在批量腳本里把這條斷言做成了默認(rèn)開啟寧可跑失敗也不要跑出一堆看似正常的錯數(shù)據(jù)。5.2 Windows 上跑批中文全變成問號或直接拋編碼錯現(xiàn)象是在開發(fā)機(jī)上跑得好好的腳本換到另一臺機(jī)器尤其是中文 Windows 服務(wù)器上日志里的中文變成???嚴(yán)重時直接UnicodeEncodeError: gbk codec cant encode character。原因和轉(zhuǎn)換邏輯無關(guān)出在標(biāo)準(zhǔn)輸出。Python 在 Windows 上的sys.stdout默認(rèn)編碼跟隨系統(tǒng)區(qū)域設(shè)置中文環(huán)境就是 GBK。腳本里任何一句print(處理完成: 中文路徑)都會走這個編碼遇到 GBK 表示不了的字符就炸。更隱蔽的是如果腳本把日志重定向到文件文件也會按 GBK 寫用 utf-8 打開就是亂碼。解決辦法是別依賴默認(rèn)編碼。寫文件時顯式encodingutf-8所有open()調(diào)用都帶上需要print調(diào)試信息時在入口處加一句sys.stdout.reconfigure(encodingutf-8, errorsreplace)3.7 起可用或者干脆把日志寫進(jìn)文件而不是打在終端。errorsreplace是保命的它讓日志不會因為一個字符打不出來而中斷整個跑批。5.3 數(shù)值被寫成科學(xué)計數(shù)法下游報類型不匹配現(xiàn)象是轉(zhuǎn)換后的 xml 里出現(xiàn)value1e-05/value或value3.0000000000000004/value本地看沒人發(fā)現(xiàn)下游做數(shù)值解析時報格式錯誤或者算出來的金額差了幾分錢。原因是中間經(jīng)過了float再str()。二進(jìn)制浮點表示不了 0.1 這種十進(jìn)制小數(shù)累加之后尾差就出來了小于 0.0001 的數(shù)str()時自動切科學(xué)計數(shù)法這是 Python 的顯示規(guī)則不是 bug。解決辦法是在配置里給每個數(shù)值字段顯式標(biāo)type: float轉(zhuǎn)換時走定點格式化并且在格式化之前用Decimal(str(raw))收一道把源字符串按十進(jìn)制語義解析避免float()引入誤差。如果字段是金額更好的做法是配置里加個scale: 2轉(zhuǎn)換時乘 100 存整數(shù)、寫 xml 時再除以 100全程不碰浮點。5.4 xml 里出現(xiàn)重復(fù)的同名節(jié)點下游只取到第一個現(xiàn)象是下游反饋「某些記錄的 name 全空了」你把文件打開一看結(jié)構(gòu)是這樣的recordpayloadnameA/name/payloadpayloadnameB/name/payload/record兩個payload并列下游用find(payload/name)只拿到 AB 被忽略。原因是映射代碼里用了node.find(part) or ET.SubElement(node, part)這種簡寫。Element 的布爾值由子元素數(shù)量決定一個已存在但暫時沒有子節(jié)點的父節(jié)點會被判成假于是又創(chuàng)建了一個同名節(jié)點。層級越深越容易觸發(fā)meta下面先建了id之后才建time的那一瞬間就是假的。解決辦法就是 2.2 里那段顯式判空。另外在寫出之前加一道自檢遍歷每條記錄的直接子節(jié)點名如果出現(xiàn)重復(fù)就報錯。這道檢查成本很低但能擋住一整類結(jié)構(gòu)性問題。5.5 大文件跑一半內(nèi)存爆掉機(jī)器卡死現(xiàn)象是處理幾萬行的小文件一切正常換成一個幾十萬行的日志文件腳本跑到中途內(nèi)存曲線直線上升最后MemoryError或者機(jī)器開始換頁卡死。原因是兩層疊加f.readlines()一次性把整個文件讀進(jìn)內(nèi)存ElementTree 的整棵樹也全在內(nèi)存里幾十萬個節(jié)點每個都是對象開銷遠(yuǎn)大于原始文本。一個 200MB 的文本能撐出 2GB 以上的內(nèi)存占用。解決辦法是兩頭都改成流式。讀用for line in f:逐行迭代不要readlines()寫用增量模式每--chunk條記錄就把當(dāng)前這批子節(jié)點序列化追加到文件然后清空。增量寫的實現(xiàn)稍微繞一點需要手工寫?xml ...?聲明和根節(jié)點開標(biāo)簽中間追加序列化后的片段最后補(bǔ)上根節(jié)點閉標(biāo)簽。如果下游不強(qiáng)制要求單文件更省事的方案是按固定行數(shù)切片輸出多個 xmlpart-0001.xml、part-0002.xml下游按序讀取即可改造成本幾乎為零。6. 進(jìn)階把映射關(guān)系外置成模板順手加一道回歸校驗字段映射寫進(jìn) JSON 之后下一個自然的需求是「多個數(shù)據(jù)源共用大部分字段只差幾列」。這時候復(fù)制多份配置會讓維護(hù)變成災(zāi)難改一個公共字段要改十幾份文件。我的做法是給配置加一層extends子配置只聲明差異字段加載時先繼承父配置再覆蓋實現(xiàn)也就二十行。模板字段含義常見取值extends父模板路徑相對當(dāng)前配置解析base/common.jsonsource.encoding源文件編碼auto走探測utf-8-sig/gb18030fields[].index列下標(biāo)子模板可用-1表示追加到末尾0~n-1fields[].required為空時是報錯還是補(bǔ)默認(rèn)值true/falseoutput.pretty是否縮進(jìn)交付給人看開給機(jī)器讀可關(guān)true/falseimport json from pathlib import Path def load_config(path, _seenNone): 支持 extends 繼承子配置的 fields 按 path 覆蓋父配置 _seen _seen or set() path Path(path).resolve() if path in _seen: raise ValueError(配置循環(huán)繼承: str(path)) _seen.add(path) cfg json.loads(path.read_text(encodingutf-8)) parent cfg.pop(extends, None) if not parent: return cfg base load_config(path.parent / parent, _seen) merged dict(base) merged.update({k: v for k, v in cfg.items() if k ! fields}) by_path {f[path]: f for f in base.get(fields, [])} for f in cfg.get(fields, []): by_path[f[path]] f # 同路徑覆蓋新路徑追加 merged[fields] list(by_path.values()) return merged_seen這個集合是防循環(huán)繼承的A 繼承 B、B 又繼承 A 的情況在配置文件里比想象中容易出現(xiàn)尤其是多人維護(hù)的時候。fields用path做鍵而不是用index是因為同一個字段在不同數(shù)據(jù)源里列位置經(jīng)常變但節(jié)點路徑是穩(wěn)定的語義標(biāo)識。配套的回歸校驗也很關(guān)鍵。改完配置之后拿一份已知正確輸出的樣本重新跑一遍把結(jié)果和基線文件做結(jié)構(gòu)化比對——不比字節(jié)比「記錄數(shù)、每條記錄的子節(jié)點路徑集合、關(guān)鍵字段的值」這樣縮進(jìn)變化、屬性順序變化不會誤報真正的字段丟失和值錯誤一個都跑不掉。def diff_structure(a_root, b_root): 比對兩棵樹的節(jié)點路徑與文本返回差異列表 def walk(el, prefix): cur prefix / el.tag yield cur, (el.text or ).strip() for c in el: yield from walk(c, cur) left, right dict(walk(a_root)), dict(walk(b_root)) return [(k, left.get(k), right.get(k)) for k in set(left) | set(right) if left.get(k) ! right.get(k)]這套東西我用了很久最大的價值不是發(fā)現(xiàn) bug而是讓「改配置」這件事從「提心吊膽跑一遍看看」變成「跑完看差異列表是不是空的」。有一回一個同事把default從一個空字符串改成0結(jié)構(gòu)比對立刻列出了兩千多條差異五分鐘就回滾了要是靠人工抽查這個改動會安安靜靜躺在數(shù)據(jù)里等下游算出一個全零的報表才被發(fā)現(xiàn)。從那以后我每次動映射配置都強(qiáng)制先跑一遍基線比對再上線哪怕只是改了一個縮進(jìn)。希望這套思路能幫到你源碼包和示例配置在整理好的下載里拿到后先跑自帶的樣例再換自己的字段。本文還有配套的精品資源點擊獲取