企业官网建设流程全解析

简介：经典WinCC画面文本显示问号或乱码，是项目从一台电脑复制到另一台、或从低版本升级到高版本时常遇到的现象，原因多为组态语言选择错误或运行语言不一致。针对这类问题，一份docx格式的排错文档面向西门子WinCC组态工程师与现场维护人员，以对象属性中的"组态语言"为切入点，说明如何通过属性列表确认当前语言、双击查看支持语言列表，并在图像编辑器"视图→语言"对话框中切换为与项目匹配的组态语言；若运行时仍异常，则需进一步检查项目全局设置中的运行语言，同时留意操作系统与WinCC的兼容性以及字体文件是否完整。资源包为docx格式的文档，大小244KB，共1个文件，内容精炼、按排查顺序组织，适合在项目迁移前或出现显示异常时对照操作。已有1766人学习下载，可帮助读者快速定位并解决经典WinCC文本问号乱码问题，避免在复制或升级项目后反复调试语言设置。

1. WinCC画面文本显示成问号：问题不在字库，在于"语言开关"没对齐

在 WinCC 里，画面文本显示成问号，是组态和现场运维里最容易被误判的问题之一：明明编辑器里中文显示得好好的，一运行就变成"？？"，重开画面没用，重新录入一遍也没用。十有八九不是机器缺字库，而是项目语言、运行系统语言、字体这三处的设置互相没对上。WinCC 的文本机制是按"语言版本"存储和读取的，同一个文本对象在不同运行语言下会去取不同语言的字符串；取不到、或字体映射不到中文字形，界面就统一渲染成问号。这篇文章按排查顺序把机理、设置步骤、批量导入导出的坑和现场处置经验一次讲透，适合正在做 WinCC 画面组态、或者在现场被问号困扰的工程师照着操作。

2. 问号产生的三层机理：字符存储、运行语言与字体映射

2.1 问号不是缺字，是"找到了字但拿错了"

很多人第一反应是补装中文字体，其实在 WinCC 里，问号大多是"按错误的方式解读了正确的字符"。WinCC 的画面文本对象并不是简单地存一个字符串，而是按语言版本存了一组字符串，并带一个语言标识。运行时，控件根据当前运行系统语言去取对应语言的字符串；取不到时有两种表现：一种是降级显示源语言文本，另一种是按当前语言代码页把字节直接映射到字体，映射不到就渲染成问号。绝大多数问号属于后一种。

这里牵涉到 Windows 的代码页机制。简体中文环境用的是 GBK（代码页 936），英语环境用的是 Windows-1252。如果项目源语言是英语，而中文文本被敲在了英语语言条目下，运行时按英语代码页去解读中文字节，字符根本不在表里，控件只能画出问号。这种情况在经典 WinCC 里非常常见：新建项目默认源语言是英语，工程师图省事没改语言设置，直接在画面里输入中文，等于把中文存到了英语条目下。

还有一种情况是字体本身缺中文字形。WinCC 默认字体依赖语言包，早期经典版本在没有安装中文语言包时，字体映射表里没有中文字形，即使文本读取正确也渲染不出来。所以排查顺序应该是：先确认文本归属语言，再确认运行系统语言，最后看字体。

2.2 三处语言设置：你的项目到底在说哪种语言

我一般把 WinCC 的语言体系看成三组开关，每一组都能让文本显示问号。把它们单独列出来，排查时就清楚了。

项目语言和运行系统语言的关系，我习惯用一个比喻：项目语言是"仓库里有哪些货"，运行系统语言是"今天门店按什么价签拿货"。仓库里只有英语条目，门店却按中文拿货，拿不到就画问号。反过来，仓库里有中文条目，门店却按英语拿货，也拿不到。源语言则是"默认兜底"：当运行语言取不到对应条目时，有些控件会降级显示源语言文本，但如果源语言本身是英语而文本内容是中文，兜底也兜不住。

实际操作中，三处设置不一致的案例占了问号问题的八成。尤其是"客户端访问"场景：服务器上运行正常，瘦客户端或远程桌面打开画面全是问号，第一反应查服务器，其实客户端操作系统的区域语言没有中文语言包，WinCC 运行时在客户端上找不到中文字体，问题根本不在项目里。

2.3 先做判断题：静态文本和动态文本的排查思路完全不同

碰到问号，我不建议立刻改设置，先分清楚是静态文本还是动态文本。静态文本是指直接在画面对象里输入的文字，比如按钮上的"启动"、标题栏的"工艺流程"；动态文本是指运行时从变量、数据库、报警系统里取出来的内容，比如来自变量连接的值、报警控件的消息文本。这两类的排查方向差异很大。

