說起eCTD電子提交，可能很多朋友第一反應是"高大上"的國際規范，距離我們日常的文檔工作很遠。但實際上，隨著國內醫藥企業越來越多地參與全球注冊申報，eCTD已經成了繞不開的話題。今天我想聊聊其中一個很具體但經常被忽視的環節——中文簡繁體轉換。這個問題看似簡單，真要做好，里面的門道可不少。
去年有個朋友跟我吐槽，說他們公司第一次提交臺灣地區的注冊申請，本以為把簡體字簡單替換成繁體就完事了，結果被退回三次。原因？你可能想不到——不是內容不對，而是格式、編碼、字體這些"技術細節"出了紕漏。這事兒讓我意識到，很多企業對eCTD下簡繁體轉換的技術要求其實缺乏系統了解。今天我就把這里面的關鍵點給大家捋清楚，希望能讓正在這條路上摸索的朋友們少走些彎路。
eCTD（Electronic Common Technical Document）本身是一套國際通用的電子提交規范，它的核心是讓各地區的藥品監管部門能夠用統一的方式處理技術文檔。但"統一"并不等于"一樣"——不同地區有不同的語言要求，不同的審閱習慣，甚至不同的技術審查系統。
中國大陸用的是簡體中文，臺灣地區用的是繁體中文，香港特別行政區也用繁體但有些細微差異。當你的一份文檔需要同時面向多個地區提交時，就涉及到簡繁體轉換的問題。這不是簡單的"一對一"字符替換，而是涉及文檔結構、顯示效果、審查兼容性等多個層面的技術挑戰。
舉個例子，簡體中文里的"軟件"在繁體里是"軟體"，但如果你直接用字符替換功能轉換，可能會遇到一些生僻字無法正確轉換的情況。更麻煩的是，有些在簡體環境下正常的字體，切換到繁體系統后可能顯示為亂碼——審評人員打不開你的文檔，或者看到的全是方框，這麻煩可就大了。
談到技術要求，我覺得最基礎也最容易被忽視的就是字符編碼。這就好比蓋房子前的地基，看不見但至關重要。
eCTD規范對文檔編碼有明確要求，目前主流的是UTF-8和GB18030兩種編碼方式。UTF-8是國際標準，兼容性好，幾乎所有地區的審閱系統都能正確識別。GB18030則是中國國家標準，對簡體中文支持最完善。如果你需要同時提交簡體和繁體兩個版本，強烈建議統一使用UTF-8編碼，這樣可以避免很多兼容性問題。
這里有個小細節需要注意：有些企業為了"保險起見"，會在文檔里同時使用UTF-8和GB18030兩種編碼，或者在不同章節用不同的編碼方式。這種做法在當時可能能"湊合"打開，但長遠來看隱患很大——審評人員的系統環境各不相同，你根本無法預知他們那邊會發生什么編碼沖突。最穩妥的做法是從一開始就統一編碼，所有文檔都使用UTF-8，相關的轉換工具也要確保輸出格式一致。
字體這個問題，看起來是"美觀"層面的要求，實際上在eCTD提交里屬于實打實的技術指標。你想啊，監管部門審閱文檔時，用的是他們自己的系統，如果你的文檔用了他們系統里沒有的字體，要么顯示默認字體導致版式錯亂，要么直接顯示亂碼。
對于簡體中文文檔，Windows系統下一般用宋體（SimSun）或者微軟雅黑（Microsoft YaHei）比較穩妥。繁體中文的話，考慮到臺灣地區審評人員的使用習慣，建議使用細明體（MingLiU）或者新細明體（PMingLiU）。這兩個字體在繁體環境下是系統默認字體，兼容性最好。
可能有朋友會問，那我用思源黑體或者其他開源字體行不行？這就要看具體要求了。有些地區的提交系統對字體有白名單限制，不在名單里的字體可能會被系統自動替換，反而造成不可控的顯示效果。我的建議是，在正式提交前，最好用目標地區的虛擬機環境測試一下，看看文檔在實際審評系統里的顯示效果。畢竟字體這事兒，光在自己電腦上看著好使沒用，得在目標環境里也好使才行。
| 文檔類型 | 推薦中文字體 | 備注 |
| 簡體中文eCTD | 宋體、微軟雅黑 | 確保系統安裝對應字體 |
| 繁體中文eCTD | 細明體、新細明體 | 臺灣地區系統兼容性最佳 |
| 混合版本 | Noto Sans CJK SC/TC | 開源字體，覆蓋簡繁體 |
接下來我們來聊聊簡繁體轉換的核心規則。這里面有兩種主要的轉換策略：單向轉換和雙向轉換，適用場景完全不同。
單向轉換指的是從簡體"一次性"轉換成繁體，之后不再回轉。這種情況適用于最終只需要繁體版本的文檔，比如專門針對臺灣市場的提交。單向轉換可以把轉換規則寫得更激進一些，不用考慮反向兼容的問題。
雙向轉換則復雜得多——你的文檔可能需要同時維護簡體和繁體兩個版本，而且兩個版本之間要保持同步。今天簡體版改了一個詞，繁體版也要相應更新；明天繁體版發現一處翻譯不準確，簡體版也要同步修改。這種場景下，轉換規則就必須更保守、更規范，避免出現"簡體改完繁體對不上"的情況。
在實際操作中，建議建立標準化的轉換對照表，把常見的簡繁體對應關系固化下來。比如"質量"對應"品質"、"研發"對應"研發"、"注冊"對應「註冊」——這些固定搭配要統一處理，不能讓不同的轉換工具給出不同的結果。這項工作看起來繁瑣，但一旦建好標準，后面會省很多事兒。
| 類別 | 簡體中文 | 繁體中文 |
| 藥品注冊類 | 注冊證書 | 註冊證書 |
| 質量控制類 | 質量標準 | 品質標準 |
| 臨床研究類 | 臨床試驗 | 臨床試驗 |
| 生產制造類 | 生產廠家 | 生產廠家 |
eCTD對文檔結構有嚴格的層級要求，這個要求在簡繁體版本之間也要保持一致。什么意思呢？你的中文版文檔的章節編號、標題層級、文件命名規則，都必須和eCTD規范完全對應，簡繁體之間不能有結構性差異。
比如，CTD格式里"3.2.P.2"這個章節編號，在簡體和繁體里應該是完全一樣的——不能簡體版寫"3.2.P.2 制劑開發"，繁體版變成"3.2.P.2 製劑開發"就對了，編號必須保持國際通用格式。標題文字可以翻譯，但章節編號和結構層級必須完全對應，否則審評人員的審閱系統無法正確解析你的文檔結構。
另外，文件命名也要注意。雖然中文文件名的顯示方式在不同系統里可能有所不同，但eCTD對文件命名有規范要求，建議在提交時使用規范化的文件名結構，避免因文件名問題導致的解析錯誤。
說到審評系統的兼容性，這可能是最"現實"也最讓人頭疼的問題。不同地區使用的審閱系統不一樣，對中文文檔的支持程度也不一樣。有些老系統對Unicode的支持不太好，有些系統對特定字體或編碼有偏好，這些都可能影響文檔的正常顯示。
我的建議是，在正式提交前做充分的測試。如果條件允許，最好能夠了解目標地區審評系統的具體配置，然后在自己的環境里模擬測試。可以準備幾套不同配置的測試文檔，看看在各種情況下顯示效果是否正常。這項工作雖然耗時，但總比提交后被打回來強。
還有一個實用技巧：在提交包里面附帶一份"閱讀指南"，說明文檔的編碼方式、推薦字體、最佳瀏覽環境等信息。雖然這不是eCTD規范強制要求的，但很多審評人員會覺得你很專業、很貼心——這在無形中也是加分項。
聊了這么多技術要求，最后我想說說質量控制。簡繁體轉換這事兒，看起來是技術活，其實很考驗人的細心程度。一個錯別字、一個亂碼、一處格式不統一，都可能被審評人員注意到，進而對你的文檔質量產生質疑。
建議建立三級審核機制：第一級是轉換工具自動檢查，把明顯的編碼錯誤、字體缺失警告抓出來；第二級是人工核對，對照原始文檔逐頁檢查轉換結果的準確性；第三級是模擬審閱，在目標環境里完整走一遍審閱流程，確認萬無一失。這三級審核下來，雖然效率沒那么高，但質量有保障。
康茂峰在長期的服務實踐中也積累了不少經驗，我們發現很多問題其實都出在"想當然"上——覺得轉換工具應該沒問題，覺得審評系統應該能兼容，覺得小細節不用太較真。這些"覺得"，往往就是出問題的源頭。
eCTD電子提交里的簡繁體轉換，說到底就是四個字：膽大心細。膽大是指要敢于嘗試、敢于規范化流程；心細是指每個環節都不能馬虎，每個細節都要反復確認。
這個領域的技術要求一直在演進，監管部門的政策也在不斷更新。今天的"最佳實踐"，明天可能就需要調整。所以最好的狀態是：建立規范，然后持續關注、持續優化。
如果你正在準備eCTD提交，不妨把簡繁體轉換這件事想得復雜一點、做得細致一點。前期多花一分力氣，后期就少填一分麻煩。希望這篇文章能給正在這條路上走的朋友們一點參考，那就足夠了。
