大多数编号系统从零开始，经过以 10 为基数的数字，然后在用完以 10 为基数的数字后转到字母：
Binary: 0,1 Octal: 0,1,2,3,4,5,6,7 Decimal: 0,1,2,3,4,5,6,7,8,9 Hexidecimal: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F
即使是字符的 ascii 顺序，数字也位于字母之前。
Base64 编码方案的做法有所不同：
┌──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┬┬──────┬──────────┐
│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 ││ │ │
└──────┴──────────┴┴──────┴──────────┴┴──────┴──────────┴┴──────┴──────────┘
base64 选择在数字之前处理字母有什么原因吗？用编码
00我最近正在研究一般的基数转换，并遇到了这个完全相同的问题。有趣的是，六年多来没有人对此发表任何评论。虽然我没有具体的答案，但这里有一些支持信息：
您提到的“Base64”被称为“RFC 4648”。我找到并阅读了相关规范，最后它提到了各种贡献者姓名和 RFC 的主要作者：Simon Josefsson。那里有一个联系电子邮件，所以如果有人知道答案，这可能是一个开始的地方。
RFC 4648 没有什么神圣之处，这意味着“Base64”本质上不需要遵守该推荐标准。当然，不同的图书馆已经以这种方式跨多种语言实现了它，并且它最终被广泛用于编码电子邮件 - 并且显然在跨古代电子邮件系统传输二进制图像数据方面表现良好.
但在我看来，RFC 4648 的使用“只是因为”遗留的建立，而不是因为它是“最佳”解决方案。对这个“Base64”的每一个解释都只是从解释 6 位组的划分开始，等等，而没有深入了解更根本的“为什么”。也就是说，这些文章似乎假设该 RFC 4648 是 Base64 编码的“the”标准（而不是“a”标准）。如果我们使用更直接的方法，从 0-9 而不是 A-Z 开始，那么跨系统传输二进制数据的基本目标会发生哪些破坏或变化？对于任何一般的基本转换，您只是索引到一系列“可接受的可打印字符”（并且任何解码器都必须认识到所使用的原始系列）。无论如何，我同意从字母开始而不是数字开始的转变看起来“奇怪”，没有明显的理由。
这并没有回答具体问题，但我希望它能引发更多关于它的讨论。我们可能只需要设置一个实验“如果我们只改变所使用符号的顺序会怎样”，也许一些实际原因可能会显现出来。一个原因可能只是这种转变是一种故意混淆，以使任意“安全符号集”用于传输二进制数据的目的变得不那么明显。