静态文本问号，几乎都是语言设置和字体问题，按第 3 章的步骤处理即可。动态文本问号，要分两截看：内容是不是 WinCC 自己存的，还是外部系统传进来的。如果是外部数据（比如从其它系统读过来的值）显示成问号，根源往往在数据源的编码，不在 WinCC 画面；WinCC 只是忠实地把字节渲染出来。报警控件的文本则特殊一些，它在报警记录组件里有独立的语言条目，即使项目语言设置正确，报警文本没有同步编译语言版本，运行时照样问号。

一个实用的判断动作：把疑问号的那条文本复制出来，在图形编辑器里用它新建一个独立文本对象，再运行看一次。如果新对象显示正常，说明字体和项目语言没问题，是原对象的语言归属或报警组件里的语言条目问题；如果新对象也问号，那就是全局设置了，直接进入第 3 章。

3. 先把项目语言和运行系统语言对齐：正确设置步骤与参数说明

3.1 第一步：在项目语言里把中文打开，并设为源语言

在 WinCC Explorer 左侧树形结构里，选中项目根节点，右键打开"属性"，切到"语言"选项卡。这里能看到当前项目启用的语言列表，以及一个"源语言"下拉框。经典 WinCC 默认只有"英语"，勾选"中文（简体）"之后，从下拉框里把源语言也切到中文。

把中文设为源语言这一步非常关键，很多教程只教勾选，不教改源语言。源语言决定了新建文本对象时，默认归属到哪个语言版本。如果源语言保持英语，新建对象后输入的中文会进英语条目，运行时按中文取不到；反过来，源语言设为中文后，新建对象的中文文本进中文条目，运行时按中文取，稳。有一点要提醒：改源语言只影响"新建"的文本对象，已经录入的文本不会自动迁移。存量文本如果已经错位，需要用文本库导出再导入的方式批量修正，具体操作见第 4 章。

参数说明：项目语言列表里勾选的语言越多，运行时需要维护的文本版本就越多；一般项目只保留中文和英语两种。中文是源语言还是英语是源语言，取决于主用语言。如果现场操作员只用中文，就选中文为源语言，减少英文条目的维护量。

3.2 第二步：运行系统语言跟着同步，别"全选"

项目语言设置好之后，打开"计算机"节点，双击要运行的计算机名，在"计算机属性"对话框里找到"运行系统语言"选项卡。经典 WinCC 这里一般会列出与项目语言对应的运行系统语言选项，把"中文（简体）"勾上，同时看有没有"启动时运行系统语言"或"默认运行系统语言"的选项，把默认值设成中文。

这里有个常见做法值得说破：我看到不少工程师图省事，把运行系统语言列表里的语言全部勾上。表面上是"以后要换语言方便"，实际上是埋雷——运行时会按列表逐个尝试加载语言资源，语言版本越多，启动越慢；一旦运行时不小心切到某个没有对应项目语言条目的语言，整个画面文本瞬间全变成问号。我一般只勾实际需要的语言。如果确实有中英文切换需求，就勾中英文两种，并在项目属性里保证这两种语言都有对应的文本条目。

运行系统语言和项目语言要一一对应。项目语言是中文，运行系统语言就必须包含中文；两者不对齐时，运行时按运行系统语言去取文本，项目语言列表里根本没有这个语言版本，取不到，问号就出现了。这个现象在"项目从一台机器拷到另一台机器"时尤为典型：项目语言列表是中文，目标机器上 WinCC 的默认运行系统语言配置却是英语。

3.3 第三步：字体映射，别让字符被"画"不出来

语言设置对齐后，如果还有问号，剩下的问题基本在字体。在图形编辑器里，选中画面上的文本对象，在对象属性窗口中找到"字体"相关的属性。经典 WinCC 里，文本对象默认字体可能是 "WinCC Standard" 或者"Arial"，这两种字体都不包含中文字形。把字体改成"宋体"或"SimSun"，中文就能正常显示。

操作上有个批量技巧：在图形编辑器里按 Ctrl+A 选中整个画面的所有对象，在属性窗口里统一设置字体、字号。需要注意，这会把按钮、输入域等对象的字体也一起改了，一般没有副作用，但画面里如果有特殊符号字体（比如箭头、流程符号），统一替换后可能变形。安全做法是先选中所有文本类对象，再改字体。WinCC"查找/替换"功能也可以按对象类型过滤，比直接全选更可控。

字体设置有一个容易被忽略的点：同一个画面在开发电脑上正常，部署到现场工控机后问号。原因是开发电脑装了 Office 或其它软件附带的中文字体，现场工控机是精简系统，只有默认字体。这种问题要提前在现场确认字体是否存在，不要想当然认为宋体一定在。远程客户端问号的原因也是一样的，客户端系统必须装中文字体。

