以古董后台语言 asp 为例，为了保证明文代码不被最终使用者修改或抄袭，有多种方法对代码进行编码，执行时再解码。也可以直接将代码全部编译入 COM+ 组件 ，但是这需要每次都编译，不适合日常使用。
因此，这里考虑的是，利用自定义 COM+ 组件的函数来对编码代码进行解码并执行的情况（ VB6 、C 等语言均可编写 COM+ 组件，写法这里不讨论，请检索相关文章）。
因为最终执行时，需要进行完全解码出明文，因此，编码算法就只能选择可逆编码类型的。
如： 易位 base64 、AES 、RSA 等。
首先，需要有预设密钥（公钥、编码表等），
然后需要一个编码算法程序（base64 、AES 、RSA 等）
将明文后台代码编码为乱码后，为了能在后台正确执行，需要在服务器端需要安装对应的解码函数 COM+ 组件 ，该 COM+ 组件为了解码编码的代码，那么就必须输入解密的密钥。
后台代码是在最终用户的服务器上，解密用的 COM+ 组件必须能读懂该密钥，但你不能让最终用户读懂该“密钥”，否则其可以解密你加密编码的后台代码。
因此，我采用预设内置编码的方法来编码解码密钥等信息，输入该解码组件。
而如果最终用户手上有你预设好加密密钥的加密编码程序，那么，通过输入特定顺序的加密原文即可很轻松的破解出加密算法及其密钥。
比如，base64 编码，它本身就不是设计用于加密，但如果采自定义码表，再加上易位操作等之后，仅凭编码结果，基本上是不可能解密的。
但是如果有对应的编码程序，那么只需要编码 0~63 这 64 个数以 6 位组成的二进制串：
/*
十进制 二进制
0= 000000
1= 000001
2= 000010
3= 000011
......
62= 111110
63= 111111
十进制 0 1 2 3 ...... 62 63
二进制 000000 00 | 0001 0000 | 10 000011 ...... 1111 10 111111
十六进制 0 0 1 0 8 3 F B F
最终得到 48 字节十六进制数据：
00 01 83 10 51 87 20 92
......
5D B7 E3 9E BB F3 DF BF
*/
再按八位拆分为十六进制数据后，得到的 48 字节的这串数据让其编码，那么编码出来的最终结果就是你的自定义编码表：
/*
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
因 48*8/6=64 ,按 6 位刚好截取完，故编码结果无需末尾的补零 = 号，
但是，可知编码结果中出现的不同字符为65个，除去上面编码出来的64个，
剩下那一个就是结尾补零字符。
*/可见，最终需要保密的不是什么编码表，也不是密钥，而是编码过程程序，因为其中有自定义易位编码函数等，只要不知道加密原文，那么在没有编码程序的情况下，光凭密文是没办法解密的，即使你有编码表和密钥也不行。
因此，这个代码加密方案不适合推广给别人用，只适合在自己保密编码算法的情况下给编码后台代码给最终用户运行。
最终逻辑就是，你用卖给客户一个产品，但是因为加密的启动钥匙已插在产品上，客户无法看懂加密的钥匙，产品能正常使用，所以客户打不开你也不希望客户能打开产品窥探其中的玄机，这时候，客户是基本无法打开产品外壳的。由于启动钥匙生产工具在你手上，所以客户无法自己生产钥匙，也就不可知钥匙和产品的关系。
但是如果你将钥匙生产工具交给了客户，那么客户就可以通过输入不同的原材料而推导出产品和原材料的关系，从而将之前你提供的钥匙进行破解，最终可打开产品外壳。
也就是说，最终需要保密的是产品生产过程。
由此可推得，只要是可逆编码，均可由编码过程得到解码方法，AES、RSA 也一样，因此为何不选择效率更高的自定义 base64 编码呢？
‘--------------------------------------------------------------------------------------------------------
以上举例的 uuecode.bin 文件可将以下字符串（base64码表）保存为 uuecode.bin.txt ：
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/然后用我之前提供的 base64&UUE文件编码解码程序，以 base64 方式解码即可得到。
欢迎感兴趣的朋友留言讨论，以下为一串纯文本字符串用自定义 base64 码表多次编码得到的字串，有兴趣的可以挑战解码看看：
QubzgWcRuf4WsZ1SuWkU9K0MuyQSY8s3
