企业官网建设流程全解析

做SAP的顾问应该都见过这个场景：用户跑过来，截图一张PFCG菜单界面，菜单树里的功能项全部显示成三四个井号“###”，或者干脆是方框、问号、一团乱码。第一反应是系统乱码，其实性质完全相反——这恰恰是SAP在告诉你“这里有数据，但没有对应的文本”。我最早在项目上遇到的时候也绕了不少弯子，后来排查多了发现，这类问题背后几乎都能在一个表里找到答案：TSTCT。

先把这个故障定性清楚：PFCG菜单乱码，绝大多数情况下不是权限配置错了，也不是前端字体编码问题，而是事务代码的短文本缺失或语言不匹配。SAP里事务代码本身的配置存在TSTC表，但它在菜单里显示的名字是存在TSTCT表里的，这张表是语言相关的，主键是语言代码加上事务代码。用户登录语言是中文，正好TSTCT里没有这个事务代码的中文记录，那SAP就给你显示“###”。所以拿到这类报障，先别急着在PFCG里翻来翻去，直接去核对TSTCT，方向对了，问题就解决一半。

这篇文章就围绕这个事展开，把PFCG菜单乱码的成因、排查路径、修复手段一次说透，顺便把我在几个项目上踩过的坑也交代一遍，给后面遇到同类问题的朋友做个参考。

1. PFCG菜单乱码到底是什么

1.1 故障现场两种常见表现

先说现象。PFCG菜单乱码不是单一的画面，我实际遇到过的至少有两种：

第一种是“###”密集阵。角色维护事务代码PFCG里，打开某个角色的“菜单”页签，点“添加事务”，弹出来的树形菜单里全是###。这种最典型，一眼就能判断是文本表缺记录。

第二种是“中西结合”。有些菜单项能看到英文，有些是中文，有些就是##或者乱码符号。这种情况比第一种更迷惑人，因为看起来不像是完全缺文本，倒像是语言包没装全。但排查到最后，本质还是一样：TSTCT表里该语言下对应事务代码文本记录不完整，显示英文的可能是SAP做了语言回退，显示###的就是彻底没找着文本。

还有第三种比较罕见，是字体问题。如果你把SAP GUI的语言设置成中文，但操作系统的字符集不支持，或者GUI的字体选项被改成了某个不支持的字体，菜单里中文会显示成方框。这种和SAP本身没关系，属于纯前端问题，后面我会单独讲怎么排除。

1.2 乱码背后涉及的机制

要真正搞懂这个问题，得先理解SAP菜单显示文本的取数逻辑。PFCG里角色菜单上能看到的事务代码名称，本质上来自一张语言相关的文本表——TSTCT。它的逻辑很简单：

• 你在PFCG里添加事务代码到角色菜单，系统根据事务代码到TSTCT里去找对应语言的短文本。
• 找到了就显示，找不到就回退或显示###

这里的“对应语言”指的是什么语言？SAP GUI登录时，快捷方式里指定的语言代码。比如你登录时用的是中文（ZH），那PFCG菜单就会尝试取TSTCT里SPRAS=ZH的记录。

这里容易混淆的一个点是：TSTCT是语言相关的，而TSTC不是。TSTC表存的是事务代码的技术信息，比如事务代码指向什么程序、是什么类型的值，这些配置不区分语言。但TSTCT纯粹是文本，同一个事务代码，英文一套、中文一套、德文一套，彼此独立存储。

所以在排查的时候逻辑就清晰了：只要菜单上显示###，就说明当前登录语言下，TSTCT里没有这个事务代码的文本记录。

这里有个容易被忽略的知识点：SAP标准事务代码的TSTCT记录，是跟着语言包一起进来的。系统初始安装时，只有源语言（通常是英文或者德文）有文本，中文语言包激活之后，标准事务代码的中文文本才会出现在表里。如果中文语言包没装全，或者装的过程中出现过问题，那部分事务代码的ZH文本就是缺失的。

而对于自开发程序，情况更特殊。开发环境里通过SE93创建事务代码时，那个“短文本”字段就是写入TSTCT的内容。但如果开发机、测试机、生产机的语言配置不一致，或者传输的时候源语言的文本没有正确传过去，那到了生产机就很容易出现TSTCT缺失的情况。

2. 排查思路：先分清六种“假乱码”，再动手

