攝影或3C

Python 正規表達式進階技巧：掌握「特例優先」(Exception-First) 法則

在文字處理與資料清理的過程中，
正規表達式 (Regular Expressions) 是我們不可或缺的利器。
然而，當我們需要處理程式碼或自然語言中的
「駝峰式命名」(CamelCase) 拆分時，
標準的 Regex 規則往往會成為一把雙面刃。

本文將帶您深入探討一個強大且優雅的正則匹配模式——
「特例優先」(Exception-First)，
了解它如何拯救被切得支離破碎的領域專有名詞。

痛點：當通用規則摧毀專業術語
在處理字串時，我們常會寫出一套強大的通用規則來
拆分連續大寫字母或駝峰式命名。但這套規則是盲目的。

想像一下你需要處理硬體檢測日誌，
裡面充滿了像是 NVMe、PCIe 或是 typeC 這樣的術語。
如果你使用標準的拆分規則：

PCIeStatus 會因為大小寫交錯，被慘忍地肢解成 [‘PC’, ‘Ie’, ‘Status’]。
typeC 會被從中間攔腰截斷變成 [‘type’, ‘C’]。
原本具有特殊意義的領域專有詞彙，就這樣被破壞殆盡，
導致後續的資料比對（如產生 Bigram）完全失效。

解決方案：「特例優先」概念 (Exception-First)
要解決這個問題，我們需要改變思維策略：
不要試圖寫出一個能完美防堵所有不規則狀況的複雜正則規則，
而是「先發放 VIP 通行證」——先撿走特例，
剩下的再交給通用規則。

這個技巧的核心在於結合 Python 字串的 join() 語法，
與正規表達式的 | (OR) 運算符號。
只要將我們想要保護的特定單字列為清單，
並使用 | 串接「置於通用規則的最前方」，
就能賦予這些特例最高的保留優先權。

運作原理剖析：為什麼這樣有效？
這個技巧之所以奏效，
主要依賴於 Regex 引擎的兩個核心運作機制：

1. 嚴格的「由左至右」配對優先權

當 Regex 引擎遇到 A | B | C 這個模式時，
它不是在比誰最適合，而是在比「誰先跑出來」。
它總是從最左邊的選項開始嘗試，
只要 A 成功了，它就完全不看 B 和 C 了。
藉由將專有名詞放在 | 的最前方，
我們迫使引擎在套用任何拆字規則前，
先檢查「這是不是一個特例？」

2. 字元消耗 (Character Consumption)

當正則引擎成功匹配了一段文字，
這段文字就會被「消耗」掉（整塊被提出來打包），
然後掃描游標會直接跳過這段字，從下一個字母繼續開始找。
這意味著一旦引擎在第一關命中並消耗了 PCIe，
它的游標就會飛越這四個字母。
它成功地「繞過」了後續會把字切碎的駝峰判斷式，
免除了被開箱肢解的命運。

程式碼實戰：Bad vs. Good

以下我們將進行實作對比。
我們會使用 re.compile() 與字串的 ‘|’.join() 來建立動態的特例攔截網。

import re

test_targets = [
    "PCIeStatusInfo",
    "VGAAutoProcessStep",
    "checkTypeCConnection"
]

# ==========================================
# ❌ 糟糕的作法 (Bad Way)
# 僅依賴通用模式：使用前瞻 (?=) 尋找連續大寫或駝峰切點
# ==========================================
base_pattern = r'[A-Z]?[a-z]+|[A-Z]+(?=[A-Z][a-z]|\d|\W|$)|\d+'
bad_regex = re.compile(base_pattern)

print("--- 糟糕的結果 ---")
for text in test_targets:
    # PCIe 變成了 PC, Ie，typeC 變成了 type, C
    result = bad_regex.findall(text)
    print(f"原本: {text:25} -> 拆出: {result}")

print("\n")

# ==========================================
# ✅ 優秀的作法 (Good Way) - 特例優先攔截
# ==========================================
# 1. 定義不能被破壞的術語清單
exceptions = ['PCIe', 'NVMe', 'typeC']

