base 64编码的有效字符范围

Jim*_*Jim 44 java regex base64 apache-commons

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

Mar*_*der 86

以下是我可以发现的内容:RFC 4648

它包括这个方便的表:

                  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
Run Code Online (Sandbox Code Playgroud)

所以,正则表达式匹配,如任何字符从来没有出现在基地64个编码是:

[^A-Za-z0-9+/=]
Run Code Online (Sandbox Code Playgroud)

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

  • “ /”是标准的一部分,意味着该名称不能用于文件。同样,为什么不以A开头的0开头呢?为什么要有目的地使基本系统中的前十个数字不同? (3认同)
  • 我无法回答你的第二个问题,但 RFC 确实提供了一种不使用“/”和“+”的替代编码,并且是专门为文件名和 URL 的安全而设计的。 (2认同)
  • @MartinEnder顺便说一句,更合适的正则表达式将是'^ [A-Za-z0-9 + /] + = {0,2} $`。 (2认同)

kap*_*pex 16

在大多数情况下,你可能对其他答案很安全,但根据维基百科关于Base64的文章,你不应该依赖一个明确的清单:

为基础所需的64个字符选择的字符集的特定选择因实现而异.

RFC 4648提到了其他字母表,例如"URL和文件名安全"Base 64字母表,其中+/替换为-_.

有一个Base64变种表使用不同的字符.请记住,有关行分隔符的实现特定规则,您可以在同一个表中找到它们.像Mime这样的实现甚至允许(并忽略)不在字母表中的字符.


jlo*_*rdo 9

Base64编码只包含A–Z,a–z,0–9,+,/=.因此,不使用的字符列表是:所有可能的字符减去上面提到的字符.

出于特殊目的.,_也是可能的.