4. 文本库批量导入导出时的编码与分隔符坑

4.1 文本库导出的真实格式：Tab 分隔的 TXT，不是 CSV

WinCC 的文本库导出文件不是 Excel 的 CSV 格式，字段之间用的是 Tab 分隔符，文件后缀一般是 .txt。用 Excel 直接打开这种文件，每列会落在不同的单元格里，看起来和表格一样，于是很多人顺手把它另存为了 .csv 文件——这是一个非常典型的翻车现场。WinCC 在导入时按 Tab 分隔解析每一行，遇到逗号分隔的内容，整个文件会被解析成错位结构：语言标识读到文本内容列，文本 ID 读到语言列，量大的时候导入直接失败，量小的时候静默导入，结果文本库里全部是乱码和问号。

正确做法是：在 WinCC Explorer 里对项目执行"文本导入/导出"（不同版本菜单名略有差异，有的叫"导出文本库"，有的在"多语言"菜单下），选择导出，得到一个 Tab 分隔的 TXT 文件。用 Excel 打开编辑后，另存时选择"文本文件（制表符分隔）"，而不是 CSV。后缀名保持 .txt，不要手动改成别的扩展名。

还有一个经常被忽略的细节：Excel 打开文本库文件时，文本 ID 列如果是一长串数字，会被自动转成科学计数法，另存回去后 ID 变了，导入时和原文本匹配不上，表现为部分文本内容被替换成问号或空。防止办法是：在 Excel 打开后，先把 ID 列选中，设置单元格格式为"文本"，再开始编辑。

4.2 批量翻译的正确流程：编码和分隔符一起查

我处理批量翻译的标准流程是这样的：

先导出原始文本库，得到一份干净的基线文件；用 Excel 打开，只修改目标语言列，不碰语言标识列和文本 ID 列；另存为"文本文件（制表符分隔）"后，不要直接导入——先打开 Notepad++ 看编码。

如果文件右下角显示"UTF-8"且没有 BOM，先另存为"UTF-8 with BOM"或"ANSI"。经典 WinCC 对编码的判断依赖文件头标记，UTF-8 无 BOM 的文件头没有识别标记，导入时默认按系统 ANSI 代码页解析，中文字节被按 GBK 读出来，一部分字符就会变成问号。简体中文环境下最稳妥的是存成 ANSI（即 GBK），这与 WinCC 内部存储一致，导入后中文显示最干净。

导入之前一定要备份原文本库。做法很简单：把导出的基线文件复制一份到别的目录，或者把当前文本库用菜单导出一份留底。文本库一旦被错误导入污染，WinCC 里所有相关文本全部变成问号，没有备份就只能手工重录，那个工作量足够让人崩溃。

4.3 编码自查表：导入前花 30 秒避免一次事故

导出的文本文件在导入前，用 Notepad++ 打开右下角看编码，和下面的表对照判断：

如果 Notepad++ 里显示"ANSI as UTF-8"这类提示，说明文件本身是 ANSI 编码但被尝试按 UTF-8 解读过，需要另存为纯 ANSI 再导入。另外，导入后不要只抽查第一条文本，需要切换运行系统语言验证一次，因为编码问题往往只在非默认语言下出现。

5. 画面文本问号排查实录：现象、根因与解决

5.1 项目语言列表里没有中文，中文被存进了英语条目

现象：画面编辑器里中文显示正常，一运行全部变成"？？"，切换运行系统语言也没有任何改善。

原因：项目源语言是英语，中文没有被勾选为项目语言。工程师直接在图元里敲中文，这些中文文本被 WinCC 自动归属到英语语言条目下，运行时按英语代码页读取中文字节，渲染成问号。

解决：在项目属性 -> 语言里勾选中文，把源语言改为中文。但此时已经有大量存量文本归属错误，光改设置不会自动迁移。常见做法是：先把现有文本库导出备份，然后重建项目语言配置，再用文本导入功能把备份的文本内容按正确的语言列导回去。如果文本量不大，也可以直接全选画面对象重新录入一次，一次性从根上纠正归属。

5.2 运行系统语言和项目语言相互错位

现象：主画面正常，但报警控件、趋势控件里的文本显示问号；服务器上正常，客户端上问号。

原因：WinCC 的报警记录组件有自己独立的语言配置。项目语言和运行系统语言切换后，报警记录的文本没有重新编译到对应的语言版本，运行时按当前语言取不到报警文本。客户端问号则是运行系统语言与客户端操作系统区域语言不一致导致。

