HarmonyOS鸿蒙Next中encodeURIComponent（编码）/decodeURIComponent（解码）方法是基于rfc3986还是rfc2396，与前端里面是否一致？

HarmonyOS鸿蒙Next中encodeURIComponent（编码）/decodeURIComponent（解码）方法是基于rfc3986还是rfc2396，与前端里面是否一致？请问鸿蒙里面encodeURIComponent（编码）/decodeURIComponent（解码）方法是基于rfc3986还是rfc2396，与前端里面是否一致？

vueper 1楼

encodeURIComponent 是ts自带的能力，URI编码是基于RFC 3986标准的。开发者您好，encodeURIComponent 能力是ts自带的，与鸿蒙提供的基础库无关。关于标准这块，仔细核对了下，更正确认是2396标准的。

更多关于HarmonyOS鸿蒙Next中encodeURIComponent（编码）/decodeURIComponent（解码）方法是基于rfc3986还是rfc2396，与前端里面是否一致？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

yibo5220 2楼

在HarmonyOS鸿蒙Next中，encodeURIComponent和decodeURIComponent方法是基于RFC 3986标准。RFC 3986定义了URI（统一资源标识符）的语法，包括编码和解码的规则。与前端（如浏览器环境）中的实现一致，前端中的encodeURIComponent和decodeURIComponent方法同样基于RFC 3986。

RFC 3986与较早的RFC 2396相比，主要区别在于对保留字符的处理。RFC 3986明确规定了哪些字符是保留字符，这些字符在URI中有特殊含义，因此在进行编码时需要特别处理。而RFC 2396在这方面的定义相对模糊。

在HarmonyOS鸿蒙Next中，encodeURIComponent方法会对所有非字母数字字符进行编码，包括保留字符（如!, *, ', (, ), ;, :, @, &, =, +, $, ,, /, ?, #, [, ]）。而decodeURIComponent方法则会将编码后的字符转换回原始字符。

总结来说，HarmonyOS鸿蒙Next中的encodeURIComponent和decodeURIComponent方法基于RFC 3986，与前端环境中的实现一致。

gougou168 3楼

在HarmonyOS鸿蒙Next中，encodeURIComponent和decodeURIComponent方法遵循的是RFC 3986标准。这与前端JavaScript中的实现是一致的。RFC 3986定义了URI的通用语法，确保字符编码和解码的统一性。因此，无论是在HarmonyOS还是前端开发中，这些方法的行为都是基于相同的标准。