简介：针对经典WinCC画面文本显示问号或乱码的常见故障，这份资源整理了完整的排错思路与操作指南。内容面向工业自动化工程师、WinCC项目维护人员，尤其适合在项目迁移或版本升级后遇到文本显示异常时参考。文档以docx格式提供，共1个文件，压缩包大小244KB，内容精炼，便于快速查阅与打印。目前已有1765人学习下载，说明该问题在实际工程中较为普遍。文档从对象属性中的“组态语言”检查入手，逐步讲解如何通过图像编辑器语言设置、运行语言与组态语言匹配、字体兼容性检查等步骤解决问题，并提醒注意操作系统与WinCC版本兼容性。通过阅读可直接对照操作，快速定位乱码根源，避免反复调试，提升项目迁移和升级效率。

1. 经典WinCC画面文本显示问号：常见，但你很可能找错方向

“经典WinCC画面文本显示问号？？”是组态项目里最容易被误判成“编码问题”的一类故障：画面编辑器里中文明明正常，一进运行系统就变成“??”甚至一串“???”，或者做完语言切换后中文全丢。我处理过不少这类工单，结论往往让人意外——不是中文没存进去，也不是数据库坏了，而是WinCC的字体映射和文本列表语言机制在运行期拿不到可用字形。这篇文章就围绕经典WinCC（7.x以及沿用该架构的V8.0/V8.1 PC Runtime，不是TIA Portal里的WinCC Unified）梳理静态文本和动态文本两套显示路径，给出能直接照做的修复步骤和五个高频现场，适合负责HMI画面维护、多语言面板交付的从业者。

2. 问号的三个来源：字体映射、语言匹配与动态文本机制

2.1 为什么是“??”而不是乱码：Unicode字形缺失的表现

很多工程师第一个反应是“中文编码不对”，于是去查项目数据库、查系统区域、甚至重新录入文本，结果问题依旧。这里要分清两个完全不同的现象：中文变成“锟斤拷”“脱库”这类乱码，那是字节被错误解释；而变成“??”或空方块，通常是文本本身已经以Unicode形式正确存在，但渲染字体中没有包含中文字符的glyph，系统找不到匹配字形时就用问号或方框代替。

WinCC组态编辑器（Graphics Designer）和运行系统（Runtime）的字体渲染路径并不完全一致。组态编辑器可以用系统字体回退链，宋体缺了还能退到微软雅黑；运行系统则严格按对象字体属性去查找物理字体，找不到就直接输出“??”。所以“编辑正常、运行问号”不是玄学，而是两套字体解析机制差异造成的。判断方法很简单：把画面里那段问号文本复制出来，粘到记事本里看是否中文正常；如果正常，就说明数据没丢，问题出在字体引用上。

另一个容易忽略的点是字号。某些中文点阵字体在小字号下没有对应字形，WinCC会把它们显示成方框，视觉上很像问号。遇到这种情况，先把字号临时调到14号以上再观察，能快速把“字体缺失”和“字号太小”两个原因区分开。

2.2 静态文本问号的根因：画面对象字体与全局Text Font映射

静态文本（Static Text）是最简单的画面文字对象，它的文本内容直接存在画面里，不随语言切换变化。这类文本显示问号，绝大多数是字体属性指向了一个不支持中文的物理字体。WinCC里的字体引用方式比较特殊：对象可以指定一个具体字体，也可以引用一个逻辑字体名，再由逻辑字体映射到物理字体。这个映射关系由全局“Text Fonts”编辑器统一维护。

常见的翻车路径是：组态时把对象字体设成“宋体”，看着没问题，但后来有人在全局Text Fonts里把默认逻辑字体改成了Arial或Tahoma，画面对象因为引用的是全局逻辑字体，运行时就全部继承成了西文字体。中文在Arial下没有可显示的字形，于是整幅画面的中文全部变成“??”。

