蒐集：銀行目前對於使用中的中文字碼資料轉換的做法或是機制仍有未盡人意或是尚未解決的議題

一、銀行主機的中文字碼問題

原文提到：

以台灣的銀行業來說，主機的編碼並不為 Big5 或 UTF-8，更不是國家中文標準交換碼 CNS11643 或是戶役政系統使用的 EUC，所以當進行通匯交易，資料傳送給財金時，就必須要經過轉碼。

1. 主機內部編碼不等於中文字碼標準

銀行主機，尤其是傳統大型主機環境，可能採用：

• IBM EBCDIC 系列的字元編碼。
• 特定 Code Page 的雙位元組中文字碼。
• 廠商自行定義的中文字碼表。
• 以內碼、外碼及造字區域組成的混合式字碼管理機制。

因此，問題不只是「主機不是 Big5 或 UTF-8」，而是：主機內部的字元表示方式，與外部系統所要求的字元編碼、字元集合及字形定義，未必具有一對一的對應關係。例如，同一個中文字在不同編碼系統中，可能有不同的碼位；而某些銀行內部造字，在外部標準中根本找不到對應字元。這種情況下，轉碼就不只是單純的 byte-to-byte conversion。

2. CNS 11643 與 EUC 的概念區分

CNS 11643 是中文標準交換碼的字元編碼標準，涵蓋多個字面（Plane）；EUC 則是一種延伸 Unix Code 的編碼架構。例如 EUC-TW 是一種可表示 CNS 11643 多個字面的編碼方式。因此，嚴格來說，不能將 CNS 11643 與 EUC 當成完全相同層級的編碼名稱。另外，戶役政系統所使用的字碼，也不宜直接概括為 EUC。實際使用的編碼、字碼表、造字區及交換介面，仍須依系統版本與介接規格確認。

這個差異很重要，因為銀行與政府系統交換資料時，真正需要確認的通常包括：

• 字元編碼（Encoding）
• 字元集合（Character Set）
• 字碼對應表（Mapping Table）
• 造字及特殊字處理規則
• 轉碼失敗時的處理方式

二、真正困難的是「難字」

原文提到：

此時就會有難字的字碼需要處理的問題。

這其實是整個議題的核心。在傳統金融系統中，難字問題通常有幾個不同層次。

其中，最容易被忽略的是最後兩項。

字形相同，不代表字碼相同

例如，某些中文字在不同標準中可能具有相同或極為接近的字形，但其字碼並不相同。如果系統只根據字形進行對應，可能會把原本不同的字元合併。這對一般文件而言，可能只是顯示上的差異；但對銀行來說，卻可能影響：

• 客戶姓名
• 法定身分資料
• 帳戶持有人識別
• AML 名單比對
• 跨境匯款受款人資料
• 法律文件及交易憑證

因此，轉碼後不只要「看起來一樣」，還需確認字元是否仍然一致。

三、滿天星與優利碼

原文提到：

經過多年的發展，市面上也有提供各種轉碼程式，更有造字、轉碼、字型等轉換的 package，以金融業來說，使用的最多的應該是滿天星的系統。

回覆者提到：

老行庫應該還有優利碼，轉碼的部份，目前各行庫考量的多半是整合現行各種編碼，不過仍在正體中文部分處理。

這裡反映一個重要的金融資訊架構問題：銀行使用的轉碼套件，往往不只是轉碼工具，而是長期累積的中文字碼管理基礎設施。這類系統可能同時處理：

1. 內部字碼與外部標準的對應。
2. 造字管理與字形維護。
3. 不同系統之間的轉碼。
4. 主機與分行系統的資料交換。
5. 報表、列印及螢幕顯示。
6. 特殊字元的替代及錯誤處理。

因此，即使銀行逐步導入 Unicode，也不代表原有的轉碼系統就能直接退場。因為真正的問題不只是將舊編碼轉成 Unicode，而是如何保留既有資料的識別能力。例如，假設銀行內部有一個自行造字的客戶姓名字元：

• 舊系統以內部碼 A123 表示。
• 新系統將其轉成 Unicode。
• 外部系統可能沒有相同的字元。
• 新系統如果只保留替代字元，就可能失去原始字碼資訊。

這時候，銀行需要的不只是轉碼程式，而是能夠維持字碼映射、造字識別及歷史資料追溯的機制。

四、大陸分行的正簡中文處理

回覆者提出：

個人較為好奇的是有部分行庫在大陸分行的系統是自行開發的，若以現行主機運作，那正體與簡體中文的處理方式為何？