解决：在报警记录编辑器里打开报警文本，确认语言和项目语言一致，然后重新编译报警记录；客户端则检查操作系统的区域语言和字体设置，安装中文字体或切换到中文区域。排查时要记住：WinCC 的多语言机制是分散的，画面文本、报警文本、变量注释、归档文本都有自己的语言条目，不能只检查一处。

5.3 对象字体不支持中文字形

现象：画面里一部分中文正常，一部分问号，而且是同一个对话框里有的正常有的问号。

原因：正常的那部分对象字体是宋体或 SimSun，问号部分的对象字体是 Arial 或 WinCC Standard。Arial 不含中文字形，运行时无法渲染。

解决：在图形编辑器中选中问号对象，把字体统一改为宋体/SimSun，或按第 3 章的方法批量选中统一设置。设置完成后重新运行，不需要重编译项目。这一条是问号问题里最容易被误判成"项目语言有问题"的情况，实际上只要改几十秒。

5.4 客户端系统缺中文字体

现象：服务器操作正常，通过远程桌面或瘦客户端打开画面，整个画面中文全部问号，英文和数字正常。

原因：客户端操作系统是英文版本，未安装中文语言包或中文字体。WinCC 运行时在客户端上渲染文本，字体映射是在客户端完成的，服务器端装了中文字体也帮不上。

解决：在客户端操作系统安装中文语言包或至少安装中文字体。如果是瘦客户端，检查它的固件里是否包含中文支持模块。这个问题最容易让人绕远路——我曾经在现场折腾了半天 WinCC 项目设置，最后发现是那台一直用来远程监看的笔记本系统语言不是中文。客户端不承担组态任务，但承担显示任务，显示环节的字体缺失就会问号。

5.5 文本库导入把 Tab 分隔符换成了逗号

现象：修改导出文件后导入，文本库里大批量文本变成问号，有些行导入时报错"缺少列"。

原因：修改时用了 Excel 的 CSV 格式，或另存时选了"CSV 逗号分隔"，WinCC 无法正确解析列。还有一部分是另存时编码变成了 UTF-8 无 BOM，被按 ANSI 误读。

解决：重新导出基线文件，在 Excel 里编辑时保持 Tab 分隔，另存为"文本文件（制表符分隔）"，Notepad++ 确认编码为 ANSI 后导入。同时养成导入前备份文本库的习惯。我有一次没备份直接导入错误文件，整个项目的画面文本全军覆没，最后花了一个下午从备份里恢复，从那次之后备份成了固定动作。

6. 把问号检查变成例行体检：语言自检与编码自查脚本

问号问题最大的特点是"平时不出事，出事就一次一大批"。与其每次现场救火，不如在项目交付前做一轮自动化检查。

第一个习惯是做一个语言自检画面。新建一个隐藏画面，把常用的中文字符、中文标点、全角数字和特殊符号（比如"流程图、设备（启/停）——。￥℃"）放在上面，运行时切换每一种运行系统语言打开这个画面，肉眼扫一遍。这个画面不参与日常操作，只用于验证部署环境。如果某个语言下自检画面问号，说明该语言的语言包或字体缺失，在交付前就能发现。

第二个习惯是导入前查编码。下面这段 PowerShell 脚本可以快速判断导出的文本文件编码，避免把 UTF-8 无 BOM 的文件直接丢给 WinCC：

$path = "C:\WinCC_Text\Export.txt" $bytes = [System.IO.File]::ReadAllBytes($path) if ($bytes.Length -ge 3 -and $bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) { "UTF-8 with BOM，可导入" } elseif ($bytes.Length -ge 2 -and $bytes[0] -eq 0xFF -and $bytes[1] -eq 0xFE) { "UTF-16 LE，不建议导入" } else { "ANSI/GBK 无 BOM，最常见，可直接导入" }

脚本逻辑说明：文件头三个字节 0xEF 0xBB 0xBF 是 UTF-8 的 BOM 标记；文件头两个字节 0xFF 0xFE 是 UTF-16 LE 的标记；两者都不是，则大概率是 ANSI/GBK。经典 WinCC 对 UTF-8 无 BOM 的文件识别不友好，所以只要不是明确带 BOM，就按 ANSI 处理更稳。

第三个习惯是"备份-导入-切换三连查"：导入文本库前先做完整备份，导入后立即切换运行系统语言验证自检画面，最后再切回默认语言确认日常界面。这三步做完，问号问题基本能在两分钟内定位到具体环节——是语言设置、是字体、还是文件编码。

问号问题说到底不是玄学，是 WinCC 语言机制的三个环节没有对齐。我在现场吃过没备份的亏之后，每次动文本库都把"先备份、后导入、导入前编码三连查"挂在嘴边。希望帮到你。

本文还有配套的精品资源，点击获取