还有一个高频来源是操作系统或WinCC缺少中文字体。目标机器如果是英文版Windows，或者安装时没有带上中文语言包，即使项目里指定了“SimSun”，运行系统也找不到这个物理字体文件，只能回退到默认字体。不同Windows版本对这个回退链的处理不一样，Windows 10英文版有的能自动回退到“Microsoft YaHei”，有的则直接输出问号，这就导致了同一套项目在不同操作员站上表现完全不同。

WinCC里中文字体名称有个“显示名”和“内部名”的差异，在字体对话框里看到的是“宋体”，保存到项目里用的可能是“SimSun”。如果你在脚本或配置文件里直接写字体名，最好用内部名。下面这张表是经典WinCC项目里最常用的几个字体对照：

2.3 动态文本问号的根因：文本列表与运行语言匹配

动态文本（Dynamic Text）是另一类画面文字对象，它的内容不是直接写死中文，而是在运行时从WinCC文本列表（Text List）里按当前运行语言取对应的文本条目。比如一个“设备状态”文本，在中文语言下取“运行”，在英文语言下取“Running”。这种机制本身没有编码问题，但坑在于：如果文本列表里只有参考语言（组态语言）一列有中文，运行语言切到英文后没有对应条目，运行系统会输出“??”占位符。

更隐蔽的是，很多人在组态时把中文直接填进了动态文本对象的“默认文本”属性，而不是填进文本列表条目里。画面打开时中文显示正常，一旦运行语言被脚本切走，默认文本不参与语言映射，再切回中文时对象内容已经丢失，显示问号后无法自愈。

从大型PLC或OPC Server（比如通过KepServerEX通讯读变量字符串）上来的中文又不一样：变量值以字节数组形式进WinCC时是按单字节编码处理的，PLC侧如果是GBK编码字符串，WinCC按Unicode解析自然会出现乱码或问号。这类数据源问题不应该靠画面字体解决，而是在PLC侧改为UTF-8编码，或者在WinCC侧用脚本做字节转换。

动态文本问号往往是“语言映射缺失”和“字体覆盖不足”两个条件叠加：即使文本列表里已经填好中文，动态文本对象引用的字体如果不支持中文，一样显示问号。所以排查时要同时看文本列表和字体两层，不能只看一个。

3. 静态文本修复：单对象字体、全局Text Font与系统区域

3.1 单个画面对象：字体属性这样改才不会马上被打回原形

先用最简单的场景入手：整个画面只有一两个文本对象显示问号，其他对象正常。这种情况下，通常不用动全局设置，只改对象字体即可。

操作步骤：

1. 在Graphics Designer里打开目标画面，双击显示问号的文本对象，进入对象属性对话框。
2. 找到字体属性。WinCC的字体属性一般显示为“字体/Font”，点击后会弹出Windows字体选择框。
3. 字体选择“宋体”或“SimSun”，字符集选择“中文 GB2312”或“CHINESE_GB2312”。这一步很多人漏掉：只改字体名不改字符集，保存后还是可能回退成西文字符集。
4. 字号不要小于12号。中文点阵字形在小字号下容易渲染成空心方框，看起来跟问号很像。
5. 点击确定后保存画面，重新编译该画面，再进入运行系统验证。

改完之后，建议立即做一个回读检查：重新打开这个对象的属性，确认字体栏显示的是“宋体”而不是“Arial”或“默认字体”。如果保存后再打开被恢复成“默认字体”，说明全局Text Fonts里存在覆盖逻辑，单对象改不彻底，要去处理3.2节的内容。

这里要补充一个判断技巧：在属性对话框里，如果字体栏显示“Text Font”，说明这个对象引用的是逻辑字体名；如果显示具体的“宋体/SimSun”，说明这是物理字体直连。前者受全局映射影响，后者不受。实际项目里，我优先把所有静态文本改成物理字体直连，这样全局变化不会波及老画面。

3.2 全画面批量修正：用全局Text Font兜底

如果一幅画面几乎所有中文都变成问号，或者单对象改完保存后又复发，问题基本在全局Text Fonts映射。WinCC把这个设置放在了独立的“Text Fonts”编辑器里，平时很少人打开，出问题时是最难找的地方。

操作步骤：

