LabVIEW 的 unicode 问题

以前从来没有意识到过这个问题，直到最近，我试图去查看自己很久之前写的一些VI的时候才开始注意到它的。

先简略的介绍一下unicode的背景：

计算机是在美国被发明的，所以很自然的最开始只考虑了处理英文。早期最著名的关于如何在计算机中表达字符的标准是ASCII标准（American Standard Code for Information Interchange，美国信息互换标准代码）。它定义了128个字符，包括英文字母大小写，数字，常用的标点和一些特殊符号。当时世界上所有的计算机都用同样的 ASCII 方案来保存英文文字。这个方案最大的问题是只包含了英文字母，于是其它国家，组织和公司纷纷开始扩展这个标准用以支持其它字符，比如制表符、数学运算符号、中文字、日文字等等。比如在中国最常用的标准 GB2312，GBK，GB18030 等都是对 ASCII 的中文扩展。之后扩展出的这些标准有个很大的问题，就是同一个数值在不同的标准中被定义了不同的含义。某一数值在中文的标准下可能是一个中文字符，放到韩国的系统的某标准下，可能就是一个完全不相关的制表符。这就造成了，在中文环境下开发的软件，运行到韩国系统下显示的就完全是乱码。如果有人需要在一个系统下同时运行一个中国软件和一个韩国软件，恐怕就不行了。

为了解决这个问题，1990年开始，计算机业界开始研发一种编码标准，它可以覆盖全世界所有的字符，这样任何一个字符都有自己独占的编码，这样就不会出现换个系统就乱码的问题了。这就是unicode，也叫万国码、单一码。unicode规定了字符集，但是这套字符集也还有多重不同的编码格式。Windows采用了UTF-16LE格式的unicode编码（UTF全称为 Unicode Transformation Format），使用16位的(双字节)数据表示一个字符。但是当前最流行的unicode编码格式却是 UTF-8，这是一种变长的编码方式，根据字符的常用程度，可能由1到6个字节来表示。目前大多数的unicode文档采用的都是 UTF-8 编码的。

目前，大多数的软件也都是基于unicode的了。但是LabVIEW始终没有支持unicode。虽然Windows很早就开始支持unicode了，但是为了兼容那些还没有支持unicode的软件，Windows系统保留了一个默认字符集的设置，对于非unicode的软件，Windows会使用默认的字符集来解释那些字符编码。国内使用的电脑几乎都设置了默认的字符集为中文字符集，所以，一个软件是不是支持unicode，对于绝大多数中国用户来说根本感觉不到什么差别。所以，我之前也从来没觉得LabVIEW不支持unicode有什么问题。

直到最近我才发现了问题。我家里有两台电脑，一台操作系统安装了英文的Windows，并且没有修改过默认的非unicode字符集；另一台操作系统是中文Deepin Linux。我在两台电脑上都安装了社区版的LabVIEW 2021。我想在两台电脑上查看一下自己十年前写的一些VI，这时才发现，如果VI的路径中包含中文，是无法在Windows上被LabVIEW打开的。不过，我主要使用的是Linux，在Linux上还可以打开大部分的VI。但很快我就又发现，如果那些VI中如果有我以前设置的中文的常量或注释，在Linux下是无法正确显示的。但是呢，我还可以再Linux下添加中文常量或注释。之后，又遇到了更严重的问题：以前那些项目中，如果有中文名的子VI，或是库中、类中有中文名的VI，就通通都打不开了。我开始还以为是不是10年过去了，LabVIEW系统有什么变化，但是没听说过啊。于是我开始怀疑是不是文字编码的问题，我把Windows的默认字符集换乘了中文，果然在Windows下一切正常了。而且我还发下，在Linux下，给VI添加的中文注释，拿到Windows下，看到的全是乱码。

总结我看到的现象，我深刻怀疑，目前LabVIEW在Windows下是不是用unicode的，字符编码由Windows系统决定，对于大部分中国用户来说，采用的是GB18030中文编码；但在Linux下却使用了UTF-8编码。

