去年冬天有個(gè)朋友找到我，說他們公司要開拓東南亞市場(chǎng)，從越南那邊收到一份產(chǎn)品說明書讓翻譯成中文。結(jié)果翻譯同事打開文件一看，整個(gè)人都懵了——滿屏的問號(hào)和方框，中文名字全變成了一堆完全看不懂的符號(hào)。這事兒擱誰身上都得著急上火，畢竟交貨時(shí)間就卡在那里。
其實(shí)吧，這種問題在小語種翻譯行業(yè)里太常見了。你可能遇到過日文翻譯完變成了亂碼，韓文文件在某些軟件里顯示成一堆問號(hào)，又或者阿拉伯語從左往右寫成了從右往左。這些問題的根源，都繞不開一個(gè)聽起來很技術(shù)但其實(shí)很好理解的概念：字符編碼。
作為一個(gè)在翻譯行業(yè)摸爬滾打多年的老兵，我見證過太多因?yàn)榫幋a問題導(dǎo)致的返工和客戶投訴。今天就想跟大家聊聊，小語種翻譯過程中那些字符編碼的坑，我們到底應(yīng)該怎么避開它們。
說白了，字符編碼就是計(jì)算機(jī)用來存儲(chǔ)和顯示文字的一套規(guī)則。你想啊，計(jì)算機(jī)這玩意兒最擅長(zhǎng)處理的是數(shù)字，0和1嘛。那我們?nèi)粘Ｓ玫奈淖帧形摹⒂⑽摹⑷瘴摹⒗摹趺醋層?jì)算機(jī)認(rèn)識(shí)呢？這就得把每一個(gè)字符都轉(zhuǎn)換成對(duì)應(yīng)的數(shù)字，這個(gè)轉(zhuǎn)換規(guī)則就是編碼。
最早的計(jì)算機(jī)是美國(guó)人在用，他們想得很簡(jiǎn)單，搞個(gè)ASCII編碼就夠了。這套規(guī)則用7位二進(jìn)制數(shù)表示128個(gè)字符，包括英文字母、數(shù)字和一些常用符號(hào)。對(duì)美國(guó)人來說夠用了，但世界其他地區(qū)的人民不干了——我們還有自己的語言呢。
歐洲人先坐不住了，他們搞了個(gè)ISO-8859系列，用8位二進(jìn)制數(shù)表示256個(gè)字符。但這也只能覆蓋拉丁字母體系的各種語言，希臘文、西里爾文什么的各有各的編碼方式。到了亞洲這邊，問題更復(fù)雜了。中文有GBK、GB2312、Big5，日文有Shift-JIS，韓文有Euc-Kr，各用各的，誰也不兼容誰。
這就埋下了隱患。同一份文檔，在這個(gè)軟件里顯示得好好的，換個(gè)軟件就變成了亂碼。翻譯公司收到國(guó)外客戶發(fā)來的文件，用系統(tǒng)自帶的記事本打開全是問號(hào)，工程師用專業(yè)軟件打開卻一切正常。你說神奇不神奇？
在實(shí)際的翻譯工作中，編碼問題從來不會(huì)缺席，只是有時(shí)候它披著不同的馬甲出現(xiàn)，讓人一時(shí)分辨不出來。
最典型的就是多字節(jié)字符的問題。像中文、日文、韓文這些語言，一個(gè)字符用一個(gè)字節(jié)根本存不下，必須用兩個(gè)甚至更多字節(jié)。這就是為什么小語種文件有時(shí)候會(huì)比英文文件大出很多。更麻煩的是，不同的語言對(duì)"一個(gè)字符占幾個(gè)字節(jié)"這件事有著完全不同的規(guī)定。同樣一個(gè)"中"字，在GBK編碼里是兩個(gè)字節(jié)，在UTF-8里可能變成三個(gè)字節(jié)。如果翻譯系統(tǒng)或CAT工具的編碼設(shè)置和源文件不一致，那字符就會(huì)全部錯(cuò)位。
Unicode和UTF-8的出現(xiàn)本來是為了解決這個(gè)問題的，但新的問題緊接著就來了。Unicode收錄了世界上幾乎所有的文字符號(hào)，但UTF-8只是它的一種編碼實(shí)現(xiàn)方式。還有UTF-16、UTF-32這些變體，它們之間并不能完全兼容。Windows系統(tǒng)偏愛UTF-16，Linux系統(tǒng)更常用UTF-8，Mac系統(tǒng)又有自己的一套做法。文件在不同操作系統(tǒng)之間傳來傳去，編碼方式一變，亂碼就來了。
還有一些比較隱蔽的問題，比如BOM頭。UTF-8編碼的文件可以在開頭加一個(gè)特殊的標(biāo)記字節(jié)序列，用來告訴后面的程序"這是UTF-8文件"。但有些老舊的軟件不認(rèn)識(shí)這個(gè)標(biāo)記，會(huì)把它當(dāng)成普通字符顯示出來，結(jié)果文件開頭就多了幾個(gè)莫明其妙的符號(hào)。翻譯的時(shí)候沒注意，交到客戶手里才被發(fā)現(xiàn)，尷尬不尷尬？
雖然編碼標(biāo)準(zhǔn)一大堆，但小語種翻譯工作中最常打交道的其實(shí)就那么幾個(gè)。了解它們的脾氣秉性，才能在實(shí)際工作中少走彎路。
| 編碼名稱 | 適用語言 | 特點(diǎn) |
| UTF-8 | 全球通用 | 可變長(zhǎng)度編碼，兼容ASCII，互聯(lián)網(wǎng)和現(xiàn)代操作系統(tǒng)的默認(rèn)選擇 |
| UTF-16 | 多語言混合 | 固定雙字節(jié)編碼，適合包含大量CJK字符的文檔 |
| GBK/GB18030 | 簡(jiǎn)體中文 | 國(guó)標(biāo)編碼，包含絕大多數(shù)常用漢字，但不支持繁體 |
| Big5 | 繁體中文 | 港臺(tái)地區(qū)常用，與GBK存在大量重疊但互不兼容 |
| Shift-JIS | 日文 | 日本工業(yè)標(biāo)準(zhǔn)，兼容ASCII，但對(duì)非日文字符支持有限 |
| EUC-KR | 韓文 | 韓國(guó)主流編碼，對(duì)韓文支持較好，但古韓文支持不足 |
| ISO-8859系列 | 歐洲語言 | 一個(gè)標(biāo)準(zhǔn)對(duì)應(yīng)一個(gè)語族，如ISO-8859-1對(duì)應(yīng)西歐語言 |
這里我想特別強(qiáng)調(diào)一下UTF-8的地位。現(xiàn)在國(guó)際化的軟件和網(wǎng)站，80%以上都在用UTF-8。它最大的優(yōu)點(diǎn)是向后兼容ASCII——也就是說，早期用純ASCII編碼的英文文件，根本不用改就能直接當(dāng)UTF-8用。而且UTF-8對(duì)多語言混合文檔的支持很好，一份文件里同時(shí)出現(xiàn)中文、阿拉伯文、希臘文，都不會(huì)有問題的前提下還能保持相對(duì)緊湊的存儲(chǔ)空間。
但UTF-8也不是萬能的。如果你的文檔里大部分都是CJK字符，用UTF-16反而可能更省空間。另外，有些的傳統(tǒng)行業(yè)的軟件系統(tǒng)，比如某些德國(guó)的工業(yè)設(shè)計(jì)軟件、日本的CAD系統(tǒng)，它們還在堅(jiān)持用老舊的編碼標(biāo)準(zhǔn)，這時(shí)候你就得入鄉(xiāng)隨俗了。
說了這么多原理，最后還得落到實(shí)操上。下面這些方法，都是我們團(tuán)隊(duì)在無數(shù)個(gè)項(xiàng)目里積累出來的經(jīng)驗(yàn)之談。
這事兒聽起來簡(jiǎn)單，但很多人做不到。習(xí)慣了雙擊文件直接開，出了問題才后悔。正確做法是：收到客戶發(fā)來的文件，先用十六進(jìn)制編輯器或者專業(yè)的編碼檢測(cè)工具看一下文件的真實(shí)編碼是什么。Windows上有個(gè)小工具叫"Encoding Detective"，Mac上可以用"FileZilla"或者命令行下的"file"命令。知道源文件的編碼，后面的工作就好做多了。
康茂峰的譯審團(tuán)隊(duì)在處理小語種項(xiàng)目時(shí)，有一個(gè)不成文的規(guī)定：所有非常規(guī)小語種文件，翻譯前必須用專業(yè)工具檢測(cè)編碼，確認(rèn)無誤后再導(dǎo)入翻譯系統(tǒng)。這個(gè)習(xí)慣幫我們避免了多少返工，真的數(shù)不清了。
主流的CAT工具比如Trados、MemoQ、Déjà Vu，在新建項(xiàng)目的時(shí)候都會(huì)有編碼選項(xiàng)。這個(gè)環(huán)節(jié)千萬別偷懶，一定要手動(dòng)選擇與源文件一致的編碼。如果源文件檢測(cè)出來是GBK，你就別選UTF-8；如果客戶特別叮囑要用Shift-JIS，那就乖乖按客戶的要求來。
有些譯員喜歡用機(jī)器翻譯輔助，DeepL、Google Translate這些工具對(duì)編碼的處理方式各不相同。機(jī)器翻譯的結(jié)果導(dǎo)出后，最好再用專門的工具檢查一遍編碼是否正確。我見過太多次，機(jī)器翻譯出來的日文文檔，因?yàn)榫幋a問題導(dǎo)致特殊假名全部錯(cuò)位，最后只能全部重翻。
文件翻譯完了，別著急交到客戶手里。用至少兩種不同的軟件打開看看效果——比如先用Word開，再用記事本開，或者用專業(yè)的文本編輯器開。如果在這兩個(gè)軟件里顯示正常，那大概率就沒問題了。
還有一點(diǎn)要提醒：Windows系統(tǒng)和macOS系統(tǒng)對(duì)某些編碼的處理方式略有不同。如果你的客戶用的是Mac，最好在交付前用Mac上的軟件打開檢查一遍。反之亦然。我們?cè)?jīng)有過一個(gè)項(xiàng)目，中文翻譯件在Windows上一切正常，結(jié)果客戶用Mac打開后發(fā)現(xiàn)所有中文引號(hào)都顯示異常，最后不得不全部替換重新調(diào)整。
這點(diǎn)太重要了。很多編碼問題不是我們?cè)斐傻模强蛻裟沁叺南到y(tǒng)太老舊。翻譯之前，先問清楚客戶：最終文件要在什么系統(tǒng)上使用？需要什么格式？有沒有特定的編碼要求？把這些信息提前問清楚，既能避免后面的麻煩，也能讓客戶感受到你的專業(yè)。
有些歐洲客戶會(huì)特別要求保留源文件的編碼格式，有些亞洲客戶則明確要求轉(zhuǎn)成UTF-8。把這些要求寫進(jìn)項(xiàng)目記錄里，整個(gè)團(tuán)隊(duì)執(zhí)行起來就不會(huì)有偏差。
有些編碼問題比較棘手，沒有標(biāo)準(zhǔn)答案，得靠經(jīng)驗(yàn)和臨場(chǎng)應(yīng)變。
比如阿拉伯語和希伯來語是從右向左書寫的，而它們的數(shù)字卻是從左向右顯示。這種文字方向和數(shù)字方向的沖突，如果翻譯系統(tǒng)不支持雙向語言處理，顯示出來就會(huì)一塌糊涂。解決辦法是使用專業(yè)的本地化工具，或者在排版階段用專門的RTL（從右向左）布局軟件處理。
再比如泰文、緬甸文、柬埔寨文這些東南亞語言，它們的字符組合規(guī)則非常復(fù)雜。一個(gè)基礎(chǔ)字符加上不同的高低輔音、元音符號(hào)，會(huì)組合成完全不同的字符形狀。如果翻譯系統(tǒng)的字體渲染引擎不支持這些語言的組合規(guī)則，顯示出來的文字就會(huì)支離破碎。這種情況下，換一個(gè)支持這些語言的字體往往就能解決問題。
還有一些生僻字、古文字、方言用字，可能根本不在常用編碼范圍內(nèi)。這時(shí)候就得考慮用Unicode的擴(kuò)展區(qū)域，或者在交付時(shí)附上說明，告訴客戶需要安裝特定的字體才能正常顯示。
說實(shí)話，字符編碼這個(gè)問題，看著挺技術(shù)挺枯燥的，但它實(shí)實(shí)在在影響著每一份小語種翻譯作品的質(zhì)量。從最早的ASCII到今天的Unicode，人類花了幾十年時(shí)間，才勉強(qiáng)讓計(jì)算機(jī)能夠更好地理解我們的語言。這個(gè)過程中出現(xiàn)的混亂和麻煩，都是前進(jìn)的代價(jià)。
我們做翻譯的，雖然不需要成為編碼專家，但了解一些基本的原理和應(yīng)對(duì)方法，絕對(duì)能讓工作更順暢。下次再遇到亂碼問題，至少知道該從哪個(gè)方向去找答案，不至于干著急。
想起那句話：翻譯是兩種文化之間的橋梁。而字符編碼呢，大概就是這座橋的地基之一吧。地基不穩(wěn)，橋再好也走不踏實(shí)。把這些看似細(xì)節(jié)的問題處理好，才能真正把翻譯這件事件做好。