我处理这类问题吃过亏，早期一看到###就直接去改TSTCT表，结果有几次根本就不是缺文本，白折腾。后来总结出一个套路：先分类，再动手。我把“菜单乱码”拆成六种情况，对号入座之后再做处理，基本不会跑偏。

2.1 第一类：TSTCT缺语言条目

这是最常见的情况，角色菜单里添加的事务代码，在当前登录语言下没有文本记录。

排查方法很简单：SE16N查TSTCT表，输入事务代码，再看SPRAS字段有没有当前语言（通常ZH）。如果SPRAS=ZH的记录是零条，而SPRAS=EN有记录，那就锁定了。

这类问题修复起来也不复杂，后面实操部分会细说。最核心的一点是：你不需要去改TSTC表，只需要补TSTCT的文本记录。

2.2 第二类：自开发程序短文本未维护

这类情况多发在生产机。开发环境里SE93创建事务代码时，“短文本”字段没填，或者填了但传输时没带上。结果就是在开发机看菜单一切正常，到了生产机就显示###。

为什么会这样？很简单，短文本写没写是TSTCT有没有记录的前提；但更麻烦的是，SE93保存事务代码后，短文本并不一定立刻写入TSTCT，它往往要等对象激活、生成、传输后才真正同步到目标系统的TSTCT。

我遇到过一种极端情况：顾问在开发机把SE93里的“短文本”从“Z固定资产导入”改成了“Z固定资产导入程序”，但只传输了程序，没有传输事务代码的对象（SE93的传输请求只包含事务代码定义）。改动后的短文本不会自动同步过来，生产机TSTCT里还是旧文本。这种看似是小问题，但用户看到的就是菜单文本对不上、乱码、缺字。

所以对自开发程序，原则只有一条：SE93里的短文本务必填写规范，并且每改一次都要保证传输到目标系统。

2.3 第三类：语言包未安装或安装不全

这一类的典型特征是系统整个菜单都乱码，不光是PFCG，比如SAP菜单、系统菜单、快捷键列表里全是###，影响面大。

原因是中文语言包没有正确安装或激活不完整。注意，语言包的安装不是一个开关，而是一个后台任务——你通过SMLT（语言管理）安装中文语言包时，系统会跑一批后台作业，后台作业负责把标准文本（包括TSTCT的ZH记录）写入各张文本表。如果后台作业中途失败，或者某个步骤被跳过了，就会出现部分记录缺失。

这种故障排查起来相对麻烦，因为它不是某个事务代码的问题，而是整个语言环境的问题。最直接的办法是检查SMLT里中文语言的状态，看看是否有激活标记；如果语言包不完整，可以在系统允许的情况下重新进行语言激活步骤，或者单独补充缺失的文本。

2.4 第四类：前端字体与GUI配置问题

这类严格意义上不算SAP服务器故障，但现象上跟乱码极其相似——中文菜单显示成方框、烂码、问号。区别在于：这类问题只出现在个别用户或个别电脑上，同一账号换台电脑就好了。

原因是SAP GUI的字体设置。在SAP GUI的“选项-可视设计-字体设置”里，如果选择了不支持中文的字体，中文渲染就会出现方框。解决方法也很简单：把字体改成中文字体，或者直接勾选“使用系统字体”。

判断这类问题有一个小技巧：按F1帮助或者看看选中菜单项的描述有没有正确显示。如果F1里的描述是正常的，菜单栏却乱码，那大概率是GUI渲染问题，不是SAP数据问题。

2.5 第五类：传输不完整导致远端缺文本

这个比较隐蔽。特别是那种开发和传输走不同系统的环境：项目上可能有DEV、QAS、PRD，但你实际维护短文本的可能是另一个DEV，导致传输请求里根本没有把SE93的短文本纳入。

还有一种可能是，源系统里TSTCT的文本记录已经存在，但传输到目标系统时，因为目标系统此前的传输历史里有“删除文本”的操作，导致新文本没有覆盖成功。这种情况在标准传输中不常见，但在CRT（配置传输）和异常处理中偶尔能看到。

排查方法是直接对比源系统和目标系统里TSTCT这张表的内容，如果源系统有ZH记录而目标系统没有，那就是传输漏了。重新传输对应的请求，或者在目标系统用程序补一条文本即可。

