使用Visual Studio 2017(VS2017)编译OpenCC 1.0.4 (Open Chinese Convert)源代码-进城务工人员小梅

摘要：本文介绍了Win7 64位环境下OpenCC(Open Chinese Convert) 1.0.4源码编译全过程，除VS2017外，VS2013以上版本也应该基本同样适用，其他版本的Windows操作系统也应该适用。本文除了完成基本的编译过程外，还指出并解决了目前在开放网络上有关OpenCC 1.0.4在Windows环境编译的过程中没有被解决过的两个问题（在Github和搜索引擎上均没有答案）。
一、VS的版本关系
VC10，对应VS2010
VC11，对应VS2012
VC12，对应VS2013（OpenCC要求VS2013以上版本）
VC14，对应VS2015
VC15，对应VS2017（CMAKE直接生成的此版本解决方案在编译时存在未解决的BUG，后详）
二、为什么要从源码编译
1、OpenCC默认没有发布Windows平台下的二进制文件；
2、需要进行源码级别的修改；
三、OpenCC介绍
      OpenCC (Open Chinese Convert，开放中文转换) 是一个用于中文简繁转换的开源项目，支持词汇级别的转换、异体字转换和地区习惯用词转换（中国大陆、台湾、香港），其官网位于Github中：https://github.com/BYVoid/OpenCC。
      OpenCC严格区分「一简对多繁」和「一简对多异」，完全兼容异体字，支持中国大陆、台湾、香港异体字和地区习惯用词转换，词库和函数库完全分离，支持C、C++、Python、PHP、Java、Ruby、Node.js和Android，兼容Windows、Linux、Mac平台。
      在Github的Wiki中，有对OpenCC的详细介绍和与cconv的对比，对于现代汉语常用简繁一对多字义、地名等也进行了支持，从介绍上看应该是一个较优秀的解决方案。
四、在Windows平台下使用CMAKE和Visual Studio编译OpenCC
      OpenCC是使用C++编写的，编译是需要用到CMAKE和Windows Visual Studio（2013或更高版本），有关CMAKE的安装可以参见本站的文章《Win7 64位环境下OpenCV 3.3.0源码编译及VS2010（VS10）下开发》中的相关内容，在此不再赘述，本文使用的CMAKE 3.9.2和Visual Studio版本分别是：

编译OpenCC 1.0.4使用的CAMKE版本

和

编译OpenCC 1.0.4使用的VisualStudio版本

CMAKE安装安装好后，使用如下的命令生成VisualStudio解决方案文件并进行编译（32位）：

cmake -H. -Bbuild -G“Visual Studio 15” -DCMAKE_INSTALL_PREFIX=”path/to/install”
cmake –build build –config Release –target install

请注意，需要根据本地安装的具体Visual Studio版本选择合理的”Visual Studio *”，其中：
VC10，对应VS2010
VC11，对应VS2012
VC12，对应VS2013
VC14，对应VS2015
VC15，对应VS2017（请注意，直接使用”Visual Studio 15″生成的解决方案编译不了，怀疑是VS的BUG，详见问题②）。如果选择了不恰当的版本会报找不到相应版本的工具链，可以通过Visual Studio Installer进行安装（后详）。

请注意，在某些机器上，上述命令如果直接从CMD中直接运行，可能会报如下的错误：

直接使用CMD运行CMAKE时的报错

Failed to run MSBuild command:

MSBuild.exe

to get the value of VCTargetsPath:
Configuring incomplete, errors occurred!

此时，需要从Visual Studio Developer’s console（开发人员命令提示符）：

使用VS开发人员命令提示符编译OpenCC

中运行上述命令：

在VS开发人员命令提示符中编译OpenCC1.0.4

编译完成后，生成的VS工程文件等会被输出到builid目录中：

在VS开发人员命令提示符中编译OpenCC1.0.4结果

然后打开builid目录中的.sln解决方案文件即可：

CMAKE生成OpenCC1.0.4的VisualStudio解决方案文件

在VS中打开解决方案后，默认的启动项目是ALL_BUILD，直接在菜单中点击“生成-重新生成解决方案”重新生成解决方案即可。请注意，OpenCC 1.0.4版本CMAKE生成的VS2017（Visual Studio 15）解决方案文件在直接编译时会有两类错误：
①PhraseExtract.cpp文件编码问题
opencc_phrase_extract项目和libopencc项目无法编译，这两个项目中的PhraseExtract.cpp文件（路径分别位于src/PhraseExtract.cpp和src/tools/PhraseExtract.cpp）由于编码问题会报错：

警告 C4819 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失
错误 C3688 文本后缀“銆”无效；未找到文文本运算符或文本运算符模板“operator “”””銆”
错误 C3688 文本后缀“锛”无效；未找到文文本运算符或文本运算符模板“operator “”””锛”
错误 C3688 文本后缀“鈥”无效；未找到文文本运算符或文本运算符模板“operator “”””鈥”
错误 C2001 常量中有换行符

如下图所示：

默认生成的VS2017解决方案编译时报错

此时，可以通过“文件-高级保存选项”将PhraseExtract.cpp文件的编码从默认的“简体中文(GB2312-代码页936)”和“Uncode(UTF-8无签名)-代码页65001”修改为“Unicode-代码页1200”解决（如果找不到“高级保存选项”请参见《解决Visual Studio 2017(VS2017)中找不到/没有“高级保存选项”的问题》）：

修改OpenCC 1.0.4中PhraseExtract.cpp文件的编码以解决编译错误

在网上，有一篇在搜索引擎中排名非常靠前的文章《使用OPENCC库进行简繁转换（C++代码）》中提到：

此处1.0.4版本中项目：opencc_phrase_extract 是无法编译的，在GIT上也有对应的issue，删除该项目即可，不影响使用，所以不用管他。

如下图所示：

处理PhraseExtract.cpp文件编码问题导致编译失败的错误方式

这实际上是一种错误的鸵鸟做法，事实上完全可以通过本文所述修改文件编码的方式解决该问题。在本文的最后，我们也可以看到在tools文件夹中生成了opencc_phrase_extract.exe.exe。
②setjmp莫名其妙的诡异BUG
除了编码问题外，还有几个关于longjmp和setjmp的诡异BUG，这两个函数用于在C语言中进行异常处理：

错误 C3829 标准属性 “noreturn” 只可适用于函数 libopencc d:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\include\setjmp.h 165
错误 C2206 “longjmp”: typedef 不能用于函数定义 libopencc d:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\include\setjmp.h 165
错误 C2039 “longjmp”: 不是“`global namespace’”的成员 libopencc d:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\include\csetjmp 10
错误 C2873 “longjmp”: 符号不能用在 using 声明中 libopencc d:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\include\csetjmp 10

如下图所示：

使用VS2017编译OpenCC1.0.4源码时的诡异错误

上述几个报错的位置位于形如：

d:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\include\setjmp.h(165)

的头文件中，该头文件是VS自带的头文件。有关上述四个报错在所有的搜索引擎中均搜不到答案，我将该问题提到了OpenCC所在GitHub的Issue#287中，看后续是否有人解决。
直觉上，感觉可能是由于VS2017的问题，因此尝试使用了”Visual Studio 14″降级到VS2015编译，结果成功：