# 2. 利用 Python 特性，將特例用 OR (|) 串接，並與通用規則結合
# 最終會變成類似: (PCIe|NVMe|typeC|[A-Z]?[a-z]+|...)
good_pattern = r'|'.join(exceptions) + r'|' + base_pattern
good_regex = re.compile(good_pattern)

print("--- 特例優先的結果 ---")
for text in test_targets:
    # 引擎會優先攔截 PCIe, typeC，而 VGAAutoProcessStep 仍會順利套用基礎規則
    result = good_regex.findall(text)
    print(f"原本: {text:25} -> 拆出: {result}")

輸出結果展示：

TypeC沒有切分好

base_pattern = r'[A-Z]?[a-z]+|[A-Z]+(?=[A-Z][a-z]|\d|\W|$)|\d+'

這是一個非常經典且強大的正規表達式（Regular Expression），
通常用於將駝峰命名法（CamelCase、PascalCase）
或是夾雜縮寫的混合字串，精準地切分成獨立的單字、專有名詞與數字。
它也是負責處理所有「非例外字串」的底層引擎。

我們將這段正則表達式用 | (OR) 拆解為三大區塊來逐一解析：

[A-Z]?[a-z]+ | [A-Z]+(?=[A-Z][a-z]|\d|\W|$) | \d+

第一部分：[A-Z]?[a-z]+（捕捉一般單字）
這部分負責捕捉最常見的英文單字形式（全小寫或首字母大寫）。

[A-Z]?：? 代表「零個或一個」。
也就是這單字開頭不一定要有大寫字母。
[a-z]+：+ 代表「一個或多個連續的小寫字母」。
運作結果與範例：
‘cat’ -> 完美命中（零個大寫，接連續小寫）
‘Dog’ -> 完美命中（一個大寫，接連續小寫）
‘camelCase’ -> 會在這個規則下，
分兩趟被精準切出 ‘camel’ 和 ‘Case’。
第二部分：[A-Z]+(?=[A-Z][a-z]|\d|\W|$)
（捕捉連續大寫與縮寫，極其聰明的一段）
這部分專門用來處理連續的大寫字母（通常是縮寫），
並且能像長了眼睛一樣知道
「我該在哪裡停下來，才不會害到後面的單字」。

[A-Z]+：貪婪地一直吃連續的大寫字母。
(?=…)：這叫做正向預查 (Positive Lookahead)。
什麼是預查？這是一個「不消耗字元」的條件。
它就像是正則引擎站在這裡「拿著望遠鏡往右邊偷看」。
如果後方符合括號內的條件，目前的提取才算成立；
但它偷看的這段內容，不會被包進目前的提取結果中。
偷看的條件是什麼？ [A-Z][a-z] | \d | \W | $（符合任一皆可）：
[A-Z][a-z]：看到了「一個大寫配一個小寫」，
也就是看到了一個新的駝峰單字的開頭！
\d：看到了數字。
\W：看到了符號或空格。
$：看到了字串結尾。
這有多神妙？我們看範例 VGAAuto：

引擎開始用 [A-Z]+ 狂吃大寫字母，一路吃到了 ‘VGAA’。
可是它必須通過預查條件檢驗！VGAA 後面的字元是 ‘u’，
不符合前瞻條件裡的 [A-Z][a-z]，也不符合數字或結尾。
於是引擎會「吐出」最後一個吃進去的 A，
倒退一步，讓自己的結果變成 VGA。
此時它再度拿起望遠鏡往右看，
現在後面接的是 Au (大寫A+小寫u)！完美符合 [A-Z][a-z]！！
於是引擎安心地把 ‘VGA’ 切出來，
並把完整的 ‘Auto’ 原封不動地留給第一條規則去善後。
如果沒有這個預查，
VGAAuto 就會被暴力切成 VGAA 和 uto（一堆無意義的碎片）。
第三部分：\d+（捕捉數字）
\d：對應任何數字 (0-9)。
+：表示「一個或連續多個」。
運作結果與範例：
負責把字串中夾雜的數字獨立抽取出來。
‘USB3Connection’ 會順序被切出：
‘USB’ (規則2)、’3′ (規則3)、’Connection’ (規則1)。

