本篇内容主要讲解“SAP ABAP字符变量和字符串变量怎么理解”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“SAP ABAP字符变量和字符串变量怎么理解”吧!
使用ABAP strlen函数计算下列这4个字符和字符串变量中包含的字符个数。
大家先别急着滑动屏幕，先试着自己计算一下，看和标准答案是否有出入。也许大家觉得这些小的知识点没什么用，但Jerry马上会分享一个我实际处理过的客户incident，正是由于类似这种看似不起眼的小知识点没有留意，最后影响了项目进展。
2
1
19
17
逐一解释。
整型变量的值，整数1，赋给字符串变量lv_s, 这里发生一个隐式类型转换。
SAP帮助文档里声明，整型变量赋给字符串变量时，如果整数为负数，则字符串变量末尾为"-"；如果整数为正数，则字符串变量末尾为空白字符。换言之，当整型变量到字符串变量的隐式类型转换发生时，字符串变量末尾会多出一位，代表赋值源头的整型数的符号位。
lv_s多出来的这个空白字符在调试器里看得很清楚，2000正是空白字符的16进制编码。同时调试器里也能看到lv_s的字符串个数为2.
和前一例相比，lv_s2的复制操作没有出现隐式类型转换，而是直接被赋以了一个字符常量，故字符个数为1.
lv_ss的类型为SSTRING，实际就是一个CHAR20：
在调试器里，lv_ss有18个前导空白(leading blank)字符，字符"1"和1个尾部空白(trailing blank)字符组成，总共20个字符，调试器里的Technical Type显示为C(20).
那为什么strlen(lv_ss)不等于20，而等于19？SAP帮助文档里给出了答案——SSTRING即CHAR20这种变量，属于固定长度(fixed length)类型变量。当使用strlen函数计算这种变量的字符串个数时，尾部空白字符不应参加计数，所以要减一。
有了例三的基础，这个就很容易了。变量lv_s3类型是CHAR18，属于固定长度类型变量，因此strlen计算出的字符串个数为18 - 1 = 17.
第一个例子中，我们把一个整数直接赋给了一个字符串变量，发生了隐式类型转换。在实际项目中，这种隐式类型转换很容易出现在函数或者ABAP类方法的参数传递中。对于函数或ABAP类方法的形式参数，如果我们传递的实际参数类型和其类型不匹配，就会发生隐式类型转换，这种自动转换有时并非我们期望发生的，甚至容易被忽略。
看一个真实的例子。我曾经担任过一个俄罗斯的SAP CRM客户项目的Dev Angel，收到过一个性能相关的incident，客户打开某个UI的速度极其缓慢，甚至经常超时。
我通过调试，最终发现罪魁祸首位于下段代码。该代码从SAP CRM发起RFC调用，去SAP ERP读取数据，Max Hit设置为15，意思是期望ERP端至多返回15条记录。
然而从ERP端返回了总共408093条记录。显然，虽然通过硬编码指定Max Hit为15，却完全没有起到限制作用。
起初我想当然地认为这是ERP函数的bug，没有正确处理CRM调用端传递过来的Max Hit. 然而当我在调试器里单步执行到CRM函数内部查看iv_max_entries时，一下傻了眼：
它的值从15一下变成了3473457. 这个数字是什么鬼?!
再看函数的形式参数定义，iv_max_entries类型为整型，而二次开发顾问传入的硬编码值'15', 是一个字符值，我顿时恍然大悟。
Jerry先不解释，而是请大家看下面这段代码：
执行，正好输出3473457这个魔幻数字。那么代码第四行31003500是哪里来的？其实就是字符串'15'的十六进制编码。
也就是说，二次开发顾问在RFC调用时，将硬编码的'15'传给了接受整型变量的函数参数IV_MAX_ENTRIES. 应该该参数类型为整型，所以'15'的十六进制编码'31003500'被自动转换成了对应的整型数3473457. 显然这不是开发顾问期望的行为，但因为程序能够继续运行，所以这个问题暂时被掩盖了。
而RFC调用完成之后，紧接着是一个嵌套的LOOP. 在Max Hit能按照期望工作的前提下，对于最多包含15条记录的内表，就算进行嵌套的LOOP操作也能很快完成。但如今因为Max Hit不工作，内表记录从最多15条一下子变成了超过40万条，在这么庞大规模的内表上进行嵌套LOOP操作，性能可想而知。
到此，相信大家对“SAP ABAP字符变量和字符串变量怎么理解”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
重庆分公司
重庆分公司
