许多文件类型都有一个头部(文件的前几个字节),其中包含一些固定信息,可以将文件识别为gz、png、pdf等格式。
因此,每个base64编码的gz文件也会以某个特定的base64字符序列开头,以便进行识别。
gzip-file始终以两个字节序列0x1f 0x1b开头,在base64编码中是
H4
加上第三个字符在
s
到
v
范围内。
原因是每个base64字符表示6位原始字节,因此两个字节
0x1f 0x1b
用两个base64字符(12位)加上第三个字符的前4位进行编码。
基于此,我认为你展示的不是base64编码的gzip文件。
其他例子包括:
png
以0x89 0x50 0x4e 0x47 0x0d 0x0a 0x1a 0x0a
开头
base64编码:iVBORw0KGg...
jpg
以0xFF 0xD8 0xFF 0xD0
开头
base64编码:/9j/4...
gif
以GIF
开头
base64编码:R0lG
tif
a) 小端格式:
以0x49 0x49 0x2A 0x00
开头
base64编码:SUkqA
b) 大端格式:
以0x4D 0x4D 0x00 0x2A
开头
base64编码:TU0AK
flv
以FLV
开头
base64编码:RkxW
wav/avi/webp和其他文件类型
多种音频/视频/图像格式都基于RIFF(资源交换格式),共同点是所有文件都以RIFF
开头
base64编码:UklGR
在RIFF
头之后,您将在第9个字节开始的4个字节中找到特定格式的起始位置。
以下使用_
作为任意字符的占位符。
wav
以RIFF____WAVE
开头
base64编码:UklGR______XQVZF
webp
以RIFF____WEBP
开头
base64编码:UklGR______XRUJQ
avi
以RIFF____AVI
开头
base64编码:UklGR______BVkkg
关于问题中的具体示例:
在更新后的问题中,附带图片提示数据首先进行base32编码,然后进行base64编码。
当我们使用在线base32解码器输入问题中给出的字符串(JA2HGSKBJI4DSZ2WGRAS...
)时,我们得到:
H4sIAJ89gV4A/+1ZURaEIAi8SkfQ+1/O3f7MtEBfMgz9rC/diXmIA5hSzun3HNdBbgbtVP2v/2+LowM837wFHKxZbmE9pQfsLOaiLAL8kvIk4MBma17ufHQbIJCXoWNZZKGPWB5QljvXIuXOmm0SgLixJw8HRC8Tbmz7x5eIspypaZHSWbj8cAhdjli2WUkR1sv2dZmwXhZlDnIcCl0GyrFX6fKkBEBTBsq+9uY2Ecug2Rf0xtaJlNdYJuxjP9kcd1LOW/fQXtb1sd3fSTGXFTx3UjfGFx6uJGjeIAAA
它以H4s
开头,所以根据我关于如何识别base64编码文件类型的写作,它是一个base64编码的gzip文件。
这可以保存在文本文件中,然后上传到base64decode.org,它将被转换为gzip文件。当您下载并打开该gzip文件时,它包含一个像这样的文本文件:
00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110000 00100000 00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110001 00100000 ...
这个案例的结论是:原始字符串/文件是一个gzip文件,首先进行了base64编码,然后对base64编码部分再次进行了base32编码。
m9zMTgKc6o3n8Ye9kOhC4r8loBBCwvARYk94bfSj1YeMpSvAvtLrR1FAdjfnrEl
,很可能还包含一些+
和/
。 - undefined