Windows 下的 UTF-8 编码问题 - 续二
第二坑很快就踩到了, 这次是 Windows 文件系统的路径编码问题. 在启用 UTF-8 默认支持后, 系统里已经安装的软件如果没有强制硬编码了使用某一种编码, 那么这些软件里曾经在 GBK 环境下引用的路径也会一律会以 UTF-8 编码读取. 于是这些原本是 GBK 编码存储的路径变量或者配置文件无一例外全都 UTF-8 解码后变成了乱码(比如我正在使用的 FS Capture 和 eDiary).
特别是 Windows 中的库目录, 会随着语言区域的切换变换命名语言, 所以中文语言设置下的库目录都是非 ASCII 字符(中文). 然而大多数的软件又都喜欢用这几个默认的库目录(比如文档, 音乐, 图片等等).
这次的结论是: 最好在 Windows 初始化好, 还没有开始安装配置其他软件的时候就启用默认 UTF-8 编码支持. 否则在系统和其他软件配置完成后再切换编码, 很容易导致这样的路径编码问题.
#Windows
via CXPLAY's Memos
第二坑很快就踩到了, 这次是 Windows 文件系统的路径编码问题. 在启用 UTF-8 默认支持后, 系统里已经安装的软件如果没有强制硬编码了使用某一种编码, 那么这些软件里曾经在 GBK 环境下引用的路径也会一律会以 UTF-8 编码读取. 于是这些原本是 GBK 编码存储的路径变量或者配置文件无一例外全都 UTF-8 解码后变成了乱码(比如我正在使用的 FS Capture 和 eDiary).
特别是 Windows 中的库目录, 会随着语言区域的切换变换命名语言, 所以中文语言设置下的库目录都是非 ASCII 字符(中文). 然而大多数的软件又都喜欢用这几个默认的库目录(比如文档, 音乐, 图片等等).
这次的结论是: 最好在 Windows 初始化好, 还没有开始安装配置其他软件的时候就启用默认 UTF-8 编码支持. 否则在系统和其他软件配置完成后再切换编码, 很容易导致这样的路径编码问题.
#Windows
via CXPLAY's Memos
