HarmonyOS 鸿蒙Next：加密算法差异导致App移植工作量增加，服务端不想动加解密算法
HarmonyOS 鸿蒙Next：加密算法差异导致App移植工作量增加，服务端不想动加解密算法
图一，Android加密算法支持byte[] ，有符号
图二，鸿蒙的解密和MD5等算法只支持Uint8Array，无符号。
ios和Andoird都是先用byte[]加密再base64。
同样的流程在鸿蒙上走不通，在服务端解密后数据错误。
服务端不针对鸿蒙适配的话，要怎么解决。
可以把int8Array数组转成base64或者十六进制字符串，然后传入HarmonyOS侧，通过下面方法转换，得到Uint8Array数组
function HexStrTouint8Array(str: string): Uint8Array {
return new Uint8Array(buffer.from(str, 'hex').buffer);
}
//base64转Uint8Array
new util.Base64Helper().decodeSync('str')<button style="position: absolute; padding: 4px 8px 0px; cursor: pointer; top: 8px; right: 8px; font-size: 14px;">复制</button>
这个跟鸿蒙的加解密算法无关系。可以保持统一。虽然你用的接口是行参数定义的为Uint8Array，无符号，这没问题吧。因为你看 c语言的代码中，很多也都是用的无符号型，便于按位解析和内存操作。
这没问题。你的问题出在使用上，把跟后台的加解密保持一致就行啦。
不是还有int8Array可以用吗？
可以试试，如果还有问题，可以给一组数据，我来算下。
在HarmonyOS鸿蒙Next平台进行App移植时，确实可能会遇到由于加密算法差异导致的工作量增加问题。这种差异可能源于鸿蒙系统对安全性的更高要求，或是底层API与原有系统的不兼容。
面对服务端不想改动加解密算法的情况，首先需明确加密算法差异的具体细节，包括算法类型、密钥管理、填充方式及模式等。若差异较小，可通过调整客户端代码以适应鸿蒙系统的要求，如更新加密库、调整密钥生成与存储方式等。
然而，若差异较大且无法通过简单调整解决，则需与服务端团队进行深入沟通，探讨算法兼容性的解决方案。可能包括但不限于：在客户端实现双算法支持，以便在鸿蒙系统上使用新算法，而在其他平台上保持原算法；或开发一套中间件，用于在客户端与服务端之间转换加密算法。
在解决此类问题时，还需注意确保应用的安全性不受影响，避免在迁移过程中引入新的安全风险。
如果问题依旧没法解决请联系官网客服，官网地址是：https://www.itying.com/category-93-b0.html 。
