很多人第一次接觸“設(shè)置字符排序器”的時候以為這就是給一個sort()換換參數(shù)的事。直到某個同事拿著員工名單來問我按姓名排了序為什么姓“張”的排到姓“A”的后面他看著列表覺得哪里不對但自己也說不清問題在哪。我讓他描述一下排序規(guī)則他說“按姓名排”。問題就出在這里——“按姓名排”根本不是一條排序規(guī)則它只是一句需求描述。真正的規(guī)則可以是按拼音、按筆畫、按 Unicode 碼點、按字母忽略大小寫、把中文單獨拎出來放到末尾每一種都叫“按姓名排”但結(jié)果截然不同。所以“設(shè)置字符排序器”這件事表面上是配置一個小工具實際上是把業(yè)務(wù)預(yù)期翻譯成可執(zhí)行規(guī)則的過程。這篇文章想聊的就是中間那些容易被跳過的環(huán)節(jié)字符怎么定義、語言規(guī)則怎么選、數(shù)據(jù)庫怎么配合、中文和數(shù)字怎么處理以及上線之后如何排查“排序不對”的問題。搞不清這一層工具越智能它“錯”得越絲滑。1. 先回答一個問題你排隊的是“字符”還是“字符串”1.1 你看到的字符不一定是程序眼里的一個單位很多排序問題根本不是排序規(guī)則錯了而是“字符”這個基礎(chǔ)概念沒有對齊。程序里的一個“字符”可能有三種存在形態(tài)你肉眼看到的一個字形例如é。內(nèi)存里的一個 Unicode 碼點例如U00E9。多個碼點拼成的組合序列例如字母e后面再跟一個組合重音符U0301渲染出來同樣是é。這意味著如果你沒有做標準化處理同一個“é”在一種輸入來源里是 1 個單元在另一種來源里是 2 個單元。排序時它們就可能被排到完全不同的位置。用戶看起來是同一個詞程序卻不認。類似的坑還出現(xiàn)在全角半角、各種不可見字符和不同種類的空格上。所以在常見實踐里設(shè)置字符排序器的第一步不是調(diào)比較函數(shù)而是清洗和標準化。Unicode 提供了 NFC、NFD、NFKC、NFKD 等規(guī)范化形式具體選哪種要看后續(xù)業(yè)務(wù)是匹配還是排序但至少排序前要保證同一份數(shù)據(jù)用的是同一種形態(tài)。不同來源的數(shù)據(jù)寧可統(tǒng)一成同一種 NFC 或 NFD 再進排序器否則后面會花大量時間排查“為什么這兩條內(nèi)容沒排在一起”。1.2 排序單元和輸入形態(tài)也要先定清楚另一個容易被忽略的問題是你要排的單元是“單個字符”還是“整條字符串”。按姓名首字排、按整條姓名排、按姓排完再按名排邏輯都不一樣。拿“歐陽修”和“王偉”來說如果按首字比較歐陽修進入 O 序列王偉進入 W 序列兩者沒有交叉但如果規(guī)則是“按整條字符串的拼音”排歐陽修ouyangxiu和王偉wangwei仍然會落在不同區(qū)間?？雌饋斫Y(jié)果碰巧一致可一旦出現(xiàn)同姓或者首字相同的情況排序單元的選擇就會直接決定順序。訂單號、序列號、文件名也是類似情況。有些字段表面是“字符”實際是用來做編號的數(shù)字有些字段是“字符合成的業(yè)務(wù)鍵”必須按完整串比較。這些定義沒定下來后續(xù)所有規(guī)則都是空中樓閣。我的建議是在寫任何排序代碼之前先寫出你這批數(shù)據(jù)的單元定義和來源清單哪些字段需要先標準化哪些字段空值怎么處理哪些字段存在全半角混用。這一頁紙比調(diào)試三次排序都有用。2. 默認排序沒有錯它只是不知道你要什么2.1 為什么默認排序結(jié)果總讓人覺得“不對”大多數(shù)編程語言內(nèi)置的默認排序采用的是“碼點順序”。Python 的sorted()JavaScript 數(shù)組默認的sort()C 的std::string逐字典序比較本質(zhì)上都是按字符在字符集里的數(shù)字編號排列。這種規(guī)則的好處是快、確定、跨環(huán)境可復(fù)現(xiàn)。但它沒有任何語言語義。最典型的表現(xiàn)就是大小寫混合時大寫字母會先于小寫字母出現(xiàn)。比如一組字符串a(chǎn)pple、Banana、cherry按碼點默認排Banana會排在最前面因為B的碼點是 66而a是 97。人習(xí)慣的字典序至少是大小寫不敏感的比較結(jié)果往往不一樣。這不是工具的 bug。默認排序的設(shè)計目標是“機器最容易執(zhí)行的順序”不是“人最容易接受的順序”。只要你沒有告訴系統(tǒng)你要按什么語言規(guī)則、什么大小寫敏感度、什么重音規(guī)則排序它就只能給你一個不帶語義的結(jié)果。2.2 數(shù)字字符串和穩(wěn)定性的兩個細節(jié)數(shù)字字符串是另一個高頻翻車點?！?0”和“9”按字符串比較時“10”會排在“9”前面因為第一個字符是“1”而“1”小于“9”。這不是算法錯誤是類型語義問題你讓字符串排序器去排一串本來是數(shù)字的編號它當然按字符串來理解。但這里有一個值得單獨拎出來的點穩(wěn)定排序和確定性不是一回事。穩(wěn)定排序指的是兩個相等的元素在排序后保持原來的相對順序這在多級排序時特別有用。確定性則是指同一份輸入每次都能得到同一份輸出。默認排序很快就很穩(wěn)定但它的“確定”只針對你自己的環(huán)境一旦換到數(shù)據(jù)庫、操作系統(tǒng)或另一個語言運行時默認的 locale 數(shù)據(jù)可能不一樣結(jié)果也可能不一樣。所以“在我機器上是確定的”這種經(jīng)驗并不可靠。3. Locale 與 Collation 才是字符排序器的核心3.1 把排序規(guī)則想象成一層一層的比較在行業(yè)里排序規(guī)則有一個更正式的名字collation也就是“排序規(guī)則”或“對照規(guī)則”。它通常不是單一開關(guān)而是按層次比較的一組規(guī)則。比較級別比較內(nèi)容例子主級別基礎(chǔ)字母a、A、á 視為同一基礎(chǔ)字母次級別重音/變音符é 和 e 的區(qū)別第三級別大小寫A 和 a 的區(qū)別第四級別標點等特殊符號- 和中橫線的區(qū)別不同 locale 對同一串字符的定序可能不同。在德語里?通常被當作a的近親在瑞典語里?則可能排在字母表末尾。字典排序和電話簿排序?qū)χ匾舻奶幚硪膊煌耆粯?。這就是為什么“排序”不能只看表面一套規(guī)則能同時決定字母、重音、大小寫和標點的先后業(yè)務(wù)方通常只說出了其中一半。3.2 數(shù)據(jù)庫把 COLLATE 當作表結(jié)構(gòu)的一部分數(shù)據(jù)庫里最容易踩坑的地方就是建庫建表時沒有顯式指定排序規(guī)則全程依賴默認值。以 MySQL 這類常見數(shù)據(jù)庫為例常見的排序規(guī)則后綴已經(jīng)能透出行為差異_ci表示大小寫不敏感_ai表示重音不敏感unicode_ci大致基于 Unicode 排序規(guī)則實現(xiàn)0900系列對應(yīng)較新的 Unicode 排序規(guī)則版本一般出現(xiàn)在 MySQL 8.0 及之后這里我不打算替你做選型因為具體差異要結(jié)合你的數(shù)據(jù)庫版本和業(yè)務(wù)要求。我更想強調(diào)的是維護方式排序規(guī)則應(yīng)該作為表結(jié)構(gòu)的一部分被管理而不是等到查詢階段才臨時依賴數(shù)據(jù)庫默認值。原因很簡單如果你先建了庫、導(dǎo)了數(shù)據(jù)再回頭改排序規(guī)則可能面臨索引重建、字符串比較行為變化甚至潛在的數(shù)據(jù)遷移風(fēng)險。項目初期就把COLLATE顯式寫進建表腳本等于提前定義好了“這套數(shù)據(jù)對外承諾的順序語義”。3.3 應(yīng)用層選擇統(tǒng)一的比較入口應(yīng)用層處理排序時常見的幾種做法各有邊界。Python 里locale.strxfrm可以生成按當前 locale 排序的鍵但它依賴操作系統(tǒng)安裝的 locale 數(shù)據(jù)換一臺機器結(jié)果可能不一致。JavaScript 里Intl.Collator更直接可以傳 locale 和選項比如new Intl.Collator(zh-Hans-CN, { numeric: true, sensitivity: base })語義清楚跨瀏覽器和 Node 環(huán)境的差異也相對小。如果業(yè)務(wù)規(guī)則很重或者要在多種語言環(huán)境里保持一致更建議直接用 ICU 這一類封裝好的排序?qū)崿F(xiàn)?，F(xiàn)在不少運行時內(nèi)部跑的就是 ICU 的 collation選擇一個成熟實現(xiàn)能少造很多輪子。這里的關(guān)鍵不是推薦某個庫而是建議你全項目只保留一個統(tǒng)一比較入口。不要前端排一次、后端排一次、報表再排一次否則三份結(jié)果大概率對不齊。4. 中文場景拼音、筆畫還是業(yè)務(wù)自定義4.1 中文沒有“天然順序”只有業(yè)務(wù)規(guī)則中文排序和英文字母排序有一個本質(zhì)區(qū)別漢字在 Unicode 里的碼點是按區(qū)段連續(xù)分配的和拼音、筆畫都沒有穩(wěn)定對應(yīng)關(guān)系。所以默認排序一遇到漢字結(jié)果在人類眼里基本等于隨機順序。中文排序最常見的業(yè)務(wù)規(guī)則有幾種按拼音最常用適合客戶名單、城市列表、菜單項排序。按筆畫適合人名清單、部分法律文書和字典附錄場景。按部首常見于工具書和字典場景普通業(yè)務(wù)很少用到。按業(yè)務(wù)權(quán)重比如把高頻用戶排前面這是業(yè)務(wù)排序不應(yīng)該塞進字符排序器里應(yīng)該用獨立字段實現(xiàn)。4.2 最常用的三層取舍拼音、筆畫、兜底鍵按拼音排是最常見的需求但“按拼音”本身也不是一條完整規(guī)則。拼音之后還有同音字同音字之后還有多音字多音字之后還有讀音完全相同的生僻字。沒有兜底邏輯排序結(jié)果就無法穩(wěn)定。多數(shù)現(xiàn)代運行環(huán)境里zh相關(guān) locale 在 CLDR 規(guī)則下默認近似按拼音排序。這里要強調(diào)“近似”不同版本、不同規(guī)范對多音字、變體字和同音字的細節(jié)處理并不完全一致。如果業(yè)務(wù)對順序有嚴格要求比如內(nèi)部通訊錄必須按拼音排同音時再按筆畫排那就不要依賴 locale 默認值而是要自己定制比較鏈先拼出拼音鍵再比筆畫數(shù)最后比碼點作為最終兜底。這種三層規(guī)則寫出來并不復(fù)雜但必須在項目文檔里留底。否則半年后接手的人看到一段“按拼音排”的注釋并不知道后面還藏著同音、多音和筆畫三個層級。4.3 中英混排和姓名類數(shù)據(jù)的邊界中英混排要提前回答一個問題中文是排在英文前面還是和英文混在一起排如果選擇混排按拼音的a、b、c和英文的A、B、C怎么銜接需要專門定義。常見做法是把中文轉(zhuǎn)成拼音或拉丁鍵之后統(tǒng)一按字母序排或者在中英文之間設(shè)定明確的邊界規(guī)則。沒有標準答案只有業(yè)務(wù)定義。姓名類數(shù)據(jù)還有一個額外邊界姓和名要不要分開處理?！皻W陽修”是一個復(fù)姓單名如果按首字拼音歐陽修落在 O 段如果按“姓”的完整拼音歐陽修仍然落在 O 段。但遇到“歐陽”和“歐”這種前綴關(guān)系時規(guī)則就會決定誰先誰后。這類邊界問題不止中文有只是中文姓名結(jié)構(gòu)會讓它更明顯。設(shè)置字符排序器之前建議先把姓名組成部分、是否支持復(fù)姓、生僻字兜底策略都列出來。5. 自然排序像人一樣對待數(shù)字5.1 人的自然順序和機器默認順序是兩套邏輯文件排序是自然排序最經(jīng)典的場景。file9、file10、file100如果按默認字符串比較得到的是file10、file100、file9因為逐字符比較時1小于9。人想看到的是file9、file10、file100。版本號也同理。v1.9.2和v1.10.0按字符串排會把v1.10.0放在v1.9.2前面按數(shù)字段理解1.10才應(yīng)該大于1.9。自然排序的基本做法是把字符串按“數(shù)字段”和“非數(shù)字段”切成 token然后逐段比較數(shù)字段按數(shù)值比較非數(shù)字段按原來的字符規(guī)則比較。這樣既保留了字典序的語義又讓數(shù)字段按人的直覺工作。5.2 數(shù)字段拆分的通用做法與常見坑以下是一個通用處理思路具體實現(xiàn)要結(jié)合你的語言和數(shù)據(jù)結(jié)構(gòu)把原始字符串拆成兩部分 token - 數(shù)字段連續(xù)的 0-9 字符按數(shù)值比較 - 非數(shù)字段保持原有字符比較規(guī)則 - 兩個 token 比較時數(shù)字段和非數(shù)字段按類型決定比較方式實踐中有幾個容易出問題的點前導(dǎo)零。01和1數(shù)值相同但展示層可能希望它們不同序。如果不做區(qū)分會出現(xiàn)不穩(wěn)定排序。小數(shù)、負數(shù)、科學(xué)計數(shù)法。文件編號和數(shù)值計算用的數(shù)字語義并不一樣。版本號語義不一定等于自然排序。1.0.1和1.0之間的關(guān)系可能需要專門的版本比較器。分隔符數(shù)量不一致。a和a.1誰在前有時候要靠業(yè)務(wù)規(guī)則而不是靠通用比較器。5.3 規(guī)則復(fù)雜時先生成排序鍵如果業(yè)務(wù)規(guī)則比較復(fù)雜比如要按拼音、筆畫、數(shù)字段、全半角統(tǒng)一等多層規(guī)則排序每次查詢時現(xiàn)場計算會比較吃力而且不同客戶端很容易算出不同結(jié)果。更工程化的做法是寫入數(shù)據(jù)時按規(guī)則生成一個“排序鍵”存成專門字段。查詢時直接ORDER BY sort_key展示時再讀原始字段。排序鍵可以是一段補零后的數(shù)字也可以是某個排序庫生成的 collation key。這種做法的代價是額外存儲和更新成本收益是查詢快、各端結(jié)果一致、規(guī)則變更時可以批量重算。這里要注意維護紀律排序鍵屬于冗余數(shù)據(jù)數(shù)據(jù)本身的拼音、編號、名稱一旦變化排序鍵必須同步更新。否則就會出現(xiàn)“展示內(nèi)容和排列順序?qū)Σ簧稀钡脑幃悊栴}。6. 設(shè)置字符排序器的五步落地流程6.1 第一步把業(yè)務(wù)預(yù)期變成 20 條樣例設(shè)置字符排序器最怕的不是代碼復(fù)雜而是業(yè)務(wù)自己也沒想清楚規(guī)則。最有效的方式是拿 20 到 30 條真實數(shù)據(jù)讓業(yè)務(wù)方先手工排出一個“正確”順序這個過程會把模糊的“按名字排”逼成具體的“按拼音同音按筆畫再不行按碼點”。樣例要覆蓋足夠多的邊界類型樣例類型示例期望驗證的點純英文大小寫B(tài)anana、apple、Cherry大小寫敏感度帶重音字母café、cafe重音是否參與比較中文姓名張三、張偉、歐陽修拼音、同音、復(fù)姓數(shù)字開頭/結(jié)尾file9、file10、v1.10自然排序空字符串與 null空串、空白字符空值策略全半角混用、ABC輸入標準化人工排序那一步本身就是幫業(yè)務(wù)方梳理規(guī)則的過程。很多團隊做完這步才發(fā)現(xiàn)最初的排序預(yù)期在讀數(shù)上根本站不住腳。6.2 第二步?jīng)Q定排序發(fā)生在哪一層排序可以發(fā)生在數(shù)據(jù)庫、應(yīng)用層、排序服務(wù)或者寫入時的排序鍵生成階段。選擇依據(jù)主要看數(shù)據(jù)量和一致性要求。數(shù)據(jù)量大、查詢直接出列表優(yōu)先在數(shù)據(jù)庫用顯式COLLATE解決配合索引。數(shù)據(jù)來自多個來源、規(guī)則復(fù)雜在應(yīng)用層用統(tǒng)一 comparator 處理。規(guī)則需要被多個客戶端復(fù)用抽象成排序服務(wù)或直接生成排序鍵下發(fā)。最怕的情況是每個客戶端各寫一份排序邏輯。最后對不齊的時候連排查入口都找不到。6.3 第三步小樣本驗證寫好排序代碼后不要急著全量跑。把第一步人工排好的樣例集輸入排序器逐條比對輸出和人工順序。如果結(jié)果不一致先區(qū)分兩類差異一類是輸入清洗問題比如全半角沒統(tǒng)一、不可見字符干擾另一類是排序規(guī)則本身的理解差異。前者修標準化后者改比較邏輯。很多時候你會發(fā)現(xiàn)業(yè)務(wù)方最初手排的順序和項目實際需要的順序并不一樣。這不是程序錯了而是規(guī)則定義變了。把差異記錄下來更新樣例集再跑一遍。6.4 第四步把排序樣例固化成回歸測試排序是典型的“一眼看不出問題”的功能。改動一個依賴版本、升級一次運行時、換一個操作系統(tǒng)排序行為都可能悄悄變化。所以建議把人工排好的樣例集和最終排序結(jié)果一起寫進 CI。以后只要有人改排序相關(guān)代碼、升級數(shù)據(jù)庫或運行環(huán)境就自動跑一遍對比。那些看似微小但可能影響列表頁、導(dǎo)出文件、搜索關(guān)聯(lián)結(jié)果的“順序變化”就能在上線前被發(fā)現(xiàn)。排序規(guī)則越復(fù)雜這套回歸測試的價值越大。6.5 第五步固定一套排查鏈路上線之后“排序不對”的反饋一定會來。與其每次從頭排查不如固定一個順序先看原始輸入。有沒有不可見字符、全半角、大小寫、重音、前后空格。再看標準化。多來源數(shù)據(jù)是否統(tǒng)一成同一種 Unicode 規(guī)范化形式。再看執(zhí)行層。數(shù)據(jù)庫COLLATE是否顯式設(shè)置應(yīng)用層 comparator 是否帶了正確 locale 和選項。再看特殊字符。數(shù)字、連字符、小數(shù)點、emoji 等是否被當成普通字符比較。最后看規(guī)則版本。依賴的排序庫、運行時或數(shù)據(jù)庫升級后默認行為是否改變。這個順序能覆蓋大多數(shù)排序問題的真實原因輸入層的問題占多數(shù)規(guī)則層次之工具本身的問題最少。設(shè)置字符排序器表面是配置一個工具本質(zhì)上是在給業(yè)務(wù)定義一套可執(zhí)行的“順序公約”。排序不是上線前一次性搞定的清洗動作而是一個會被反復(fù)調(diào)用的基礎(chǔ)能力。我的建議是最早花半天把樣例集和規(guī)則寫下來比上線后再為每一次“奇怪的順序”逐個排查要劃算得多。你可以從 20 條真實數(shù)據(jù)開始先手工排一遍——往往排完你就發(fā)現(xiàn)自己原來以為清楚的規(guī)則其實從來沒被寫清楚過。