2.6 第六类：菜单“复制/继承”产生的脏数据

这类问题比较刁钻，你查TSTCT表完全正常，但PFCG菜单就是显示乱码。原因出在角色菜单本身。

在PFCG里你从别的角色“复制”菜单过来，或者通过SU22/SU24继承了一些权限，菜单树里的节点文本可能会被“固化”下来——也就是说，菜单节点保存的不是事务代码的“当前短文本”，而是复制那一刻的“快照文本”。如果那个快照文本在复制时的语言环境有问题（比如源角色是用德语或英语维护的），目标角色在中文环境下就可能显示乱码或空文本。

这类情况修复起来也不能直接改TSTCT，因为TSTCT没有问题。你需要去PFCG里找到对应菜单节点，手动改掉显示文本，或者干脆删掉那个菜单项重新添加一次。

总的来说，六类问题里至少有一半最终都要回到TSTCT表，所以实战中我习惯先查这张表，再判断问题属于哪一类。有个小小的经验总结给你：

3. 实操修复：从SE93到TSTCT的完整过程

分类完成后，接下来就是动手修。我这里以最常见的“TSTCT缺语言条目”为主线，把这个流程完整做一遍，期间穿插各类情况的处理手法。

3.1 第一步：确认登录语言和系统语言

解决方案对不上号，很多时候是你没搞清楚“当前登录语言”到底是什么。

SAP GUI快速登录的快捷方式里，参数“-”后面如果带了/3或者没有指定语言，那登录时用的就是用户主档里设置的默认语言。如果用户主档的语言代码和GUI快捷方式指定的语言有冲突，会出现一种情况：你明明觉得自己用的是中文，但系统实际用的登录语言是英文。

判断方法很简单：登录后看系统右下角，或者用SE37跑一下模块，用系统变量看当前语言。更直接的办法是用事务代码S000（登出后再登入）选择语言，或者在用户主档（SU01）里改默认语言。

确认完语言后，第二个要确认的是系统已安装的语言。用事务代码SMLT查看，里面会列出所有已安装语言包的状态。如果目标语言（通常是中文ZH）是“未安装”状态，那你再怎么维护TSTCT也是白搭——因为TSTCT的维护虽然能写进去，但系统的其他标准功能还是跟不上。这个场景下需要先做语言包安装，或者至少先让业务用户把界面语言暂时切换成英文。

排除掉语言环境的问题之后，后面的排查才有意义。

3.2 第二步：用SE16N查TSTCT，锁定缺哪个语言

登录语言确认是中文（ZH），系统也装了中文包，接下来就去查TSTCT。

按路径或直接输事务代码SE16N，进入表查询界面后填入表名TSTCT。接下来在查询条件里：

• 事务代码里填你怀疑有问题的那个事务代码，比如ZMI01
• 语言代码留空
• 执行之后，系统会列出该事务代码在TSTCT中所有的语言条目

你会看到类似下面的结果：

注意，这里有一个SAP的语言代码细节：中文在TSTCT里的SPRAS字段值不是“ZH”，而是“1”（数字1）。同理，英语是“E”，德语是“D”，日语是“J”。

如果你的查询结果里没有SPRAS=1的记录，只有E和D，那就说明ZMI01这个事务代码在中文环境下没有文本记录。PFCG菜单在中文登录下自然显示###。

如果查询结果里有SPRAS=1，但显示出来的文本内容是乱码、问号或者“#####”，那情况可能是另外两种：一是当初写入TSTCT的文本本身就有问题（比如从其他编码格式转换过来时损坏了）；二是该事务代码的文本是用其他语言的字符集错误写入的。

不管哪种，处理方式都差不多：修正TSTCT里该语言下的文本内容。

还有一种偷懒办法：直接用SE16N查TSTCT里某个事务代码是否存在，不输入语言，直接Enter看列表。但实战中我建议你把全部语言记录都拉出来看一遍，因为有的问题恰恰是“某条语言的文本被误写成了空白”。

3.3 第三步：标准程序与自开发程序分开修

排查确认是缺文本，接下来是修复。这里有一个重要原则——标准事务代码和自开发事务代码的修复路径完全不同。

