今天用HTTP做接口，从站网站服务器上POST提交数据，然后得到返回结果，但发现返回的中文结果并不是直接的中文，而是类似\u6210\u529f，所以在网上找了段代码，但网上的是CLASS（ZCL_CHINESE_TOOL ）的，所以自己转换了一下做成了函数。
在函数中的类型：ZUNICODE_FLAG,其实可以直接设置成STRING就成了，我这里只是为了记录一下，可传的参数，其中内容可为：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 |
FUNCTION ZHTTP_UNICODE_TO_ZH. *"---------------------------------------------------------------------- *"*"本地接口： *" IMPORTING *" REFERENCE(IV_STRING) TYPE STRING DEFAULT '\U6210\U529F' *" REFERENCE(IV_FLAG) TYPE CHAR3 DEFAULT '\U' *" EXPORTING *" REFERENCE(RV_STRING) TYPE STRING *"---------------------------------------------------------------------- *'\\u ' 为下横线 _ CONSTANTS: MASK TYPE STRING VALUE '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'. CONSTANTS: C_DEFAULT TYPE CHAR3 VALUE '\U'. TYPES: BEGIN OF TY_PAIR, UNICODE TYPE CHAR4, CHINESE TYPE CHAR2, END OF TY_PAIR. DATA: LV_OFFSET TYPE I, LV_START TYPE I, LT_MATCH TYPE MATCH_RESULT_TAB, LS_MATCH LIKE LINE OF LT_MATCH, LV_UNICODE TYPE CHAR4, LV_UPPER TYPE CHAR4, LT_CHINESE TYPE STANDARD TABLE OF TY_PAIR, LS_PAIR TYPE TY_PAIR, LV_LEN TYPE I, LV_CHINESE TYPE CHAR3, LV_REPLACE TYPE CHAR7, LV_INPUT TYPE STRING. DATA: SV_UNICODE_FLAG TYPE CHAR3, ST_INVALID TYPE STRING_TABLE. *IV_FLAG = \U \U+ &* IF IV_FLAG IS NOT SUPPLIED. SV_UNICODE_FLAG = C_DEFAULT. ELSE. SV_UNICODE_FLAG = IV_FLAG. ENDIF. FIND ALL OCCURRENCES OF SV_UNICODE_FLAG IN IV_STRING RESULTS LT_MATCH. IF SY-SUBRC <> 0. RV_STRING = IV_STRING. RETURN. ENDIF. LV_INPUT = IV_STRING. LV_LEN = STRLEN( LV_INPUT ). CLEAR: LT_CHINESE. LOOP AT LT_MATCH INTO LS_MATCH. LV_START = LS_MATCH-OFFSET + LS_MATCH-LENGTH. CHECK LV_LEN >= LV_START + 4. LV_UPPER = LV_UNICODE = IV_STRING+LV_START(4). TRANSLATE LV_UPPER TO UPPER CASE. * CHECK IS_HEXDECIMAL( LV_UNICODE ) = ABAP_TRUE. IF LV_UNICODE CO MASK. LV_CHINESE = CL_ABAP_CONV_IN_CE=>UCCP( LV_UPPER ). READ TABLE ST_INVALID WITH KEY TABLE_LINE = LV_CHINESE TRANSPORTING NO FIELDS. CHECK SY-SUBRC <> 0. LS_PAIR-UNICODE = LV_UNICODE. LS_PAIR-CHINESE = LV_CHINESE. ELSE. * RETURN . * LS_PAIR-UNICODE = LV_UNICODE. * LS_PAIR-CHINESE = LV_UNICODE. CONTINUE. ENDIF. APPEND LS_PAIR TO LT_CHINESE. ENDLOOP. *--------------------------------------------------------------------* *加入特殊转换， LS_PAIR-UNICODE = '\\u '. LS_PAIR-CHINESE = '_'. APPEND LS_PAIR TO LT_CHINESE. *--------------------------------------------------------------------* SORT LT_CHINESE BY UNICODE . DELETE ADJACENT DUPLICATES FROM LT_CHINESE COMPARING UNICODE. LOOP AT LT_CHINESE INTO LS_PAIR. LV_REPLACE = SV_UNICODE_FLAG && LS_PAIR-UNICODE. REPLACE ALL OCCURRENCES OF LV_REPLACE IN LV_INPUT WITH LS_PAIR-CHINESE. ENDLOOP. RV_STRING = LV_INPUT. ENDFUNCTION. |
在使用中发现， ‘\\u ‘ 的内容为下横线 “ _”的UNICODE,
所以上面加入了一个特殊转换，可能还会有其它的特殊转换内容，可以此加入，原因可能如下，以下为网上找来的，更多内容可参看： https://www.cnblogs.com/jiangzhengjun/p/4265650.html
Java中的Unicode编码是采用高字节序（符合人的阅读习惯），而ABAP中是采用低字节序（符合机器存储结构）（注意，可能与测试的环境有关。经测试，与测试环境确实有关系，请看下面在AIX机器上的测试结果——高字节顺序——高字节在前，低字节在后，符合人的阅读习惯，但与机器存储刚好相反——内存是从左到右字节地址越来越大，即内存前面是低字节，而后面是高字节。正是因为ABAP不像Java那样跨平台，所以在ABAP中可以通过CL_ABAP_CHAR_UTILITIES=>ENDIAN获得当前SAP所在的服务器的字节序类别；但是Java是跨平台的，在任何平台下都是采用上面的高字节序）
