编码从0至65535全部覆盖，增加其他浏览器的兼容，0x10000到0x10ffff的字符会被scratch识别为2个字符同样没问题了
scratch应该不是utf16的小端 就是 utf16大端，因为没法直接读取内存所以哪边都没关系，而列表导出时是utf8，太有迷惑姓了.。。。之后才发现代理区的不光是被屏蔽了，还是有点作用的，毕竟utf16才用代理区，只不过不能顺序存储，间隔存储还是可以的，这应该是跟着大小写不敏感一起被处理掉了
2个字节以上的编码识别成多个字符，每个字符也按0-65535处理就没问题了
还有2.0是统一flash的，只要能用flash还是有兼容保证的，但3.0换成h5了，所以不同浏览器和系统可能不一致了，我还是换了个浏览器才发现，不过懒得合并，每种分布都加了一堆赋值
目前兼容offline，chrome66 x86，firefox64.0 x64，opera44/57 x86，都在win7下测试的，其它组合大家可以试试，里面的 模块[check] 可以测试，如果有问题希望能告诉我~
卡搭：kada.163.com(2.0&3.0)
官S：scratch.mit.edu(3.0)
卡搭：/project/1805058-2027277.htm
官S：/projects/268341702/

接口用广播"???"并等待，参数为空格分隔的十进制字符串，广播前放入全局变量"Arg"
查询广播是Unicode模块的，转换广播是Encode模块

技术贴

good

dalao

严重更新，加入清空检测，成功降低性能
初始化好的列表有些保存不住所以如果保存了，重启后有些字符会查错，不同的浏览器也同样哦

搜索了一下，scratch应该是utf8，utf16应该是系统或浏览器方面的，但保存时utf16的代理对没有转换过去，却还是去掉了错误的代理对

大概查找一个汉字要多久

上帝给你了一个展示你大师能力的机会，你却用它只到了三级

更新一下
---字符串连接改成列表拼接，2.0可以处理更长，让scratch在底层拼也可能更快点
3.0的连接已经没太小的长度限制，之前的也可以处理很长，估计最大限制也就看电脑有没有空余内存，我这连接字符串至少几千万长度，还是个拉吉平板，更大的没再试
---encode角色里增加base64
处理字节十进制，字符串先要转编码串，再转其他的字节范围的编码串（utf16be/le/utf8/xxx）
输出不是直接base64的字符串，而是字符串的ascii值，之后用unicode的编码转字符串就ok了，这样角色可以分开单独放置
另外可以直接用encode角色里的 DecStringToList积木 把变量里的十进制数读到列表，除了 0到9 都会被当成分隔符，比如小数点.和负号-，还有连续数字位数最好不要超过浮点数的精度

如果速度不正常，可以试试其他组合
比如我这chrome和咔哒2.0就很慢，不知道是flash还是其他什么影响，反倒是在firefox最新版比离线还快些
chrome和官网3.0代码编辑页面就很快，离线版也还行，之前在线3.0的项目页面比较慢，最近也好些了
总的来说我这一代i5初始化也就零点几秒到1秒左右

除了代理区的字符，都可以用 编码+1（因为第一个是编码0）从Unicode变量取得
代理区的55296-57343因为不能顺序存储，需要交叉取得，一共2048，分成每1024两部分，前面一个配上后面一个，也就是1，1025，2，1026，3，1027，。。。类似这样
或者直接调用接口获取

再更新下
ANSI模块也放到一起，不另外放了，接口改了下名，区别开
如果只搜索包括ascii在内的0-255的字符，这个要快些，固定搜索8次，unicode模块要搜索16次

Encode模块增加
Base64URL，+和/换成-和_，编码后可以放入url和文件名中
UUEncode/XXEncode，只有内容，需要自己添加每段长度和文件属性等
时区，没计算东西12时区
UNIX时间戳

又被3.0截断了，以后再改吧