1. 从开始菜单找到WinCC工具组，打开“Text Fonts”编辑器。它在WinCC安装目录的Tools子目录下，图标是个T字形。V8.0以上版本也可以从Graphics Designer的“设计/Design”设置入口进入，两个入口编辑的是同一份项目配置。
2. 编辑器左侧是逻辑字体列表，常见的逻辑字体有“Standard”“Header”“Title”等。右侧是对应的物理字体名称。把所有逻辑字体的物理字体都改成“SimSun”。
3. 检查“默认语言字体”下拉框，确保默认语言是“中文（简体，中国）”。这个设置会作为新建画面对象的默认字体来源。
4. 保存并关闭编辑器，重新启动Graphics Designer，再打开之前有问题的画面。
5. 按F4刷新画面，逐个检查文本对象属性，确认字体栏不再显示“Arial”或“Tahoma”。

关键参数是“逻辑字体→物理字体”的映射关系：只要逻辑字体指向一个不支持中文的物理字体，所有继承该逻辑字体的画面对象都会在运行期输出问号。

提示：直接在开始菜单搜“Text Fonts”不一定搜得到。WinCC 7.x的此工具安装在安装目录Common Files或Tools下，WinCC V8以后在“开始菜单→Siemens WinCC→Engineering Tools”下。装过多个版本的机器，注意区分版本入口。

改了全局字体后，需要重新编译所有受影响画面。经典WinCC的编译操作是：在WinCC项目管理器中选中Graphics Designer，右键选择“编译/Recompile All”，全量重新生成画面运行文件。只编译单个画面也可以，但如果其他画面也用了同一逻辑字体，建议一次全编译，避免后续逐个爆雷。编译完成后，运行系统里中文一般就能正常显示。

3.3 操作系统区域语言：把非Unicode程序语言和WinCC安装语言对齐

做完整项目交付时，问号问题还经常出在操作系统层。经典WinCC对系统区域设置非常敏感，因为它的部分本地化资源文件仍然按ANSI代码页读取。目标机器的“非Unicode程序语言”如果不是中文，WinCC在查找中文字体名称时会失败，进而回退到默认西方字体。

解决步骤：

1. 打开Windows控制面板，“区域和语言”或新版系统的“区域”→“管理”选项卡。
2. 点击“更改系统区域设置”，选择“中文（简体，中国）”。注意不是“区域格式”，而是底部“非Unicode程序的语言”对应的系统区域设置。
3. 系统提示重启机器，确认重启。
4. 重启后，打开WinCC项目管理器，进入项目属性里的语言设置，确认“中文（简体，中国）”被添加，并且被勾选为允许的运行语言。项目里如果存在多种语言，把中文设为默认启动语言。
5. 重新打开画面并进入运行系统验证。

这里有一个非常常见的误操作：在“管理”选项卡里勾选“Beta版：使用Unicode UTF-8 提供全球语言支持”。这个选项对经典WinCC很不友好，勾选后WinCC的ANSI代码页读取逻辑会错乱，结果往往是文本全部变问号、工程文件启动异常。处理这个问题时，一定要先取消该Beta选项并把系统区域改回中文，再考虑其他修复。

如果项目要部署在多语言操作系统上，比如德语或阿拉伯语版Windows，无法把系统区域改成中文，那就要在每台目标机器上安装中文字体，并在Text Fonts编辑器里把物理字体明确指向“SimSun”。另一种做法是使用Arial Unicode MS，它覆盖的字符集范围很广，难点是需要正版授权且字体文件较大，运行系统首次加载会有可见延迟。对生产过程画面而言，字体加载延迟在换画时会让人误以为系统卡死，需谨慎选用。

4. 动态文本与多语言切换：文本列表才是问号的隐藏来源

4.1 建文本列表并填好中文翻译：Text Library的两种填法

动态文本的问号问题和静态文本完全不在一个层面。静态文本只要字体对就能显示；动态文本即使字体正确，只要文本列表里缺中文条目，运行系统照样输出“??”。文本列表的统一入口是WinCC项目管理器里的“Text Library”（文本库）编辑器。

常见做法是这样的：

