【原】ABAP 实现繁体中文和简体中文的互相转换

我的技术交流群里有朋友提问：

ABAP 如何实现繁体中文和简体中文的互相转换？

有朋友建议，因为网上有现成的繁体汉字和简体汉字互相转换的数据库，可以把这些映射关系下载下来，导入到 ABAP 系统，以数据库表记录的方式存储。

注意，在阅读本文之前，建议大家先阅读笔者之前写的这篇文章，以获得阅读本文必需的前置知识：

ABAP 调用第三方 API，遇到乱码该怎么办？

比如汉字岳，Unicode 编码值为 \u5cb3，其繁体字嶽的 Unicode 编码为 \u5dbd，那么这个汉字的映射关系，在 ABAP 系统里可以用一条数据库表的记录来维护：

岳 5cb3 嶽 5dbd

这样一来，如果想在 ABAP 应用程序里实现繁体汉字和简体汉字的互相转换，只需要直接查表就行了。

Unicode 编码的完整列表，可以在官网下载：

https://www./versions/components-15.1.0.html

已知汉字的 Unicode 编码值，想获取其原始的汉字值，使用 cl_abap_conv_in_ce 的 uccp 方法，将汉字的 Unicode 编码值传入即可。

下面的代码，打印的结果就是 5dbd 编码对应的汉字值：嶽。

PARAMETERS: input TYPE char4 DEFAULT '5dbd'.
DATA: lo      TYPE REF TO cl_abap_conv_in_ce,
     lv_data TYPE string VALUE '嶽'.
lo = cl_abap_conv_in_ce=>create( ).
DATA(result) = lo->uccp( input ).
WRITE:/ result.

已知一个汉字，想获取其 Unicode 编码值，使用 cl_abap_conv_out_ce=>uccp 方法即可。

上面的代码，将汉字 嶽 的 Unicode 编码值 5DBD 打印出来。

如果大家想了解 ABAP 应用里 Unicode 处理的更多细节，可以参考 SAP 官方帮助文档：

https://help./docs/SAP_NETWEAVER_731_BW_ABAP/cfae740a0a21455dbe6e510c2d86e36a/623f2cb0b35311d5993800508b6b8b11.html

下面是帮助文档的部分中文内容，来自 GPT 先生的翻译，加上笔者少量润色。

从 6.10 版本开始，ABAP 开始支持 Unicode 中的多字节字符编码（multi-byte coding for characters）。在 6.10 版本之前，ABAP 只使用基于单字节编码的字符集——例如 ASCII 和 EBCDIC ——或双字节编码，如 SJIS 和 BIG5。

在引入 Unicode 概念之前，ABAP 内的 Char 类型所占据的存储空间，即字节长度默认为 1. 不少 ABAP 应用程序，其编写逻辑也基于这种默认的假设。

后来 ABAP 开始支持 Unicode，所以但凡基于这种假设而开发出的 ABAP 应用程序，都需要进行评估然后进行相应的重构。

幸运的是，那是一个遥远的时代。如今的 ABAP 应用开发人员，早已不需要再做类似的事情了。

在引入 Unicode 之前，ABAP 开发人员使用各种编码来表示不同字母的字符，例如 ASCII、EBCDIC 或双字节编码页。

ASCII（美国信息交换标准代码）使用 1 个字节（8 位）来编码每个字符。这使得最多可以表示 256 个字符，这些字符的组合范围是 [00000000, 11111111]。常见的编码页有 ISO88591，用于西欧语言或ISO88595，用于西里尔字母集合。

EBCDIC（扩展二进制编码十进制交换码）也使用 1 个字节来编码每个字符，同样可以表示 256 个字符。EBCDIC 0697/0500是用于西欧语言的旧 IBM 格式，主要用于 AS/400 机器。

双字节编码页每个字符需要 1 或 2 个字节。这允许形成 65536 种组合，其中通常使用 10,000 到 15,000 个字符。双字节编码页的例子包括用于日语的 SJIS 和用于繁体中文的 BIG5。

使用这些字符集，可以涵盖 SAP 系统相关的所有语言。

然而，如果希望在一个中央系统中合并来自不同的彼此不兼容字符集的文本，就会出现问题。

同样，在系统之间交换不兼容字符集的数据，可能会导致意想不到的问题。

解决这个问题的一种方法，是使用一个包含所有字符的编码集合。这种编码被称为Unicode（ISO/IEC 10646），每个字符至少由 16 位（2 字节）或 32 位（4 字节）组成。

虽然当时的 SAP R/3 内核和应用程序，在切换到支持 Unicode 的时候，耗费了具体的转换工作量，但从长远来看，迁移到 Unicode 也是一件必须完成的事情，并且带来了巨大的收益：

• Unicode 允许所有 R/3 用户安装一个涵盖全球所有业务流程的中央 R/3 系统。

• 使用不同分布式系统的公司，通常希望汇总其全球企业数据。如果没有 Unicode，这些企业只能在有限的程度上做到这一点。

• 使用 Unicode，用户可以在单个前端计算机上同时使用多种语言。

现在回过头来看，Unicode 是跨应用数据交换所必须支持的，只有支持 Unicode，才不会因字符集不兼容而导致数据丢失。