ABAP 調用第三方 API，遇到亂碼該怎麼辦？詳情 - abap,亂碼,utf-8,編碼,編碼規範註銷博客

這是 Jerry 2022 年第二篇原創文章，也是本公眾號第 370 篇原創文章。

之前有一個朋友在知乎上向我諮詢過這個問題，我覺得很有代表性，所以專門用一篇文章來講述一些相關知識點。

先看這位朋友遇到的具體問題。

用 Postman 調用第三方接口，裏面的中文字符能夠正常顯示。

然而當用 ABAP 的 HTTP 工具類 CL_HTTP_CLIENT 的 response->get_data( ) 讀取響應之後，發現裏面的中文字符，例如 "訪問成功" 是亂碼：

首先明確一點，既然 Postman 能正確顯示響應數據中的中文內容，説明 API provider 是不存在問題的，這個亂碼問題出現在接收方，即 ABAP 代碼的編程實現需要調整。

我們只要弄清楚出現亂碼的原因，就能有的放矢進行修復了。

上個世紀 60 年代，美國製定了一套字符編碼，定義了英文字符與二進制位之間的一一映射關係，稱為 ASCII 碼。將一個符號的圖形顯示，關聯到其二進制存儲位的這種行為，就稱之為字符編碼。ASCII 就是一種最簡單的字符集和字符編碼方式。

一個字節有 8 位，2 的 8 次方為 256，因此 1 個字節只能表示 256 種符號，而漢字的總數超過了 10 萬個，顯然無法用 1 個字節來存儲。

除了大家熟悉的英文字符和漢字外，還有很多歷史更悠久的文字，比如埃及象形文字：

以及周杰倫《愛在西元前》裏提到的楔形文字：

有沒有這樣一種計算機編碼方式，能夠將這些稀奇古怪的符號都納入其中呢？有，這就是 Unicode，正如其命名暗示的，Unicode 將世界各種語言的每個字符都分配了一個唯一的編碼，以滿足跨語言、跨平台的文本信息轉換。

我們根據 Unicode 編碼表，就能查到一個字符對應的 Unicode 編碼，比如漢字 "汪"對應的 Unicode 編碼為 00006C6A.

6C6A 的二進制表示為 0110 1100 0110 1010，需要兩個字節進行存儲。表示其他的符號，可能需要三個甚至四個字節存儲。

另一方面，對於原本就存在於 ASCII 編碼表中的英文字符，僅需 1 個字節就能存儲。如果 Unicode 強制要求每個字符按照最大需要的存儲空間，即 4 字節進行存儲，顯然對於英文字符來説，意味着極大的空間浪費。

因此，Unicode 僅僅定義字符到其編碼的映射關係。而這些編碼到底採取多少個字節進行存儲，由 Unicode 具體的實現方式，比如 UTF-8，UTF16 等來決定。

UTF-8 是一種變長的編碼方式，使用 1 到 4 個字節表示一個字符，符號不同，用於存儲的字節長度也不同。比如 "汪" 的 UTF-8 碼值為 E6B1AA，需要三個字節存儲。

根據 SAP 幫助文檔，ABAP 採用 UCS-2 編碼方式，可以看成 UTF-16 的子集，因為 UCS-2 不支持 UTF-16 的 surrogates 區間內定義的一些特殊符號。

所謂 UTF-16，就是所有字符固定都用兩個字節表示。

從下面這張表格能夠看出，UTF-16 又分 UTF-16BE 和 UTF-16LE 兩種實現方式。以漢字 "汪" 的 Unicode 編碼值 6C6A 為例，如果 6C 存儲在內存低位地址，6A 存儲在內存高位地址，這就是 Big Endian 即大尾序(有時也譯作大頭，大端)存儲方式，反之則為 Little Endian 即小尾序存儲方式。