C++ 源码改用 UTF8 编码 about paddleocr-json HOT 7 CLOSED

utf-8 with bom 早该进历史垃圾堆了。。。不存在 windows 兼容性不好。vscode, clion, qtcreator 全都默认是 utf-8 no bom，早就是事实上的标准了

from paddleocr-json.

其实本项目v1.1及以前的工程文件是UTF8编码的，会产生一个神奇bug：使用vs2019编译时，以中文结尾的注释有几率吞掉后一个换行符，导致下一行代码也被注释。这种现象只在编译时发生，写的时候vs编辑器并不会提示异常，导致难以发现。

每一个中文注释的句尾加多一个空格可避免此问题。不过为了防止某一天漏加空格导致玄学异常，我还是决定用回默认编码算了。当然，不用中文注释也能一劳永逸解决，只是我个人不习惯。

移植Linux的话，本项目为了兼容windows的不同语言区域，使用了很多win平台的API来处理文件路径。剪贴板相关的代码应该也是win api。移植Linux可能要重写 tools.cpp 中的大部分函数。

from paddleocr-json.

这种问题我遇到过，加上编译选项 /utf-8，见 https://learn.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=msvc-160
一个汉字 UTF8 编码是3个字节，GBK 编码是2个字节。当恰好是奇数个汉字时，编译器当作 GBK 处理，这时就会吃掉后面一个换行符。

from paddleocr-json.

windows 下为了处理国际化不同语言编码问题，一般外部打印输出统一用 wstring （所谓的宽字符，UTF-16编码），内部可以统一用 UTF-8。

from paddleocr-json.

一般外部打印输出统一用 wstring （所谓的宽字符，UTF-16编码），内部可以统一用 UTF-8

现在是内部 wstring 和 string 混用，因为兼容多语言区域的win api一般都是用宽字符参数，但json解析器的nlohmann库使用 u8 string ，只好互相转换。

至于输出，因为某些Paddle和Opencv链接库的内部有日志输出，改不了那部分代码。考虑到 wcout 和 cout 混用可能出现问题，就全部cout了。

加上编译选项 /utf-8

好建议，有空试试。还有个问题请教一下，应该保存为 utf-8 with bom 还是 no bom 呢， with bom 可能Linux兼容性不太好，no bom则win兼容性不太好？

from paddleocr-json.

能问一下这里面的模型是你自己训练的吗，还是从 PaddleOCR 官网下载的？

from paddleocr-json.

模型都是官方的，这里

from paddleocr-json.