在資料清理、程式碼重構或日誌分析時，拆解 CamelCase（駝峰式命名）幾乎是每個開發者的必經之路。如果只是單純的 camelCase 或 PascalCase，隨便寫個 [A-Z]?[a-z]+ 就能輕鬆搞定。

但現實世界經常充滿了惡意 —— 當你的系統遇到充滿縮防與不規則大小寫的變種單字時，傳統的正規表達式就會瞬間崩潰。今天，我們就來探討如何利用 「例外優先 Token 消耗模式」 (Exception-First Token Consumption) 以及經常被低估的 (?i:…) 區域修飾符，來完美解決這個痛點。

💥 災難現場：名為 `USBtypeCConnection` 的邊界案例

想像一下，你需要解析硬體設備的日誌，設備吐出了一個極度棘手的字串：USBtypeCConnection。

如果用標準的 CamelCase 拆解邏輯（例如匹配大寫開頭的單字或是尋找連續大寫），你會得到什麼災難級的結果？
它極高機率會被切碎成：['US', 'Btype', 'C', 'Connection']。

一場災難！標準解法在遇到 USB (全大寫) 緊接著 typeC (小寫加大寫) 這種毫無規則可言的組合時，完全無法防禦。如果我們把這些錯誤的單字輸入給下游的文字分析系統，搜尋精準度絕對會大打折扣。

💡 破局核心戰略：例外優先 (Exception-First)

面對這種毫無規律的專業領域名詞，與其把通用的正規表達式寫成難以維護的「天書」，不如轉換思維，採用例外優先設計模式。

正則引擎的運作原理是由左至右、優先匹配。如果你在 | (OR) 的最前面放置了特定的邊界案例，引擎就會優先消耗這段字串。只要被例外規則吃掉的字元，它的內部游標就會直接跳過，後面的通用拆字規則連看都看不到它！

這是解析器設計中的經典思維：先發放 VIP 快速通關證，剩下的再過安檢。

🔧 致命陷阱與秘密武器：(?i:…)

當我們定義 USB 和 typeC 為特例時，通常會遇到大小寫不統一的問題（如 TypeC, typec）。我們很直覺會想幫 Regex 加上 re.IGNORECASE 旗標：

# 致命陷阱示範
good_regex = re.compile(good_pattern, re.IGNORECASE)

千萬不要這麼做！ 因為你的「通用駝峰規則」完全是依賴英文字母的「大小寫差異」在運作的！一旦啟用了全域忽略，它會把整串文字當成一條毫無起伏的純字母，什麼都切不出來了。

這時候，無捕獲區域修飾符 (?i:…) 就是我們的終極武器。它允許我們僅針對括號內的局部範圍開啟忽略大小寫功能，完全不會污染全域的駝峰規則！

👨‍💻 終極代碼實戰

讓我們直接看代碼，感受一下這套「連招」的優雅與強大：

import re

test_targets = [
    "PCIeStatusInfo",
    "VGAAutoProcessStep",
    "USBtypeCConnection"   # 最棘手的終極王王挑戰
]

# 1. 定義通用規則：用來拆連續大寫(Acronym)與駝峰字，[必須保持大小寫敏感！]
base_pattern = r'[A-Z]?[a-z]+|[A-Z]+(?=[A-Z][a-z]|\d|\W|$)|\d+'

# 2. 定義不能被破壞的術語清單
exceptions = ['PCIe', 'NVMe', 'typeC', 'USB']

# 把清單用 | 串接起來 -> PCIe|NVMe|typeC|USB
exception_str = '|'.join(exceptions)

# 3. ✨ 超級關鍵解法 ✨
# 使用 (?i:{...}) 語法創造防護罩，再接上絕對不能忽略大小寫的 base_pattern
good_pattern = f"(?i:{exception_str})|{base_pattern}"

# 編譯 (注意！絕對不要加 re.IGNORECASE)
good_regex = re.compile(good_pattern)

print("--- 完美的提取結果 ---")
for text in test_targets:
    result = good_regex.findall(text)
    print(f"原本: {text:25} -> 拆出: {result}")