标准事务代码（比如MM01、FB50）如果TSTCT缺中文文本，你不能随便用SE16N往TSTCT里乱插数据，因为标准文本是语言包管理的一部分，手动改了的记录在后续语言包更新时会被覆盖，而且短报文的不一致还可能引发其他问题。

正确的做法是检查系统语言包的状态。如果标准程序出现缺失，多半是语言包安装不完整，需要在SMLT里做一次语言补充激活。如果你不想整个系统重新跑一遍语言激活，也可以通过SAP提供的语言导入工具做增量添加。注意，这个操作通常需要申请SAP的许可或者联系管理员，属于系统级操作。

自开发程序则简单很多。像是项目上写了一个Z开头的事务代码，SE93里的短文本又没填中文，那你直接在SE93里补上短文本保存即可。保存后系统会自动写入TSTCT的对应语言条目。

这里要说明一个我一直想吐槽的点：开发机SE93维护的短文本，保存后不一定马上同步到TSTCT，它在保存时会写一个对象条目，只有通过传输请求传到目标系统，才会把文本记录带过去。所以如果你只在开发机维护了短文本而忘了释放请求，生产机的TSTCT就不会有对应语言的记录。很多PFCG乱码的故障根源就是这么来的。

3.4 第四步：PFCG重新生成菜单并验证

修好文本之后，还需要回PFCG里做一次菜单刷新，验证是否还有乱码。

具体操作：

1. 进入PFCG，输入角色的角色名，点修改。
2. 去“菜单”页签。
3. 右键点击菜单树根节点，选择“重新生成”或者“刷新”。
4. 如果有“比较”功能，可以先比较一下角色菜单和实际菜单的差异，看是否有菜单项因为找不到文本被排除了。
5. 保存角色，退出重新进入。

注意一个细节：如果PFCG里角色菜单是“手动模式”，也就是你手动在菜单树里添加过文件夹并自己改过显示文本，那么PFCG不会自动从TSTCT获取文本，你手动改的文本是什么样，它就显示什么样，哪怕TSTCT修复了也不变。这时候要改成“自动生成”模式，或者把菜单节点删掉重新添加。

我自己在一次项目上就是这么栽的：TSTCT补了文本，返回PFCG刷新菜单，结果乱码还在。后来发现是那个角色的菜单是手动模式，文件夹节点文本在创建角色时就被固化了。删掉那个节点重新添加，刷新后正常。

修复完后，最好让报障用户重新登录一次SAP GUI，因为PFCG菜单的显示有时会缓存用户的会话内容，重新登录是最稳的验证方式。

4. 批量修复：用ABAP程序给TSTCT“补语言”

单个事务代码补文本很简单，但实际项目上经常是批量缺失。比如某次语言包激活不完整，系统里上百个自开发事务代码都没有中文文本，一个个去SE93补会当场崩溃。这时候就得写一个小程序来批量扫表和补文本。

4.1 为什么要写程序

先说一个常见场景。一个系统上了很多年，里面可能有几百个Z开头的事务代码。这些事务代码在开发阶段大多数是由不同顾问维护的，有的顾问在SE93里填了中文短文本，有的只填了英文，有的甚至没填。

有一天做权限清理，用PFCG批量重建角色，用户登录一看——菜单里三分之一是###。你去查TSTCT，发现缺ZH记录的事务代码一大片。

用SE93挨个补？几百个事务代码，那不是一个小时能搞完的。而且SE93改短文本属于开发传输层面的调整，要走审批流程，成本和风险都高。如果只是想解决PFCG菜单显示问题，直接在TSTCT表里批量补ZH文本是更高效的赌法。

但这里有两个前提：

• 你只能给“确实有依据”的事务代码补文本。比如事务代码对应的程序名、程序描述是明确的，你可以根据英文文本翻译出一份中文文本批量写入。
• 批量修改TSTCT属于系统配置级操作，在生产环境需要走变更流程，并且要提前备份，出了问题能回滚。

所以我建议把批量补文本程序做成“只输出一个日志，不直接更新”的测试版，先把结果看一遍再决定是否真正修改数据库。宁可多跑几遍，也不要一把梭直接MODIFY。

4.2 程序逻辑代码和说明

下面给一个参考程序的逻辑骨架，适合在测试机先验证，再移植到生产机。

