想问一下这种字符串是 base64 吧？为何解码后乱码啊？是我解的有问题还是这个不是 base64

[timedivision]

studyTime: 
nxcUhOHtnq8U5OiQFRyVIQ==
lessonLocation: 
KuT9XK4MVaizQbjef2R+ug==

studyTime: 
0oA/lBN+vUvGhhYXmElIlQ==
lessonLocation: 
TlUnVu8KwPj09tCjakR66Q==

studyTime: 
XU7cDi+6eAuZvwFTaHHFzw==
lessonLocation: 
BRpMW/INcTNMp4c80DWX4g==

studyTime: 
0ZdZgweOU9CM7MhzBvGExw==
lessonLocation: 
z6QsH/c/vXJA19zpRqak/w==

[GeruzoniAnsasu]

长度这么规整，原数据精确 128 位

推测是 MD5

[JohnBull]

猜测应该是编码之前对称加密过了

[JohnBull]

@GeruzoniAnsasu 从 studyTime 和 lessonLocation 的字面上看，应该是明确的时间地点信息，应该是要取出来用的，应该不是 md5 ，而是某种加密算法

[dingwen07]

echo "nxcUhOHtnq8U5OiQFRyVIQ==" | base64 -d | xxd
00000000: 9f17 1484 e1ed 9eaf 14e4 e890 151c 9521 ...............!

完全看不出来这是什么

[msg7086]

为什么 base64 解码后不能是乱码呢。

[dingwen07]

@msg7086 #5
更值得问的问题是，不乱码的字符串，为什么要用 base64

[LykorisR]

可能是换表 base64 吧，你找找有没有新表

[chendy]

base64 解码是 string -> byte[]
byte[] 不一定是字符串编码得到的，所以得不到字符串很正常

[icegaze]

我小时候经常用 base64 把一些 exe 文件编码后作为邮件主体发送给对方…

因为那时候对 BIN 的编码还在用 QP ，
用 base64 效率更好些。

所以，
用 base64 编码的不一定是文本文字哦…

[geekvcn]

这是打算逃课吗？

[julyclyde]

如果原文是 human reabable 谁还去 base 啊……

[julyclyde]

@icegaze 小时候邮件服务器还 7bit 么？
1997 年我调研的时候已经找不到这么旧的服务器了呢

[lanwairen123]

用其他对称加密算法如 aes des rsa 等加密后用 base64 编码的

[Promtheus]

base64 只是为了序列化，用来传输。他的源头不一定是文本的

[timedivision]

@geekvcn 问的没错，就是准备逃课，哈哈哈

[q8515620]

逃课的话，解不出来不是更好吗？/doge

[someone120]

目测为 aes 加密，base64 应该不会出现 /和+的

[ElmerZhang]

看起来是 hash 过又 base64 的

[yolee599]

base64 的功能不是只编码 ASCII ，而是编码 HEX 。

[locoz]

盲猜 AES 套 Base64 方便传输，不是 AES 的话大概率 DES 。

[liuguang]

你见过 ssl 证书吗？也是 base64 编码的。base64 只是把二进制数据编码为可读的字符串，并没有说这些二进制数据一定是字符串。

[shawndev]

base64 decode, 输入是 string ，输出是 bytes ，从来没有说过输出一定是一个有效的字符串啊。

如果你关心的是为什么不是所有 bytes 都能解码为字符串（ ASCII, UTF-8 ）那就是另一个问题了。

[jiangzm]

@ElmerZhang 用 hash 数据传字段值吗， 这么牛

[icegaze]

@julyclyde 1995 年 1996 年吧，基本上邮件很少有直接发到对方服务器的，多多少少会经过中间邮件服务器中转，只要有一个服务器是 7bit 的，就会发生错误，，，所以非 ASCII 的文件，习惯于自己先编码一下，放在邮件 body 里，这样安全些。

[itskingname]

任何二进制信息都能编码成 Base64.图片也可以。所以并非所有 Base64 解码后都能得到字符串。

[thinkershare]

base 64: encode: bytes ==> string decode: string==> bytes
byte 里面是什么，只有天知道, 或者瞎猜, 使用各种 encoding 尝试解码， 只是因为大部分字符串编码都兼容 ASCII, 所以解码出来的 bytes[]恰好可以直接和 Unicode 16 的字符串匹配，纯粹就是一个巧合。JavaScript 原来没有原生的 UInt8Array ， 使用了 string 来表示了 byte[]，所以 btoa 就是不支持中文(因为中文的 Unicode 并没有办法直接对应到 byte[])， 你找个强类型语言，你会发下输入都是 byte[], 解码后也是 byte[], 至于 byte[]里面的内容，只有创建人清楚。

[ElmerZhang]

@jiangzm 因为所有值的长度都一样是 32 位，而且随机性比较强，所以猜测是 hash 过的。当然也有可能是自创了什么加密算法，那就很厉害了。

[ElmerZhang]

@jiangzm 另外，如果是选课系统的话，lessonLocation 和 studyTime 的值实际都是有限的，可枚举的，所以提前 hash 一下再传输也是有可能的，不过这样的话前端肯定会还会有一次「字典请求」来把 hash 和展示的值对应起来。

[julyclyde]

@icegaze 啊？都经过哪些中间服务器了？
现在除了反垃圾网关，基本上都是直达吧

[JohnBull]

@icegaze 你暴露年龄了！ 用 uuencode 的人都悄咪咪不说话

[jiangzm]

@ElmerZhang lessonLocation 和 studyTime 原始数据长度应该一样，才可能加密后数据长度一样
lessonLocation 两个经纬度值
studyTime 两个时间戳

[whoami9894]

@ElmerZhang 百度一下分组加密的 padding

[icegaze]

@julyclyde ^_^ 现在是的呀，都直接和对端 smtp 服务器连接的，，，我小时候那大多是经过好几个服务器中转的…>_<

[icegaze]

@JohnBull and ，还有用电话线下载上传 FIDO 的 BBS……^_^

[julyclyde]

@icegaze 你小时候，当时他们域名是怎么指向的？把自家域名 MX 指向别人？
那个域名自己的邮件服务器不上公网吗？

[julyclyde]

@icegaze FIDO 我也玩过，不过我当时的软件不支持 ZMODEM 所以只能看文字不能下载压缩包

[icegaze]

@julyclyde

哈哈哈，不是的，
当年的邮件服务器，域名是和现在一样的，也是能解析到 ip 地址… 但是 smtp 通常无法直接在两个远程 ip 之间通讯（我也不知道为啥），一般是经过中间的几个公共服务器中转，每次中转都会在邮件的头 head 里留下一些信息… 然后你收到邮件的时候就能看到这封邮件都经过了哪些地方，还挺好玩的。

[julyclyde]

@icegaze 我当然知 Received header
但我问的是：如何指示这个路径
SMTP 就是靠 MX 记录的，除了反垃圾网关，还真存在过别的指法么？
难道你用过 UUCP ？