100分－－软件国际化－－ 一些关于国际化的问题和思考

Question

请教大家一个关于VC国际化的问题（长期讨论）：
1 当用户输入时，是否项目是通过UNICODE编译的就可以支持各个国家不同的输入法，也就是editbox等可以正确的接受和显示，不同语言不同输入法的输入；2 接受来自外部程序的数据，如果不UNICODE的是否一定要转换乘UNICODE
再显示到界面；3 一个lable控件的长度可以接纳2个字符，不同的国家可能文字长度不同
比如说 English 和 英文 一个是7个字符的长度 一个是2个字符的长度，
如果动态的解决界面上这些控件的长度问题：
   A 我想了个方案就是把控件的长度也保存在资源文件中，根据资源文件该控件
的长度动态的生成界面上控件的长度；
         B 为不同的语言画不同的界面，设置不同的长度；
       大家认为哪个方法更好一些或者还有别的好方法。4 打开保存文件的路径，控制台命令行。这2个问题也挺头疼，是否项目使用UNICODE
编译的就会自动的显示正确的路径不出现非法字符的乱码：还有就是如果控制台对方输入比如说   CMD  openfl 文件名字.txt  这个openfl命令是我们自己开发的是否在控制台可以接受非英文的输入呢。  
  
5 即便是UNICODE对方要是没有响应的字符集也是不能正常显示的吧？有没有解决办法呢？  
  
6 是否要考虑utf－8节约控件？7 最关键的工作，关于软件的国际化，其实专门做出来一个DLL文件，让他负责读取资源文件然后显示到界面上，同时界面上的所有控件都是支持UNICODE的就可以。我的理解是否正确？

Answer 1

顺便问一下 vc 使用_UNICODE,UNICOED编译以后是的应用程序是那种unicode是uft-8 还是uft－16等的哪一个？
或者是支持uft－8    vc和vb一样么在unicode方面

Answer 2

没有人知道微软默认的UNICODE的格式？？？

Answer 3

如果是uft-16那我们的vc程序 editbox得到的字符串保存为文本不就是uft-16的了 显然不是啊

Answer 4

其实我觉得做好语言就可以了。UNICODE嘛，可以做，也可以不做。

Answer 5

UNICODE你理解的太简单了。
1 当用户输入时，是否项目是通过UNICODE编译的就可以支持各个国家不同的输入法，也就是editbox等可以正确的接受和显示，不同语言不同输入法的输入；
  〉〉〉这个是不可能的。2 接受来自外部程序的数据，如果不UNICODE的是否一定要转换乘UNICODE
再显示到界面；
  〉〉〉如果你的程序定是UNICODE的，就必须这样3 一个lable控件的长度可以接纳2个字符，不同的国家可能文字长度不同
比如说 English 和 英文 一个是7个字符的长度 一个是2个字符的长度，
如果动态的解决界面上这些控件的长度问题：
   A 我想了个方案就是把控件的长度也保存在资源文件中，根据资源文件该控件
的长度动态的生成界面上控件的长度；
   B 为不同的语言画不同的界面，设置不同的长度；
大家认为哪个方法更好一些或者还有别的好方法。
〉〉〉A4 打开保存文件的路径，控制台命令行。这2个问题也挺头疼，是否项目使用UNICODE
编译的就会自动的显示正确的路径不出现非法字符的乱码：还有就是如果控制台对方输入比如说   CMD  openfl 文件名字.txt  这个openfl命令是我们自己开发的是否在控制台可以接受非英文的输入呢。  
  
5 即便是UNICODE对方要是没有响应的字符集也是不能正常显示的吧？有没有解决办法呢？
〉〉〉是的。
     解决办法，就是对那种语言单独做一个版本。  
  
6 是否要考虑utf－8节约控件？7 最关键的工作，关于软件的国际化，其实专门做出来一个DLL文件，让他负责读取资源文件然后显示到界面上，同时界面上的所有控件都是支持UNICODE的就可以。我的理解是否正确？
〉〉〉这样可以以上都是我个人的理解，不一定正确。仅供参考。

Answer 6

系统其实使用的是UNICODE
只不过由于书上说的原因(忘了)系统会转成别的编码的如果你是简中那就是GB来让你用,系统内部使用的是unicode(98以后的系统,98不支持unicode),
具体的你可以看看 windows核心编程
上面介绍的挺多,好像是第二章