它涉及的並不是單純的繁體中文轉簡體中文，而是兩種不同的文字環境如何共存。

1. 繁簡轉換不是單純的字碼轉換

例如：

• 「銀行」與「银行」
• 「發展」與「发展」
• 「後台」與「后台」

這些字詞在繁簡轉換時，可能涉及字形轉換，也可能涉及語意差異。更重要的是，簡體中文與繁體中文之間並非一對一映射。例如：

• 「髮」與「發」在簡體中文中都可能轉為「发」。
• 「後」與「后」在簡體中文中都可能使用「后」。

這意味著，如果銀行將繁體中文轉換為簡體中文，再將簡體中文轉回繁體中文，原始資料可能無法完整還原。這對金融系統來說，是一個需要嚴肅處理的資料完整性問題。

2. 兩岸系統可能需要不同的字碼管理層

若台灣銀行的核心系統採用既有主機字碼，而大陸分行的系統採用另一套中文編碼環境，較合理的架構可能是：

• 核心系統保留原始客戶資料。
• 介接層負責字碼轉換。
• 分行系統使用符合當地需求的字元編碼。
• 交易資料保留來源及必要的原始字碼資訊。
• 顯示、列印及法定文件使用各自適當的字形。

這裡的關鍵在於：資料交換時的文字表示方式，可以不同；但客戶的身分識別及交易語意，必須保持一致。

五、AML 與 ECIF

原文最後提到：

加上 AML 和 ECIF，這就不是單單的轉碼程式可以解決了～

這是整段討論中最值得延伸的觀點。因為 AML 與 ECIF 的問題，已經從字碼轉換進入資料治理與身分識別。

1. ECIF：客戶資料一致性

ECIF（Enterprise Customer Information File）通常是銀行企業級客戶資訊整合機制。當銀行不同系統對同一個客戶使用不同的中文字碼表示方式時，可能出現：

• 同一客戶在不同系統中的姓名不一致。
• 客戶主檔與交易資料的字元無法完全對應。
• 造字與標準字碼混用。
• 客戶資料整併時產生重複或錯誤匹配。

如果 ECIF 只以姓名字串作為比對條件，這些問題就可能被放大。但姓名比對本來就不能只依賴字串完全相等。應該同時考慮客戶識別碼、身分證明文件、國籍、出生日期及其他可用的識別資訊。

2. AML：字元轉換可能影響名單比對

AML（Anti-Money Laundering）涉及客戶審查、制裁名單及交易監控。例如，同一個人的姓名可能存在：

• 繁體中文版本。
• 簡體中文版本。
• 英文拼音版本。
• 不同字碼或異體字版本。

如果 AML 系統只進行字串完全比對，就可能造成誤判或漏判。因此，AML 名單比對可能需要結合：

• Unicode 正規化（Normalization）。
• 繁簡字形轉換。
• 異體字處理。
• 英文姓名及拼音變體。
• 模糊比對（Fuzzy Matching）。
• 多項身分識別資訊。

文字正規化可以協助比對，但不應直接改寫客戶的原始法定姓名。比對用的正規化資料與正式客戶資料，應該是不同的資料層次。

六、值得討論的幾個問題

從轉碼程式走向企業級字元服務

在現代化架構中，適合將中文字碼管理獨立成一個企業級服務，負責：

• 統一字碼映射。
• 造字管理。
• Unicode 正規化。
• 繁簡字形轉換。
• 原始資料保留。
• 轉換錯誤及例外處理。
• 字碼版本管理及稽核。

這樣的服務不應只是提供 convert(input, targetEncoding) 之類的函式，而是必須能夠處理資料來源、轉換規則、例外情境及可追溯性。

總結

這討論提出了一個很有價值的問題：當銀行的核心系統從傳統主機走向 Unicode、API 及跨境整合時，中文字碼問題究竟應該被視為技術債，還是企業資料治理的一部分？這已經不只是主機轉碼的問題。尤其在 AML、ECIF、跨境匯款及客戶資料整合等場景中，中文字碼管理與客戶身分識別、資料完整性及法遵風險有直接關係。

真正的挑戰是：如何讓不同系統使用不同的字元編碼與文字表示方式，卻仍然能夠維持同一個客戶、同一筆交易及同一份法定資料的語意一致性。這也是為什麼，即使 Unicode 已經成為現代資訊系統的主流，金融業仍然可能需要長期維護既有的中文字碼管理機制。