VC51使用说明 用途。 我们所使用的keil c51，是不支持中文标识符名的。但对于中国人来说，还是用中文作标识符比较符合思维习惯。VC51就是为了能实现此目的，而编写的一个小工具。 使用方法。 安装：此工具是开源的，用的是VC++编译环境。用户可自己编译。编译生成EXE文件，将keil安装目录下的“.\C51\BIN\c51.exe”重命名为“kc51.exe”。将编译后的文件复制到“.\C51\BIN\”下，并命名为“c51.exe”。 使用：在编写keil的C代码或H代码中，希望使用中文标识符名时，需要按照如下格式：“nameof(“变量名字符串”)”。这样，经过VC51工具的处理，就能正确编译了。 举例： 实现原理。 先说一下c51的实现原 理吧。c51是一个可以在命令提示符环境下通过命令调用的编译工具。其命令格式有两种：“C51 sourcefile [directives…]”或“C51 @commandfile”。我们使用的keil前台是通过后一种命令来实现的。commandfile是keil在编译前临时生成的文件，其内容就是真正要传递给c51的编译参数。c51处理结束后，把结果返回。我们就能看到编译是否成功，如果有错误，错误是出在哪了。是不是看着有点乱呢？还是举例吧。比如我们要编译“main.c”。 下面就说说VC51是怎么实现的。VC51把自己伪装成C51，而把真正的C51更名为KC51。这样，前台发的命令就被VC51收到了，也就知道了要对谁进行编译。但是考虑到被编译的文件可能会调用到各头文件。所以本着“宁可枉杀一千，不叫一个漏网”的原则。VC51首先会把工程所在目录及子目录下的所有C文件和H文件，全部复制到工程目录下的“VC51FILS”文件夹中。当复制的同时，就会对文件中的中文标识符进行处理，具体怎么处理，我们在下一点中说。复制完就给KC51，也就是真正的C51发命令，不让它处理原文件了，而是处理我们复制后的文件。然后把KC51的结果返回给前台。说白了，就是在IDE前台和C51的通信之间进行“传话”，在传话的过程中，我们作手脚。 下边就说怎么作手脚了。前文已经说了，我们的中文标识符必须按照“nameof(“变量名字符串”)”的格式。我们复制的时候，把所有出现这样格式的内容都替换掉。“nameof”还保留不变。“(“变量名字符串”)”都变成对应GB码的十六进制字符。这样，标识符就符合规范了，即，由字母数字和下划线组成，并且由字母或下划线开始。例如：“nameof("示例变量")”替换后就是“nameof2822CABEC0FDB1E4C1BF2229”。当然长度上肯定是增加了。所以不要超过规范规定的字数限制哦。 VC51对C51返回的结果也作了一些处理。因为返回结果中会包含（不是每次都包含）我们复制后的路径。而IDE前台会根据路径来查找对应的文件。比如我们的文件语法有误，如果不对结果进行处理，我们在编辑环境中，双击错误信息，出来的就是复制后的文件，而不是原文件。所以我们把结果中出现的路径还还原为原路径，IDE前台就以为是原文件了。 补充说明。 本软件完全开源，用户可自行修改和使用。但由此可能引发的版权纠纷或其他后果，均由用户自负。因此建议仅供学习与交流使用，请勿用于商业用途。 上面我们说到编译任何一个文件时，都会复制全部的C文件和H文件。其实还有一步详细的处理。原文件进行替换完毕，VC51会把替换结果与已经存在的文件作比较。若长度和CRC校验都符合，就不再写文件；否则才会写。这样能有效减少写的次数。 工程中文件的结构，需要符合这样的格式，所有C文件和H文件都需要位于工程文件所在目录和子目录中。如果不在这范围内，则不能出现中文标识符。 我发现的不完善的地方，真正的C51工具，在某个文件修改后，如果选择“build target”，KEIL只会对修改过的文件进行编译，不编译没修改过的。但在VC51下，KEIL对修改过的文件也“视而不见”。我猜测可能的原因是，C51编译后会产生一些存储相关信息的文件，而这些文件中的路径是我们作过手脚的路径，因此对原路径修改的文件不能正确识别。这一点也请大家共同研究探讨。 可增加的功能。VC51返回的结果中，与中文标识符相关的内容，显示的会是我们替换后的形式。而这个形式是可再“翻译”回来的。目前没加这个功能，但理论上是可实现的。而且我想，就算没这功能，影响也不大。如果哪位愿意加上，我也是举双手双脚来赞成的。 理论上，可用类似的方法，实现在MDK中使用中文标识符。我的直觉告诉我，那个叫“armcc.exe”的文件，就是编译器了。 这工具是我利用业余时间所编，时间仓促，而且我对VC也不是太熟悉。软件中存在漏洞或待完善之处的可能还是蛮大的。代码中注释也不多，几乎没有。这个习惯可不好，不是程序员应有的。实在是时间不允许，请大家见谅。欢迎大家共同交流，使VC51有更好的改善，或是能编写出更好的工具来。我的联系方式写在最后了。 我的联系方式： 邮箱：sdkdwj@163.com，或QQ邮箱。 QQ：342581660（当前昵称：基督徒）。 理吧。c51是一个可以在命令提示符环境下通过命令调用的编译工具。其命令格式有两种：“C51 sourcefile [directives…]”或“C51 @commandfile”。我们使用的keil前台是通过后一种命令来实现的。commandfile是keil在编译前临时生成的文件，其内容就是真正要传递给c51的编译参数。c51处理结束后，把结果返回。我们就能看到编译是否成功，如果有错误，错误是出在哪了。是不是看着有点乱呢？还是举例吧。比如我们要编译“main.c”。 下面就说说VC51是怎么实现的。VC51把自己伪装成C51，而把真正的C51更名为KC51。这样，前台发的命令就被VC51收到了，也就知道了要对谁进行编译。但是考虑到被编译的文件可能会调用到各头文件。所以本着“宁可枉杀一千，不叫一个漏网”的原则。VC51首先会把工程所在目录及子目录下的所有C文件和H文件，全部复制到工程目录下的“VC51FILS”文件夹中。当复制的同时，就会对文件中的中文标识符进行处理，具体怎么处理，我们在下一点中说。复制完就给KC51，也就是真正的C51发命令，不让它处理原文件了，而是处理我们复制后的文件。然后把KC51的结果返回给前台。说白了，就是在IDE前台和C51的通信之间进行“传话”，在传话的过程中，我们作手脚。 下边就说怎么作手脚了。前文已经说了，我们的中文标识符必须按照“nameof(“变量名字符串”)”的格式。我们复制的时候，把所有出现这样格式的内容都替换掉。“nameof”还保留不变。“(“变量名字符串”)”都变成对应GB码的十六进制字符。这样，标识符就符合规范了，即，由字母数字和下划线组成，并且由字母或下划线开始。例如：“nameof("示例变量")”替换后就是“nameof2822CABEC0FDB1E4C1BF2229”。当然长度上肯定是增加了。所以不要超过规范规定的字数限制哦。 VC51对C51返回的结果也作了一些处理。因为返回结果中会包含（不是每次都包含）我们复制后的路径。而IDE前台会根据路径来查找对应的文件。比如我们的文件语法有误，如果不对结果进行处理，我们在编辑环境中，双击错误信息，出来的就是复制后的文件，而不是原文件。所以我们把结果中出现的路径还还原为原路径，IDE前台就以为是原文件了。 补充说明。 本软件完全开源，用户可自行修改和使用。但由此可能引发的版权纠纷或其他后果，均由用户自负。因此建议仅供学习与交流使用，请勿用于商业用途。 上面我们说到编译任何一个文件时，都会复制全部的C文件和H文件。其实还有一步详细的处理。原文件进行替换完毕，VC51会把替换结果与已经存在的文件作比较。若长度和CRC校验都符合，就不再写文件；否则才会写。这样能有效减少写的次数。 工程中文件的结构，需要符合这样的格式，所有C文件和H文件都需要位于工程文件所在目录和子目录中。如果不在这范围内，则不能出现中文标识符。 我发现的不完善的地方，真正的C51工具，在某个文件修改后，如果选择“build target”，KEIL只会对修改过的文件进行编译，不编译没修改过的。但在VC51下，KEIL对修改过的文件也“视而不见”。我猜测可能的原因是，C51编译后会产生一些存储相关信息的文件，而这些文件中的路径是我们作过手脚的路径，因此对原路径修改的文件不能正确识别。这一点也请大家共同研究探讨。 可增加的功能。VC51返回的结果中，与中文标识符相关的内容，显示的会是我们替换后的形式。而这个形式是可再“翻译”回来的。目前没加这个功能，但理论上是可实现的。而且我想，就算没这功能，影响也不大。如果哪位愿意加上，我也是举双手双脚来赞成的。 理论上，可用类似的方法，实现在MDK中使用中文标识符。我的直觉告诉我，那个叫“armcc.exe”的文件，就是编译器了。 这工具是我利用业余时间所编，时间仓促，而且我对VC也不是太熟悉。软件中存在漏洞或待完善之处的可能还是蛮大的。代码中注释也不多，几乎没有。这个习惯可不好，不是程序员应有的。实在是时间不允许，请大家见谅。欢迎大家共同交流，使VC51有更好的改善，或是能编写出更好的工具来。我的联系方式写在最后了。 我的联系方式： 邮箱：sdkdwj@163.com，或QQ邮箱。 QQ：342581660（当前昵称：基督徒）。