博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
关于windows系统里locale、code page、ANSI编码的问题
阅读量:6887 次
发布时间:2019-06-27

本文共 1096 字,大约阅读时间需要 3 分钟。

最近把公司代码库里的代码同步下来之后编译了下,竟然出问题。问下同事说代码库肯定没问题,而我啥也没改,那到底那里出问题了呢?

VS2018报的错误是:error RC2001: newline in constant

百度下这个错误的原因,主要原因是定义的字符串常量两个引号之间有换行,跳到相应出错的代码位置处,大体可以解决这个编译错误。当然,这个问题只是表象。由于代码库里的代码编译肯定能通过,而且这些代码已经跑了很久了,不可能存在这么低级的编译问题。

那么问题出在哪呢?

答案是操作系统的设置。问题源自于windows本身的一个历史包袱吧,我大体简述下,自己对这个问题本身研究也不透彻,所以有问题请谅解:大体就是windows在支持国际化的道路上是推荐使用unicode的,毕竟一个编码标准就能支持这个世界上所有语言的所有文字,也就不存在乱码之类的问题了。但是windows也是半路才支持unicode的,在这之前一直是使用locale+ANSI编码标准的。这个是个什么玩意儿呢?大体就是可以通过控制面板里的一个选项来设置系统的locale,而系统会根据你的locale来选择在ANSI编码(严格说这个不能叫编码!!)模式下(相对于unicode而言,也就是文本编辑器如notepad++、VS的编辑器等检测到当前的文本文件的编码不是unicode)所使用的编码。比如如果locale是Chinese PRC,则此时ANSI编码为gb2312(或者gbk,反正是gb系的),而如果locale是English US的话,则ANSI编码对应扩展的ascii(貌似,没有求证)。说实话ANSI这个叫法着实蛋疼,很让人费解,因为ANSI本身是个标准委员会,不明就里的人根本不知道是说啥么。

回到刚刚的编译问题,由于这些代码通常实在locale为English US的情况下编译的,而代码文件本身不是unicode编码,所以就应该是使用扩展ascii来进行编码/解码。但由于我的locale是Chinese PRC,所以对于非unicode编码的文件系统是使用gb2312来解析的。嗯嗯,问题来了,文件的编码和解码所使用的标准不兼容,导致各种诡异问题。

这里想吐槽下微软在处理这种问题下遗留下的种种尾巴,不过咋说呢,问题本身太复杂,解决不好也不怪这样臃肿的大公司,谁还没有点顽疾呢。

关于编码的问题知乎上有讨论:

可以参考下,可能讲的比我清楚。

另外,关于locale对应的ANSI编码,微软是叫code page的。locale与code page的对应可以参见:

没时间了解太多,有问题请谅解。

转载地址:http://dhtbl.baihongyu.com/

你可能感兴趣的文章
[应用模板]移动应用界面
查看>>
嵌入式Linux C编程 02
查看>>
sql server支持连接管理功能
查看>>
java的强制类型转换想到的
查看>>
简要介绍cookie与session的区别与联系
查看>>
mysql flush用法
查看>>
response.setHeader()的用法
查看>>
一位前辈的经验,给正在思考的自己
查看>>
分享一篇关于lucene原理的文章
查看>>
基于 HTML5 结合互联网+ 的 3D 隧道
查看>>
Win10下 80端口被system(pid=4)占用的解决方法
查看>>
使用SubVersion+TortoiseSVN多仓库方式进行版本控制
查看>>
Nginx虚拟目录alias和root目录
查看>>
MySQL(Extends)
查看>>
Android KeyboardView实现App内置键盘开发
查看>>
Python文件夹复制
查看>>
细谈 vue 核心- vdom 篇
查看>>
ajax+springmvc实现跨域请求
查看>>
SaltStack快速入门-配置管理
查看>>
批处理研究(QQ绿化和卸载)
查看>>