base 64 编码的有效字符范围 | 编码的有效字符范围

本文介绍了base 64 编码的有效字符范围的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我对以下内容感兴趣:
是否有一个字符列表永远不会作为 base 64 编码字符串的一部分出现?
例如 *.我不确定这是否会发生.如果原始输入实际上有 * 作为它的一部分，那么它的编码方式会不同吗?

I am interested in the following:
Is there a list of characters that would never occur as part of a base 64 encoded string?
For example *. I am not sure if this would occur or not. If the original input actually had * as part of it would that be encoded differently?

推荐答案

这里是我可以找到的:RFC 4648

它包括这个方便的表格:

It includes this convenient table:

                  Table 1: The Base 64 Alphabet

 Value Encoding  Value Encoding  Value Encoding  Value Encoding
     0 A            17 R            34 i            51 z
     1 B            18 S            35 j            52 0
     2 C            19 T            36 k            53 1
     3 D            20 U            37 l            54 2
     4 E            21 V            38 m            55 3
     5 F            22 W            39 n            56 4
     6 G            23 X            40 o            57 5
     7 H            24 Y            41 p            58 6
     8 I            25 Z            42 q            59 7
     9 J            26 a            43 r            60 8
    10 K            27 b            44 s            61 9
    11 L            28 c            45 t            62 +
    12 M            29 d            46 u            63 /
    13 N            30 e            47 v
    14 O            31 f            48 w         (pad) =
    15 P            32 g            49 x
    16 Q            33 h            50 y

因此，匹配任何应该从不出现在 Base 64 编码中的字符的正则表达式将是:

So a regular expression that matches any character that should never appear in Base 64 encodings would be:

[^A-Za-z0-9+/=]

然而，正如 kapeps 的回答所指出的，这只是建议.特定的实现可能会选择一组不同的 64 个字符.(事实上，即使链接的 RFC 也包含一个用于 URL 和文件名安全编码的替代表，它分别用 - 和 _ 替换了字符 62 和 63).所以我想这真的取决于创建编码的实现.

However, as kapeps answer points out, this is only the recommendation. Specific implementations might choose a different set of 64 characters. (In fact, even the linked RFC contains an alternative table for URL and filename safe encoding, which replaces character 62 and 63 with - and _ respectively). So I guess it really depends on the implementation that created the encoding.

这篇关于base 64 编码的有效字符范围的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！