1. 在WinCC项目管理器中双击“Text Library”，打开文本库编辑器。
2. 左侧是文本列表（Text Lists）列表，右侧是条目（List Entries）内容。
3. 先确认编辑器顶部的语言页签里包含“中文（简体）”。如果没有，先在项目语言设置中添加中文，再回到文本库刷新。
4. 新建一个文本列表，例如“DeviceStatus”，在列表条目编辑区添加若干条目。
5. 每个条目有多列，列名是已启用的各语言。在最左侧的“参考语言/Reference Language”列填入中文原文，例如“运行”；随后在中文列填入同样的中文，英文列填入“Running”。

实际组态中，条目列的填写有两种做法：一种是只填参考语言列，系统默认其他语言列继承参考语言；另一种是逐列显式填写。前者省事，但一旦运行语言切到英文，英文列取到的是中文内容，界面就会中英混杂；后者费时但可靠。对于面向出口项目的多语言面板，逐列填写的可维护性要好很多。

还有一种常见情况：文本列表是从CSV导入的，导入时只映射了参考语言列，其他语言列全部留空。运行系统遇到空条目时不会回退到参考语言，而是直接输出问号。

注意：文本列表条目里的空字符串和“??”不是一回事。空字符串在画面上显示为空白，问号是“找不到条目”的占位符。填表时如果发现某条中文列显示为“??”，先删掉重新填，保存后确认文本库不再报错。

4.2 画面动态文本绑定：引用文本列表而不直接写死中文

文本列表建好后，要把画面里的文本对象绑定上去，这一步的组态方式决定了运行语言切换后是否还会问号。

以最常见的动态文本对象为例：

1. 在画面工具箱中选择“动态文本/Dynamic Text”对象，拖放到画面上。
2. 双击对象打开属性对话框，在“文本/Text”相关属性里找到“文本列表/Text List”选项。
3. 勾选“从文本列表获取内容”或类似选项，下拉选择刚创建好的文本列表（如“DeviceStatus”）。
4. 在“列表条目/List Entry”里选择需要显示的条目。
5. 确认对象的字体属性为“SimSun”。

绑完之后，不要直接在动态文本对象上写死任何中文字符串。很多组态工具的动态文本对象允许填写一个默认文本，这个默认文本只在运行语言无法匹配时作为后备显示。一旦切成其他语言再切回来，默认文本优先级低于文本列表条目，但不会触发字体渲染，所以看似恢复正常，实际列表条目仍是缺失状态。

判断动态文本是否绑定成功，可以在组态状态下切换一次语言：调用语言切换脚本把运行语言临时改成英文，观察该对象是否显示为英文；再切回中文，观察是否显示中文。如果切回后是问号，问题在文本列表中文列缺失，而不是字体。

这里还要区分另一类显示场景——I/O域（I/O Field）直接输出变量值。变量值来自PLC或OPC服务器时，它不经过文本列表，显示内容完全由变量字节决定。KepServerEX与WinCC通讯时读到的字符串如果包含中文，经常在OPC通道里被转成Unicode后又按ASCII解析，最终显示问号。这种情况要回数据源排查编码，而不是改画面字体或文本库。

4.3 运行语言切换脚本：SetLanguage与全局脚本

多语言面板一定有语言切换按钮，WinCC里切换运行语言的标准脚本函数是SetLanguage。最常见的实现是在按钮的鼠标事件里直接调用：

#include "apdefap.h" void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName) { SetLanguage("Chinese"); }

这段代码的含义很明确：把运行系统的当前语言切换为“Chinese”。SetLanguage是WinCC提供的全局脚本API，参数必须和项目属性里配置的语言名称完全一致。如果项目里添加的语言显示为“中文（简体）”，脚本里则写“Chinese”；如果显示为“chinese”或“中文”，那脚本参数也要跟着变。参数不匹配时，函数不会报错，但语言不会切换，画面没有任何反馈，容易造成“脚本失效”的错觉。

更稳妥的写法是先读取当前语言再判断是否需要切换。语言切换按钮通常做成“中/英”切换，需要知道当前处于哪种语言，推荐用GetLanguage先读取：

