每次我使用 Base64 对字符串进行编码并添加 + 时，由于字符串的长度无效，解码将失败。如果编码没有前导+，它将很好地解码。谁能解释为什么会这样？什么会导致在某些情况下生成 + 符号？下面的示例，此字符串已编码但无法解码。
+ueJ0q91t5XOnFYP8Xac3A==
我传递的参数示例在编码之前采用以下格式，123_true 或 123_false。 “_”会导致“+”出现随机问题吗？
【问题讨论】：
+ 是常规base64 characters 之一，当被编码的 6 位的值为 62 时使用。
我的猜测是您将其放入 URL 的查询参数中，其中 + 是空格的转义值。对于该用例，您应该改用URL-safe base64 encoding：
在 URL 中使用标准 Base64 需要将“+”、“/”和“=”字符编码为特殊的百分比编码的十六进制序列（“+”变为“%2B”，“/”变为“%2F”和“ =' 变为 '%3D')，这会使字符串不必要地变长。
因此，存在针对 URL 变体的修改 Base64，其中标准 Base64 的“+”和“/”字符分别替换为“-”和“_”，因此不再需要使用 URL 编码器/解码器并且对编码值的长度没有影响，保持相同的编码形式完整地用于关系数据库、Web 表单和对象标识符。一些变体允许或要求省略填充“=”符号以避免它们与字段分隔符混淆，或者要求任何此类填充都进行百分比编码。一些库（如 org.bouncycastle.util.encoders.UrlBase64Encoder）会将 '=' 编码为 '.'。
您在此处选择的确切路径将取决于您是否控制双方 - 如果您这样做，使用修改后的 decodabet 可能是最好的计划。否则，您只需对查询参数进行转义即可。
以下示例，此字符串已编码但无法解码。
+ueJ0q91t5XOnFYP8Xac3A==
这本身就不是真的：
byte[] bytes = Convert.FromBase64String("+ueJ0q91t5XOnFYP8Xac3A==");
工作正常...表明它是损坏的字符串的传播，这与我上面所说的一致。
【讨论】：
+ 成为字符串值的一部分...
WebUtility.UrlEncode 或类似的东西。您可以通过在结果上使用 string.Replace 来使用替代的 decodabet，但前提是您同时控制编码和解码端。您的问题缺少大量上下文确实无济于事。
这个问题类似于 PHP 的solution，你可以用安全字符-、_和,替换+、/和=
string safeBase64= base64.Replace('+', '-').Replace('/', '_').Replace('=', ',')
就在解码之前，您可以替换回原来的字符：
string base64 = safeBase64.Replace('-','+').Replace('_','/').Replace(',','=')
【讨论】：