鸿蒙ArkTs/c++/RepalcePioneer/base64.us之Base64编码解码的是非

狗血现象：

同一字符串原文使用

1、RepalcePioneer（一款Windows平台的字符串工具）

2、鸿蒙ArkTs自带base64编码方法

3、https://base64.us（一款在线base64工具）

来编码，得到编码串不一样，后二者是一致的。（未测试用c++写的base64编码。）

猜测base64编码可能有不同的“标准”？

相比解码的狗血度，上边的编码现象还不算什么：

上述1，和2或3，得到的两个不同的编码串，使用base64.us解码，居然得到相同的正确原文。

使用c++的base64解码（网上的一段代码，如下）上述不同的编码，也能得到相同的正确原文。

也就是说这两个方法在解码时，能正确处理不同编码工具（“标准”？）得到的不同编码串。

而用ArkTs的自带的解码方法，则可能得到不同的原文。

注意，上边说的是可能，即ArkTs有时能正确解码RepalcePioneer编码，有时不能。这是最狗血的地方。一个经验是：原文最后有一个单独的换行，其后可能有一些字符或没有，则ArkTs解码结果是：从这个换行起所有内容丢失。如果不是这样，则解码正确。

std::string base64_decode(const std::string &encoded) {
    static const std::string base64_chars =
             "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
             "abcdefghijklmnopqrstuvwxyz"
             "0123456789+/";
 
    std::string ret;
    int val = 0, valb = -8;
    for (unsigned char c : encoded) {
        if (base64_chars.find(c) == std::string::npos) break; // 非法字符
        val = (val << 6) + base64_chars.find(c);
        valb += 6;
        if (valb >= 0) {
            ret.push_back(char((val >> valb) & 0xFF));
            valb -= 8;
        }
    }
    return ret;
}

不了解为何存在不同的base64编码“标准”，以至于得到的编码串都大不相同。

更不理解为何这种不同的编码串，cpp解码或base64.us解码，能得到相同的正确原文。

我的实践是在鸿蒙NDK侧读取被ReplacePioneer编码的文件内容，然后在ArkTs侧解码，发现上述有时正确、有时错误（内容缺失）的现象。所以被迫在NDK侧用上述cpp方法解码，过渡一下，再把解码后的原文传回ArkTs侧，ArkTs侧不再参与base64解码。