REPORT ZFIX_TSTCT_TEXT. TABLES: tstc, tstct. SELECT-OPTIONS: s_tcode FOR tstc-tcode. PARAMETERS: p_test AS CHECKBOX DEFAULT 'X'. FIELD-SYMBOLS <fs_tstct> LIKE tstct. DATA: lt_missing TYPE TABLE OF tstct, ls_missing LIKE LINE OF lt_missing. DATA: lv_source_text TYPE tstct-text, lv_tcode TYPE tstc-tcode. " Step1: 找出 TSTCT 里目标语言缺失的事务代码 SELECT tcode INTO lv_tcode FROM tstc WHERE tcode IN s_tcode. CLEAR: ls_missing. SELECT SINGLE text INTO lv_source_text FROM tstct WHERE spras = 'E' " 英文作为参考源 AND tcode = lv_tcode. IF sy-subrc = 0. SELECT SINGLE text INTO ls_missing-text FROM tstct WHERE spras = '1' " 中文 ZH 在 TSTCT 中语言代码为 1 AND tcode = lv_tcode. IF sy-subrc <> 0. ls_missing-spras = '1'. ls_missing-tcode = lv_tcode. ls_missing-text = lv_source_text. APPEND ls_missing TO lt_missing. ENDIF. ENDIF. ENDSELECT. IF p_test = 'X'. WRITE: / '缺失的语言条目数量:', lines( lt_missing ). LOOP AT lt_missing INTO ls_missing. WRITE: / ls_missing-tcode, ls_missing-text. ENDLOOP. ELSE. " 正式更新，建议先备份或记录修改日志 MODIFY tstct FROM TABLE lt_missing. IF sy-subrc = 0. COMMIT WORK. WRITE: / '更新完成', lines( lt_missing ). ENDIF. ENDIF.

简单说明这个程序做了什么：

• 先从TSTC表查出所有你指定范围内的事务代码。
• 对每个事务代码检查TSTCT里英文（SPRAS=E）是否有序。
• 再检查中文（SPRAS=1）是否有序。
• 如果英文存在而中文缺失，就把英文文本作为初始内容填入中文条目——当然，这一步只是应急，英文文本显示成中文环境，总比###强。如果业务人员能接受英文，就不急着翻译。

实际运行时要特别注意：

• TSTCT表的更新权限不是所有账号都有的，通常需要SAP_ALL或者特定的对象权限。
• MODIFY TSTCT之前一定要先备份，哪怕是用SE16N手动改，也要先记录原值。
• 在跨系统场景里，如果你在测试机运行了程序，还没决定生产机怎么处理，建议把测试结果导出成Excel，方便变更评审时展示。

这里提个细节：程序里我用英文文本作为中文缺失时的临时填充。如果英文也没有，那说明这个事务代码在TSTCT里的记录可能压根就没有，得先回去查SE93是不是连短文本都没维护。这类数据即使你强行补了一条，也没有参考价值，后面该显示乱码还是乱码——因为源文本本身就缺失。

批量补完文本之后，记得回到PFCG里重新生成角色菜单，步骤和前文一致。另外还要提醒一句：这种批量补TSTCT的做法虽然能解决菜单显示问题，但没有解决“为什么TSTCT会缺”的根本问题。如果根源是SE93短文本没维护，那新开发的程序照样还会出问题。治本的手段还是规范开发流程，保证每个SE93都填好短文本，并且完整走传输。

5. 常见问题与排查笔记

5.1 故障速查表

把实际项目中反复出现的情况整理成一张速查表，遇到问题直接对号入座。

这张表不是万能的，但覆盖了大多数PFCG菜单显示问题。拿不准的时候，先按表里的顺序排查，绝大多数情况下能在半小时内定位。

5.2 几个实际项目里很难查的边角案例

常规问题可以按流程走，但实际项目里总有几种情况，会让你觉得“明明是按流程处理的，为什么还是乱码”。我挑几个记忆深刻的写出来。

案例一：语言代码不是ZH，而是“1”

有一次项目上做知识转移，新来的顾问在SE16N里查TSTCT，条件SPRAS填了ZH，查不到数据，回来告诉我“这个事务代码在TSTCT里不存在”。我过去一看，条件填错了。