在Linux由于系统和LabVIEW采用的都是unicode，所以一个VI在不同Linux版本下应该行为都是一致的。但Windows系统用的是unicode，LabVIEW用的却不是。我们现在假设一个项目中有两个VI，本别是“界面.vi”和“任务1.vi”，其中“任务1.vi”是“界面.vi”的子VI。在操作系统层面，有两个文件：“界面.vi”和“任务1.vi”，它们的名字都是使用unicode保存的。但是在“任务1.vi”内部，它记录了自己要调用“任务1.vi”，却用的是非unicode编码保存的子VI的名字。所以LabVIEW中用于记录这个子VI的一段二进制数据与操作系统中记录这个子VI文件名使用的二进制数据是不同的。每次LabVIEW需要操作系统找到相应的VI文件时，还需要做一次编码转换，把文字转为系统认识的unicode编码。如果保存VI，和读取VI都是在中文Windows中，这没有问题，VI名字总能被正确转换。但是把之前在中文Windows系统下保存的项目拿到非中文Windows（默认语言编码不是中文）下打开，文件名编码转换这一步就会出错，LabVIEW就无法找到正确的VI了。同理，中文Windows下保存的VI，如果有中文名，拿到Linux下打开会出错；反过来也是一样会出错。

总之，由于LabVIEW在Windows下没有使用unicode，造成了中文显示在不同系统下的不一致行为，切换系统就会出现乱码，甚至VI无法被加载。目前没有什么好办法可以解决这个问题。我只好将来在LabVIEW中只使用英文，不是用中文了。

广告

重新制作了书籍网页

最近学习完了React，又使用Docusaurus重新为书籍制作了网页：https://lv.qizhen.xyz/

实际上，Docusaurus已经帮我作为绝大部分工作，我学习的React技能基本没有用上，毕竟书籍的格式还是比较简单固定的，不需要非常炫酷的界面。

之前是用Docsify制作的页面。我对于Docsify的界面和功能已经非常满意了，最主要的问题是它制作的网页是客户端渲染的，搜索引擎都不会爬取。墙外的搜索市场已经被Google垄断，恐怕Google是不会有动力去支持搜索客户端渲染页面了。国内的搜索市场竞争还更激烈一点，可以它们居然做的都比Google还差很多，也没有指望。只能自己修改网页了。

Docusaurus使用起来比Docsify麻烦不少，所需技术门槛也稍高。这一是因为Docsify只支持制作文档网页，而Docusaurus还可以制作个人主页和博客，功能复杂了不少，虽然都是我都用不上的。二是因为Docusaurus是制作服务端渲染页面的，多了一个Build步骤。再有Docusaurus比较新，资源相对来说少一些。

但不管怎么样，Docusaurus也是非常令人满意的。现在Google可以爬取我的页面了，国内的搜索引擎都还不行，但这不是网页的问题，最可能是我的域名没有工信部认证，国内引擎不愿意访问。

Docusaurus开发团队非常活跃，应用前景应当超过其它类似工具。非常推荐用于创建静态的个人主页、博客、文档等。

最近更新了书里的一些内容

https://lv.qizhen.xyz/

毕竟不是专业做LabVIEW编程了，写作速度也大为减缓。因为之前太久没维护了，近期我还是会尽可能多的做一些修改。长期的来说，希望保持每年可以更新一两章的内容。

将来会逐渐补充一些我比较了解的内容，比如：面向对象编程，泛型编程，数据结构，设计模式，网络编程，调用Python等。当然这些都是很长远计划了，不能期望太高。

试了一下LabVIEW2021社区版

只大致看了看前后面板。发现跟10年前差别不大，功能有所增加，但也没有太多，没有2000~2010那十年变化大。这也可以理解，编程语言的基础部分还是要稳定一些的。重大的功能添加可能主要会以插件的形式发布了。

也有可能NI过去10年精力主要都放在了LabVIEW NXG上面。看看下个十年会怎么样吧。