关于ASCII实验I'；我在用JavaScript做什么

我正在尝试开发一种新的JavaScript压缩器，这种压缩器可以在二进制文件上工作，不同于常规的缩略器（如闭包编译器）或基于词汇的打包器（如JScrush）

我的想法是：

我想压缩JS代码

alert（123）

-压缩器获取每个字符并将其从ASCII转换为二进制：

01100001 01101100 01100101 01110010 01110100 00101000 00110001 00110010 00110011 00101001

-然后，它删除每个字符的高位，因为在ASCII中它总是0

1100001 1101100 1100101 1110010 1110100 0101000 0110001 0110010 0110011

-然后，它用剩余的位生成一个长字符串

"110000111011001100101111001011101000101000011000101100100110011"

-然后，它将这个字符串切成8位的块

11000011 10110011 00101111 00101110 10001010 00011000 10110010 01100110

-然后，它将每个块转换为8位字符

ó/.²f

解码器只需做相反的事情就可以恢复原始JS

所以我用JavaScript制作了这个编码器和解码器，它就像一个魔咒：

如果你把11k个字符放在最上面，你会在最下面得到10k个字符，如果你执行最下面的代码，它就会工作。酷

但是，如果将编码脚本保存在文本文件中，则会出现问题：

-如果以UTF-8格式保存，则每个非ASCII字符将存储在2个字节上，并且压缩文件将比原始文件大

-如果将其保存为拉丁语-1（也称为iso-8859-1），则文件大小正常（每个字符可容纳一个字节），但在执行时，它不起作用，因为解码不再准确：

alers�123)

我对这个结果感到惊讶，因为UTF8的前256个代码点与Latin-1的前256个代码点匹配

如果将其保存在ANSI（又称windows-1252）中，也会出现同样的问题

有人能给我解释一下这里发生了什么，为什么它不能按预期工作，以及是否有解决方案

非常感谢

PS：这是我在JS中的编码器和解码器（但我认为问题不在JS中，而是在转码中…）

//编码器
//@param d:JS原始代码
函数e（d，b，f，c，a）{b=a=“”；for（d+=“；”）c=d.charCodeAt（f），a+=（1e6+c.toString（2））.slice（-7）；for（；7i；i++）b+=（1e7+a.charCodeAt（i）.toString（2））.slice（-8），c+=String.fromCharCode（parseInt（b.substr（i*7,7），2））；eval（c）

没有通用压缩器可以假定输入为ASCII，因此您的第一步（删除高位）不起作用。UTF-8使用所有八位，而不仅仅是低七位：如果您的UTF-8文件包含BOM或UTF-8中需要高阶位的数千个字符中的任何一个，它将失败。事实上，我的压缩器假定输入仅为ASCII。只要我们遵守这一规则，它就会工作。（但JS文件中只有ASCII字符并不难，因为非ASCII字符可以转义。）.UTF-8的前127个字符与127个ASCII字符匹配。编码的脚本不是文本，那么你为什么希望文本编辑器能够正确处理它？@Eric：我误解了。是的，的确如此！天知道编辑器将如何处理数据，它看起来不像文本…@xem没错！终于有人尝试了一些非开箱即用的创意我希望有更多像你这样的帖子。

// Encoder
// @param d: original JS code
function e(d,b,f,c,a){b=a="";for(f in d+=";")c=d.charCodeAt(f),a+=(1e6+c.toString(2)).slice(-7);for(;7<a.length;)c=String.fromCharCode(parseInt(a.substring(0,8),2)),b+=c,a=a.slice(8);return b}

// Decoder:
a='(encoded JS code)';b=c='';for(i=0;(original JS length)>i;i++)b+=(1e7+a.charCodeAt(i).toString(2)).slice(-8),c+=String.fromCharCode(parseInt(b.substr(i*7,7),2));eval(c)