char *转换为string的陷阱:char*中包含较多的'\0'

今天给团队调试一个错误,概率性的加密的数据没法做解密,现象是解密出来的结果和源数据长度不一致,很奇怪的现象,因为加密使用的数据是随机的,所以使得问题出现时表象是概率的问题;


因为初次做加解密算法相关的项目,碰到这样的问题,首先是单步把解密流程过了一遍,发现解密没有问题,能正常的解密,但解密出来的长度就是不对,分析才发现加密后的数据的长度也不正常,所以考虑是加密源数据的问题,通过分析,才发现一个二进制的源数据经过转换为字符串对象string后使用openssl的接口完成的加密处理,导致string对象比原来的字节数组长度要短,短的原因是字节数组中包括了'\0'结束符,原以为是openssl的接口实现存在这样的问题,建议使用方将加密的字节数组将0字符都过滤一遍,但想来还是不正确,原来char*的数组转换为string存在一个陷阱:见“https://blog.csdn.net/b876144622/article/details/79972498”;所以还是转换的不合适,修改前后的代码如下:

  //原来的代码
  #if 0
  char *temp = (char *)malloc(length + 1);
  if (temp == NULL){
    ALOGE("encrypt failed, temp == NULL");
    ShutdownOpenABE();
    return -1;
  }
  memcpy(temp, rawData, length);
  temp[length] = '\0'; 
  string inputStr = temp;
  FREE(temp);
  #else
  //修改的代码
  string inputStr ;//= temp;
  //convert temp to string
  for (int i=0; i<length; i++){
  	if (i < length-1 && rawData[i] == '\0'){		
        cerr << "rawdata:" << rawData <<", length:" << length<<endl;
        //ALOGE("rawdata:%s, length:%d, i:%d", rawData, length, i);
		//return PARMETER_ERR_CONTENT;
	}
	inputStr += rawData[i];
  }
  #endif//end

参考:https://blog.csdn.net/analogous_love/article/details/71744427

还有一种方法是使用assign方法进行赋值,需要指定赋值字节数组的长度,否则以0做结束符计算长度,更简洁些;

inputStr .assign(rawData, length);


白俊遥博客

本文为呱牛笔记原创文章,转载无需和我联系,但请注明来自呱牛笔记 ,it3q.com

请先登录后发表评论
  • 最新评论
  • 总共0条评论