EasyRSC重要说明
有些杀毒软件会提示easyrsc.exe有木马病毒（比如R星），这完全是杀读软件过敏...
至于为什么R星会有这种提示，是因为easyrsc.exe是非正常方式编译出来的exe，具体的东西，有些技术保密的成分，就不能说太多了。
EasyRSC使用教程
关键字
Symbian，汉化，工具，A码，偏移。
适用范围
使用EasyRSC V0.3 B060727进行SymbianOS A码资源汉化。
环境要求
windows 2000以上或linux red hat 7以上及同档次其他操作系统。
10M以上可用硬盘空间
128M以上系统内存
正确安装有JRE 5.0 updata 6运行环境。
预备知识
从接触汉化之后很久我才习惯了大家对U码A码的叫法。这种叫法，其实本身是错误的。
我们先来简单回顾一下Symbian的发展历史，在SymbianOS 5.1之前的系统，是不支持国际化语言的，使用纯粹的AscII，如果说“A码”，OS5.1之前的才能叫A码。
随着各行业国际化进程的发展，Symbian从5.1开始，支持国际化语言。如果大家又一些编码知识就能知道，Uincode使用双字编码，可以含盖各国语言字符。SymbianOS5.1至OS6.1的系统，对资源文件使用legacy Unicode编码。这种编码方式最显而易见的特点就是中文（或者其他什么文字）、英文都是双字节编码。这也就是大家所说的U码资源。
Unicode编码虽然解决了国际化问题，但是随之带来了一个比较严重的浪费问题：本来一个字节就可以表示的ASCII，却使用了两个字节。对于手机这种计算能力和存储空间都非常有限的设备，这种浪费的确让人很难接受。于是，从Symbian OS7引入了新的编码方法：Compressed-Unicode和D-Compressed-Unicode（目前我们见到的都是Compressed-Unicode，D-Compressed-Unicode编码方式的rsc我也一样没有见过，呵呵）。
所谓 Compressed-Unicode，字面看法就是“压缩Unicode”。这种编码，英文ASC II占用1字节，中文等其他文字，通过相应的压缩算法，占有不定量个字节。比较常见的压缩Unicode，就是Java编译后使用的UTF-8编码，汉化过Java的同学们肯定都有了解。而Symbian采用的是一种几乎已经被人遗忘的压缩方法：SCSU。关于SCSU我这里不多说了，有兴趣的同学可以自己去Unicode编码组织学习。
严格的说，SymbianOS7使用的资源文件应该叫CU编码，不过大家既然都习惯叫A码，那么咱们约定下面所有提到A码的地方指的都是CU编码。
我还要重点的提一下大家手动汉A码，因为这跟后面用EasyRSC汉A码有很大关系。现在大家手动汉化A码时候使用其实还是legacy Unicode编码，所以要加那些0xOE 、0xEO 、0xAB之类的标志。SymbianOS7可以根据这些标识自动支持。但是严格的说，现在所有汉化A码用的编码，都是不符合SDK规范的。正确的规范，应该使用Compressed-Unicode编码来写入中文。
听起来是不是很有趣：以前所有的A码汉化，都是不符合标准的：）
手动汉A码掠影
为了给使用EasyRSC打好基础，在这里再带着大家简单回顾一下手工汉A码的基本过程。
不得不承认，手工汉A码的确是一件很需要毅力的工作，这也是我要编写EasyRSC这样一个工具的原因。
有些杀毒软件会提示easyrsc.exe有木马病毒（比如R星），这完全是杀读软件过敏...
至于为什么R星会有这种提示，是因为easyrsc.exe是非正常方式编译出来的exe，具体的东西，有些技术保密的成分，就不能说太多了。
EasyRSC使用教程
关键字
Symbian，汉化，工具，A码，偏移。
适用范围
使用EasyRSC V0.3 B060727进行SymbianOS A码资源汉化。
环境要求
windows 2000以上或linux red hat 7以上及同档次其他操作系统。
10M以上可用硬盘空间
128M以上系统内存
正确安装有JRE 5.0 updata 6运行环境。
预备知识
从接触汉化之后很久我才习惯了大家对U码A码的叫法。这种叫法，其实本身是错误的。
我们先来简单回顾一下Symbian的发展历史，在SymbianOS 5.1之前的系统，是不支持国际化语言的，使用纯粹的AscII，如果说“A码”，OS5.1之前的才能叫A码。
随着各行业国际化进程的发展，Symbian从5.1开始，支持国际化语言。如果大家又一些编码知识就能知道，Uincode使用双字编码，可以含盖各国语言字符。SymbianOS5.1至OS6.1的系统，对资源文件使用legacy Unicode编码。这种编码方式最显而易见的特点就是中文（或者其他什么文字）、英文都是双字节编码。这也就是大家所说的U码资源。
Unicode编码虽然解决了国际化问题，但是随之带来了一个比较严重的浪费问题：本来一个字节就可以表示的ASCII，却使用了两个字节。对于手机这种计算能力和存储空间都非常有限的设备，这种浪费的确让人很难接受。于是，从Symbian OS7引入了新的编码方法：Compressed-Unicode和D-Compressed-Unicode（目前我们见到的都是Compressed-Unicode，D-Compressed-Unicode编码方式的rsc我也一样没有见过，呵呵）。
所谓 Compressed-Unicode，字面看法就是“压缩Unicode”。这种编码，英文ASC II占用1字节，中文等其他文字，通过相应的压缩算法，占有不定量个字节。比较常见的压缩Unicode，就是Java编译后使用的UTF-8编码，汉化过Java的同学们肯定都有了解。而Symbian采用的是一种几乎已经被人遗忘的压缩方法：SCSU。关于SCSU我这里不多说了，有兴趣的同学可以自己去Unicode编码组织学习。
严格的说，SymbianOS7使用的资源文件应该叫CU编码，不过大家既然都习惯叫A码，那么咱们约定下面所有提到A码的地方指的都是CU编码。
我还要重点的提一下大家手动汉A码，因为这跟后面用EasyRSC汉A码有很大关系。现在大家手动汉化A码时候使用其实还是legacy Unicode编码，所以要加那些0xOE 、0xEO 、0xAB之类的标志。SymbianOS7可以根据这些标识自动支持。但是严格的说，现在所有汉化A码用的编码，都是不符合SDK规范的。正确的规范，应该使用Compressed-Unicode编码来写入中文。
听起来是不是很有趣：以前所有的A码汉化，都是不符合标准的：）
手动汉A码掠影
为了给使用EasyRSC打好基础，在这里再带着大家简单回顾一下手工汉A码的基本过程。
不得不承认，手工汉A码的确是一件很需要毅力的工作，这也是我要编写EasyRSC这样一个工具的原因。
言归正传，下面是一个经典的A码资源：
04 04 49 6E 66 6F
第一个04，表示资源内容有4个字符
第二个04，表示资源内容有4个字节长
49 6E 66 6F是英文 Info
汉化时候，我们把info汉化成“信息”，假如“信息”的编码是： B1 B2 B3 B4
那么正段字节就改为
02 04 B1 B2 B3 B4
当然，很多情况下，字节是不能对这么整齐的，比如：
07 07 4E 65 74 77 6F 72 6B
4E 65 74 77 6F 72
6B是英文Network，我们汉化为“网络”，两个汉字，只占4个字节，
填不满原本的7个字节，这样的时候，我们就不得不补空格啊、补0x00啊，补0xFF啊之类的补来补去。
这还不是最郁闷的，最郁闷的是，有些时候，你想补都没的补，比如：
03 03 43 75 74
43 75 74是英文Cut，我们汉化为“剪切”，两个汉字，占4个字节。天啊，可用的只有3个字节位置，怎么办...这种情况下，又要到处借位置，或者进行更BT的工作：改资源偏移。
改字符偏移的教程，大家可以看看
[url]http://www.bwo.com.cn/forum/read.php?tid=106742&fpage=1[/URL]，反正我觉得我绝对没毅力自己手动改偏移——那真不是人干的。
刚才还提到了，以往汉化时候用的编码其实都不对。不过话要两头说，普通Unicode很多工具都可以转换出来，SCSU这种bt编码，还真难找到转换工具。不是我不想按规范，是实在没工具...
当当当，以上为小广告：）
综合以上的恶心问题，我编写了EasyRSC，可以为大家提供简单便捷的A码汉化。在正式开始使用EasyRSC汉化东西之前，俺要喊个口号：工具的作用是提高效率，不是解决所有问题，唯一能解决所有问题的还是自己的大脑和双手。
EasyRSC功能介绍
支持A码资源汉化（汉化U码请找本人编写的RSCEditor）。
自动修正资源偏移，汉化过程中不用再考虑任何补位、借位、偏移之类的。
支持并且建议使用压缩Unicode编码方式汉化。
EasyRSC汉化过程
启动easyrsc，点击“打开”按钮打开一个A码rsc文件。
界面分为以下几个主要部分：
1.资源树列表，有可展开的节点，说明其下还有子资源。
2.字节显示框，这是一个只读框，用于显示选中资源的字节序列。
3.资源修改框，在这里输入修改后的资源字节序列，就行资源修改。
4.文字转码框，在这里输入需要转换的文字。
5.文字转码后的字节序列框，这里输出转码结果。
从资源树内，顺序查找，需要修改的资源，一般来说，如果是需要的修改资源，会在2框内看到资源内容。
在EasyRSC内，修改资源分类两种情况：一种是节点本身不存在子节点的，这种直接修改资源本身；另一种是存在子节点的，这种只能修改子节点，修改子节点后，程序会自动更新其根节点。
现在我们选中一个没有子节点的资源，比如“SExplorer”，字节序列为：“09 53 45 78 70 6C 6F 72 65 72”。细心的朋友也许已经发现，这个资源跟前面讲手工汉A码时候的资源不一样，只有一个0x09表示字节长度，没有表示字符长读的字节了。事实情况的确是如此，这涉及到比较繁琐的rsc编译规则，就不展开讲了，只要大家知道，多数情况下，这种没有子节点的资源是以这种方式存储的。注意，只是多数情况，不是绝对情况！
现在我们将“SExplorer”汉化为“超级浏览器”。
在4框内输入“超级浏览器”；前面我们抨击了半天应该用压缩unicode来汉了，所以转化选项里面选“压缩Unicode”；没有子节点的资源只有字节长度标志没有字符长度标志，所以，附加条件选“带字节长度”，不选“带字符长度”，压缩unicode，不需要另外设置unicode标志，所以也不选“带汉子标志”（其实选了也不生效）；选好之后，按“文字->字节”转换，在5框内将出现转换后的结果。
将转换后的字节，复制到字节修改框3内，点击“替换”，即完成此资源的修改。简单吧，嘿嘿。
接下来我们再找个带子节点的资源来汉一下。
在子节点里面找到一个“Open”资源来进行汉化，看起来似乎跟无子节点的资源一样，同样是没有字符长度标志。
如果真是这样，我就不用单独拎出来说道了。
一般情况下，有子节点的资源，都是符合“字符长度
字节长度 内容”这种格式的，可是我们为什么看不到字符长度呢？其实是因为字符长度这个字节被划归到上一个子节点里了。
这样，我们在修改“Open”资源时候，就要同时修改两个节点。
用转换框转换“打开”，这次要多选中一个“带字符长度”来备用，转换结果是：
02 05 0F 62 53 5F 00
02是字符长度
05是字节长度。
进行修改时候，有两种方式：
方式1：用05 0F 62 53 5F 00 替换 "Open"所在节点，然后修改Open前一个节点的最后一个字节为02。
方式2：用02 05 0F 62 53 5F 00
替换"Open"所在节点，然后将Open前一个节点的最后一个字节删除。
按如上所述，一步一步将需要修改的资源修改后，保存文件即可完成汉化工作啦~~~
后记
EasyRSC目前版本为0.3版，功能和易用性方面还有很多不足，希望大家在使用过程中多多摸索，多多提意见。