#include "apdefap.h" void OnClick(char* lpszPictureName, char* lpszObjectName, char* lpszPropertyName) { char szLang[64]; GetLanguage(szLang); if (strcmp(szLang, "Chinese") == 0) { SetLanguage("English"); } else { SetLanguage("Chinese"); } }

GetLanguage()输出的是当前运行语言名称，保存在字符数组里；strcmp函数做字符串比较，相等则说明当前是中文。这段代码特别适合既做中英切换又做状态显示的按钮。很多工程师写的WinCC历史趋势曲线脚本里也会用到类似的语言判断——曲线图例文字在语言切换后如果变问号，通常是因为图例文本没有走文本列表，而是在脚本里直接写死中文导致的。改法是在脚本里按当前语言选择不同的图例字符串，或者把图例也改成动态文本。

5. 避坑与排查：五个常见现场的现象、原因与处理顺序

5.1 现象：组态电脑正常，服务器或操作员站全问号

项目开发机上画面中文显示一切正常，拷贝到服务器或操作员站运行后，整幅画面或者部分画面中文变成“??”。这是项目交付阶段最常遇到的现场，通常和画面文件本身没有关系。

原因分析：目标机器没有安装中文字体，或者目标机器Windows的“非Unicode程序语言”不是中文。WinCC运行系统在做字体渲染时，会根据画面对象里的字体名称去目标系统查找对应的物理字体文件。开发机的Windows自带SimSun，服务器是英文版Windows或精简版系统，没有SimSun，系统回退到默认西文字体，中文自然变成问号。

解决办法：在目标机器上安装中文字体文件，并确认系统区域设置为“中文（简体，中国）”。批量部署时，可以在项目发布包中附带字体安装脚本，用批处理把simsun.ttc复制到Windows的Fonts目录并注册。另一个办法是让WinCC项目的Text Fonts映射指向Arial Unicode MS，该字体随Windows Office组件分发，在多数办公系统上存在；但工业操作员站如果是精简系统，不一定安装Office，仍需单独检查。

5.2 现象：TIA Portal打开经典WinCC项目后中文变问号

有些改造项目会涉及用TIA Portal对老WinCC工程做维护。在TIA Portal中打开经典WinCC项目，或者用WinCC Professional/Comfort功能导入旧画面后，发现中文全部变成“??”

原因分析：TIA Portal和经典WinCC的文本列表结构、字体映射机制并不兼容。经典WinCC项目里通过Text Fonts逻辑字体建立的映射关系，在TIA侧可能没有被正确转换，尤其是标题字体和默认文本字体这类带逻辑引用的设置。项目如果还涉及WinCC Comfort的许可证问题，比如V15.1找不到许可证，组态库加载不完整也会导致字体引用异常。

解决办法：先解决许可证和基础环境，确保WinCC Comfort/Professional功能可用；然后在TIA侧重新为画面对象指定中文字体，不要依赖旧项目的逻辑字体映射。同时在TIA侧重新建立文本列表或导入经典WinCC文本库的CSV导出文件，再逐语言检查。最关键的一条：不要在两套工程环境之间反复保存同一批画面，这样会让字体映射丢失得更彻底。

5.3 现象：Windows区域里勾“UTF-8 Beta”后画面全毁

项目现场新装的一台操作员站，Windows 10系统，为了处理某个第三方软件的乱码，运维人员在“区域”设置里勾选了“Beta版：使用Unicode UTF-8 提供全球语言支持”。重启后WinCC画面一片问号，甚至有的画面无法打开。

原因分析：经典WinCC的本地化资源读取依赖系统ANSI代码页，UTF-8 Beta模式改变了代码页映射规则，WinCC在读取中文字体名称和文本库条目时按错误代码页解析，字形查找失败，于是输出问号。这不是字体文件缺失，而是系统层代码页状态异常。

