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 _).所以我想这实际上取决于创建编码的实现.
kap*_*pex 16
在大多数情况下,你可能对其他答案很安全,但根据维基百科关于Base64的文章,你不应该依赖一个明确的清单:
为基础所需的64个字符选择的字符集的特定选择因实现而异.
RFC 4648提到了其他字母表,例如"URL和文件名安全"Base 64字母表,其中+和/替换为-和_.
有一个Base64变种表使用不同的字符.请记住,有关行分隔符的实现特定规则,您可以在同一个表中找到它们.像Mime这样的实现甚至允许(并忽略)不在字母表中的字符.
| 归档时间: |
|
| 查看次数: |
44228 次 |
| 最近记录: |