SAP内部的语言代码，中文在TSTCT里是数字“1”，不是“ZH”，英语是“E”，德语是“D”。很多从其他系统接触过SAP的人会习惯性地以为中文就是ZH，因为SU01用户主档里显示的是ZH。实际上ZH是外部显示代码，内部存储值在语言相关表里是1。这个细节特别容易让人绕弯子，建议遇到TSTCT相关的问题第一件事就是确认你用的语言代码是内部代码。

案例二：文本表有记录，但内容本身是乱码

有一次排查一个Z程序的菜单乱码，TSTCT里中文记录是存在的，但内容一看就不对——一堆“###”里夹杂着几个能看懂的字。这种属于当年创建事务代码时，SE93在开发机上的代码页和传输目标系统的代码页不一致，导致文本在传输过程中被错误转换。

这个修复比缺记录更麻烦，因为直接改TSTCT文本可以解决，但改完仍要同步回SE93，否则下次从开发机重新传输，乱码文本又会覆盖回来。我遇到的那次，最终是让开发顾问在SE93里把短文本删掉重填，重新走传输，才彻底根除。

案例三：不同版本ECC行为不一致

SAP ECC 6.0 EHP4和EHP8，在菜单文本回退逻辑上表现不同。老版本里，中文环境如果找不到中文文本，会老实显示###；新版本在某些配置下会尝试回退到英文。这个差异会导致同一个问题在两个不同系统上呈现出完全不同的表象——一个全###，一个中英混杂。

所以如果你维护多个系统，看到同样的菜单在不同系统显示风格不一样，先别怀疑配置，用SE16N查一下同一个事务代码在不同系统的TSTCT里有没有差异，往往很快就能找到答案。

案例四：角色菜单里自建文件夹的“假乱码”

最后说一个最容易骗人的。某个角色的菜单里，用户自定义了一个文件夹叫“日常工作”，“菜单”页签里显示正常。但用户用SAP GUI打开菜单时，这个文件夹的名字却变成了一堆问号。

查遍了TSTCT，发现一切正常。后来才搞明白，这个文件夹的文本是当时在英文登录环境下创建的，文本存的是英文。用户用中文登录，文件夹保存的英文文本没有对应中文映射，就显示成乱码。

这种问题在TSTCT里是找不到答案的，因为文件夹文本根本不在TSTCT，而是直接存在角色菜单数据里。修复方式就是在PFCG里把文件夹节点改名成中文，保存。甚至连程序都不用写。

5.3 给新人的排查建议

初学者在被PFCG菜单乱码搞得焦头烂额时，最容易犯的错误有两个：一是过早改数据，二是不看语言环境。

我的建议是，拿到这类问题，先做完三件事再动数据：

1. 确认当前登录语言是什么。如果用户用的是英文系统，菜单里的英文文本显示成乱码，说明不是TSTCT问题，而是字体编码问题。
2. 确认目标系统TSTCT里该事务代码都有哪些语言记录。这一步能帮你判断是“完全没记录”还是“记录内容不对”。
3. 对照开发系统或者测试系统，看看目标系统缺的记录在源系统里是否存在。如果源系统有，那就是传输问题；如果源系统也没有，那就是事务代码本身没维护好。

这三步走完，问题的类型基本已经被锁定了。接下来再决定是走语言包修复、走传输重发、还是在SE93补短文本。

还有一个小技巧：如果你有数据库访问权限，可以用SQL直接查TSTCT。SAP GUI里SE16N虽然方便，但手工一条条看效率低。SQL查询可以一次性把某个事务代码范围在中文语言下的文本记录全部拉出来，再以Excel形式导出比对。从事SAP维护的朋友应该都有类似的经验，优先用自动化手段做数据分析，手动操作容易漏。

至于更新TSTCT，说实话我不建议直接在生产机用SE16N手改。能走传输就走传输，能走程序就走程序，手改表只适用于紧急单点修复，而且改完要记得留下变更记录。SAP系统的可追溯性是很重要的，手改表会让后续审计变得麻烦。

写到这里，PFCG菜单乱码的处理思路基本完整了。从现象到原理，从排查到修复，再到批量处理和边角案例，这些东西都是我一步步踩坑踩出来的。最后特别想强调一点：遇到“###”先稳住，它不是数据损坏，也不是权限错误，而是SAP在告诉你“文本缺失”。按着TSTCT这条线去排查，多数乱码问题都能在半小时内定义清楚。剩下的，就是选对修复方式的问题了。