解决办法：取消勾选该Beta选项，把系统区域改回“中文（简体，中国）”，重启计算机。重启后重新打开WinCC项目，一般可以自动恢复。如果画面仍然异常，删除该画面的编译缓存文件，重新编译画面。工控上位机不建议勾选这个Beta选项，它和WinCC、S7-PDI、授权组件的兼容性普遍较差，属于典型的“看着能解乱码、实则引入新乱码”的设置。

5.4 现象：动态文本运行时正常，备份恢复后变问号

项目从一台机器备份到另一台机器，或者把项目打包发给同事继续开发，恢复后动态文本显示“??”。原机器上是好的，打包之后就坏。

原因分析：WinCC文本库的导出/导入对语言列有裁剪。部分版本在备份时只导出当前运行语言和参考语言的条目，其他语言列在恢复后变成空。也有可能是备份过程中文本库文件没有包含中文语言列，恢复后语言列表里中文被折叠成参考语言，运行语言匹配不到独立的中文条目。

解决办法：备份前先打开Text Library，确认每个文本列表都有中文列且非空；再执行一次完整编译，编译成功后再备份。恢复之后，第一时间打开Text Library，逐条核对中文列内容。如果已损坏，用CSV导出格式批量补：导出所有语言列，在Excel里筛选中文列为空的记录，统一填值后重新导入。这个操作是文本库维护里效率最高的补救方式。

5.5 现象：WinCC V7升V8.1或重新激活后问号

项目从WinCC V7.4升级到V8.1，激活运行后旧画面的中文全部变成问号，新建的画面正常。或者V8.1激活后第一次运行，原有面板出现零星问号。

原因分析：升级过程会重建默认字体映射表，旧项目里很多画面对象引用的是升级前版本的逻辑字体名称，升级后的字体库对旧逻辑字体名的解析结果改为西方字体。只对旧画面产生影响，新建画面用新默认字体所以正常，这个差异本身就是很好的定位依据。

解决办法：升级后打开Text Fonts编辑器，把所有逻辑字体统一重置为SimSun；然后删除运行系统生成的字体缓存和画面编译缓存，重新完整编译项目。激活状态确认无误后再次启动运行系统，问号一般能消失。这里要提醒的是：升级后在第一时间检查Text Fonts，而不是等到现场报故障再处理。预防成本远低于事后逐画面恢复。

6. 一个运行期自检脚本与检查收尾习惯

6.1 运行时语言自检脚本：开机先判语言再决定是否切回

多语言项目里，很多问号并不是字体问题，而是上一次运行结束时语言停在了英文或其他语言，再次开机后运行系统按记忆语言启动，中文文本因文本列表无对应条目显示成“??”。在项目启动画面里放一段语言自检脚本，能避免这类“假问号”。

#include "apdefap.h" void OnOpenPicture(char* lpszPictureName, char* lpszObjectName) { char szLang[64]; GetLanguage(szLang); if (strcmp(szLang, "Chinese") != 0) { SetLanguage("Chinese"); } }

OnOpenPicture是画面打开事件，在启动画面的属性里挂接这段脚本，进入运行系统时自动执行。GetLanguage把当前语言名写入szLang，strcmp判断它不是“Chinese”就直接切成中文。这里的语言名要与项目语言设置严格一致。如果项目主语言是简体中文，一般传“Chinese”。切完语言后，画面上所有动态文本会自动刷新到中文状态。

6.2 文本列表完整性检查：导CSV用Excel批量补齐中文列

排查问号问题的最后一步，是确认文本列表没有空语言列。手动逐条检查效率太低，我一般用文本库的CSV导出/导入来做完整性检查：在Text Library里把所有语言列导出为一个CSV文件，用Excel打开后筛选中文列内容为空的记录。需要关注的不仅仅是完全空白，还有单元格内容为“??”的假值。

批量补全后重新导入文本库，再做一次完整编译。这个习惯能显著减少交付后因翻译缺失导致的问号工单。我现在接到“画面问号”报障，通常按这个顺序排查：先看目标机区域语言和字体，再看全局Text Fonts映射，最后查文本列表中文列。按这个顺序处理，大部分问题能一次到位，不用来回折腾。希望这些经验和参数能帮到正在跟WinCC画面较劲的你。

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