不允许修改windows的语言环境,不知道有没有人碰到同样的问题,是如何解决的?

解决方案 »

  1.   

    靠, 不让修改windows环境啊!
    你的asp.net的aspx页面保存为ascii,uft-8,和gb2312都试一遍,估计是aspx的编码类型和com输出的编码类型不一枝造成的,不知道com的输出类型是什么,估计是ascii。
      

  2.   

    你说方法没用哎...我再等等~~~  看有没有什么好的方法其实在英文环境下你写gb2312它保存的就已经是乱码了,除非用unicode保存,要么它根本不认识什么gb2312,就把它当做非unicode来处理,而我们那几台服务器上的非unicode处理方式是用英语(美国)的.更要命的是,这个设置是不可以改的!保存成asc,我不会哎 - -!  高级保存里根本没那个选项~~~ 
      

  3.   

    该死的CSDN,想发的贴刷新N遍再行我想这个和文件编码是没有关系的,因为unicode已经是大字符集了,这都取不出来,你改成小的字符集是没有用的,而且这台机器上用unicode存的文件里有中文是可以显示的,而存成其它格式,里面原有的中文都不正常了,所以文件本身就应该存成unicode的...而且,客户端是通过IE访问的,这个和你本身的文件格式根本就没有什么关系,即使在服务端的文件是一团乱码,客户端IE看到的一样是正常的内容~~~所以问题的根本就是在取出来的内容的编码该如何转换,我可以说这介我们研发部人的问题,他们开发的com根本没有考虑全球化的问题,如果他们返回的char那么根本就不用这么麻烦的转码,貌似他们写的com返回的都是bstr,不过理论上来说C++里的bstr就是用unicode编码,所以我怀疑他们返回的就是string~~~,那么OS在读取时就用默认编码来读取.不过,在这台机器上用asp来读com完全正常,难道com的运行还和应用环境有关,真是太奇怪了!我的项目完了,不过我用的是牺牲性能的方法.在别的服务器上做了一个windows服务,主要用socket,然后在这个web程序上用线程来取,放到内存里,然后再WEB程序直接读内存,这样是没有问题的.这个系统对性能要求相当高,我不想用这么别扭的方法来解决,我会继续找方法来解决.   这个贴子先结了,找到我会发消息给大家..