abap取字符串最后几位_关于SAP ABAP字符变量和字符串变量字符个数的一个知识点,和一个血案...

本文介绍了在ABAP中使用strlen函数计算字符和字符串变量的长度时遇到的陷阱,包括隐式类型转换导致的额外字符和固定长度变量的处理。通过实例解析了整数转字符串时末尾空格的问题,以及字符值传递给整型参数时引起的错误。强调了理解隐式类型转换的重要性,以避免项目中出现未预期的性能问题。
摘要由CSDN通过智能技术生成

d707cc73831f0aa64b860ffce05fb930.png

今天是2020年5月2日,五一国际劳动节小长假的第二天。让我们继续劳动起来。

使用ABAP strlen函数计算下列这4个字符和字符串变量中包含的字符个数。

9845364e71b7027db4e265544c9b7a78.png

大家先别急着滑动屏幕,先试着自己计算一下,看和标准答案是否有出入。也许大家觉得这些小的知识点没什么用,但Jerry马上会分享一个我实际处理过的客户incident,正是由于类似这种看似不起眼的小知识点没有留意,最后影响了项目进展。

9bece2d05a15a30e8c5ddb3a7b59aa35.png

0c54848be99f6440e1242983afa29e28.png

7e534e4184149e129d35f6b0038d6726.png

cd874378d4463c94210a47686f91ba58.png

正确答案,依次是:

  • 2
  • 1
  • 19
  • 17

逐一解释。

strlen( lv_s ) = 2

整型变量的值,整数1,赋给字符串变量lv_s, 这里发生一个隐式类型转换。

SAP帮助文档里声明,整型变量赋给字符串变量时,如果整数为负数,则字符串变量末尾为"-";如果整数为正数,则字符串变量末尾为空白字符。换言之,当整型变量到字符串变量的隐式类型转换发生时,字符串变量末尾会多出一位,代表赋值源头的整型数的符号位。

084eeeeaebaf35b04a7490817fe6df5b.png

lv_s多出来的这个空白字符在调试器里看得很清楚,2000正是空白字符的16进制编码。同时调试器里也能看到lv_s的字符串个数为2.

552084ee1db1629e124c707fe82e322b.png

strlen( lv_s2 ) = 1

和前一例相比,lv_s2的复制操作没有出现隐式类型转换,而是直接被赋以了一个字符常量,故字符个数为1.

strlen( lv_ss) = 19

lv_ss的类型为SSTRING,实际就是一个CHAR20:

4eaa49650383396650a279d42a85a9e9.png

在调试器里,lv_ss有18个前导空白(leading blank)字符,字符"1"和1个尾部空白(trailing blank)字符组成,总共20个字符,调试器里的Technical Type显示为C(20).

38a75475a9ab5b349ee86a7a84289ea7.png

那为什么strlen(lv_ss)不等于20,而等于19?SAP帮助文档里给出了答案——SSTRING即CHAR20这种变量,属于固定长度(fixed length)类型变量。当使用strlen函数计算这种变量的字符串个数时,尾部空白字符不应参加计数,所以要减一。

73d4d9601851b9b4aaa82a098b2b9795.png

strlen( lv_s3) = 17

有了例三的基础,这个就很容易了。变量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条记录。

a9979a0d115bbca0d34e372d071c428b.png

然而从ERP端返回了总共408093条记录。显然,虽然通过硬编码指定Max Hit为15,却完全没有起到限制作用。

853064481928d76543ced4130cd57685.png

起初我想当然地认为这是ERP函数的bug,没有正确处理CRM调用端传递过来的Max Hit. 然而当我在调试器里单步执行到CRM函数内部查看iv_max_entries时,一下傻了眼:

2c0ada5afeb6646ea3b6eb789ca1ffed.png

它的值从15一下变成了3473457. 这个数字是什么鬼?!

再看函数的形式参数定义,iv_max_entries类型为整型,而二次开发顾问传入的硬编码值'15', 是一个字符值,我顿时恍然大悟。

53f55e4c3ed5a881587631d5708624bd.png

'15'是怎么变成魔幻数字3473457的?

Jerry先不解释,而是请大家看下面这段代码:

ac4691a48a6870c60db9d8a5a2e28d15.png

执行,正好输出3473457这个魔幻数字。那么代码第四行31003500是哪里来的?其实就是字符串'15'的十六进制编码。

b13665a4fb18a9d86b5048ca5d246467.png

也就是说,二次开发顾问在RFC调用时,将硬编码的'15'传给了接受整型变量的函数参数IV_MAX_ENTRIES. 应该该参数类型为整型,所以'15'的十六进制编码'31003500'被自动转换成了对应的整型数3473457. 显然这不是开发顾问期望的行为,但因为程序能够继续运行,所以这个问题暂时被掩盖了。

而RFC调用完成之后,紧接着是一个嵌套的LOOP. 在Max Hit能按照期望工作的前提下,对于最多包含15条记录的内表,就算进行嵌套的LOOP操作也能很快完成。但如今因为Max Hit不工作,内表记录从最多15条一下子变成了超过40万条,在这么庞大规模的内表上进行嵌套LOOP操作,性能可想而知。

经历过这次incident的处理之后,我个人觉得,使用隐式类型转换的最佳实践就是根本不去用它。程序员在工作的时候,必须时刻清醒地知道自己在做什么,要扼住编译器的咽喉,而不要被编译器扼住了咽喉。

120a9859952c6847fd9a304bcfd699c3.png

感谢阅读,祝大家五一节快乐。

要获取更多Jerry的原创文章,请关注公众号"汪子熙":

90ffb6ddaf38626f89362985656fa258.png
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值