企业官网建设流程全解析

最近在权限顾问的群里，又看到有人贴了一张PFCG菜单乱码的截图，底下好几个刚入行的朋友跟着问：是不是权限配错了？是不是角色数据坏了？要不要重启服务器？我一看那截图，心里差不多就有数了——这种情况十有八九不是权限问题，而是语言和文本显示的事。PFCG作为SAP ECC里维护权限角色的核心事务码，菜单一旦乱码，确实会让人心里一紧，但它通常不影响权限校验，只是菜单这块“门面”出了问题。这篇文章把这几年排查PFCG菜单乱码的经验整理一遍，从现象定位到根源分析，再给出一套可以照着做的排查清单，最后复盘几个真实场景。不管你是刚接触SAP中PFCG的使用，还是已经扛了几年的权限顾问，这篇应该都能帮上忙。

1. 先搞清楚乱码到底“乱”在哪：现象与定位

1.1 PFCG菜单乱码的几种典型表现

PFCG是权限角色维护的入口，SAP中PFCG的使用场景很集中：创建角色、配置权限、给用户分配角色，同时维护角色菜单。最终用户登录SAP Easy Access后看到的菜单树，很多就是从角色菜单带出来的。所以PFCG菜单乱码的直接受害者是终端用户——菜单上写的是什么他们看不懂，自然不知道该点哪里，业务操作也受影响。

乱码的表现其实不止一种，我总结下来大概有四类：

• 菜单项显示成“口口口”或者带问号的方块。这多半是字体或字符集不匹配，数据库里存的是中文，但当前客户端的编码环境认不出来。
• 菜单项中英文混杂，甚至出现德文、法文。这种情况在回退机制里很常见，系统在指定语言下找不到文本，就自动退回基准语言。
• 菜单项直接显示成技术名称，比如PFCG、SE38、FBL3N这样的格式。这说明事务码文本表里对应语言的描述缺失，SAP只能暴露技术名。
• 同一个角色，在不同的电脑上登录，菜单显示结果不一样。这就是典型的客户端显示层差异，得从GUI设置上去找原因。

理解这些现象的区别很重要。在PFCG里，乱码通常不是权限数据损坏，而是“文本层”出了问题。我经常打一个比方：一栋楼的门牌号码贴错了，但房子的结构还好端端的。菜单乱码不等于权限坏了，也不代表角色彻底废了，很多时候只是文本没显示对。

1.2 先分清楚是显示问题还是数据问题

这是排查的第一步，也是最重要的一步。接到这种报障，我不会第一时间去翻角色配置，而是先问自己：这个乱码是显示层的问题，还是数据层的问题？

显示层的问题，特征很鲜明：同一个人配的菜单，在A电脑上正常，在B电脑上乱码；或者中文登录乱码，英文登录就正常。这种情况通常出在SAP GUI的字体、操作系统的区域语言设置、GUI的字符集配置上。数据层的问题，特征则是：所有人、所有电脑看起来都乱码，而且换语言也没用。这种情况要往服务器端查，比如语言包缺组件、文本表存储异常、代码页设置不对。

怎么判断？三个动作：

• 换一台电脑，登录同一个用户，看看菜单是否还乱码。
• 在同一台电脑上改用英文登录，看乱码是否消失。
• 用SE16N直接打开菜单文本对应的表，肉眼确认数据库里的数据到底长什么样。

这三招基本能砍掉90%的错误方向。如果换电脑就正常，那是客户端问题，别去服务器上折腾；如果所有电脑都乱码、换英文却正常，那就去查中文语言包和字体。这个判断逻辑听起来很简单，但很多人一上来就被“乱码”两个字带偏，直接去检查权限对象、角色配置文件，绕了一大圈才发现跟权限半毛钱关系没有。

2. 乱码的根源：语言、代码页与文本存储机制

2.1 语言链：一个文本从录入到显示要过五关

在SAP系统里，一条菜单文本能不能正确显示，不是简单“存了中文就能显示中文”的事，它要经过一整条语言链路的过滤。我把这条链路总结成五个关卡：

第一个关卡是系统参数zcsa/system_language。这是SAP系统的基准语言，在安装时就定了，国内很多ECC系统是EN（英文）或DE（德文）。第二个关卡是客户端默认语言，每个Client在SCC4里有一个默认语言，用户登录时如果SAP GUI没有明确指定语言，系统就拿这个当默认。第三个关卡是登录语言，也就是用户启动SAP GUI时在登录界面填的语言代码，填ZH就是中文，填EN就是英文。第四个关卡是用户主数据里的默认语言，SU01里可以维护，很多文本解析的优先级会参考这个设置。第五个关卡是对象文本自身的语言键，TSTCT、AGR_TEXTS这些文本表里，每条记录都有一个语言字段，比如这条文本是ZH还是EN。

SAP显示文本时有一个回退机制：如果当前语言下找不到文本，就回到基准语言去找；再找不到，就显示技术名称或者干脆空白。很多“菜单乱码”的本质，其实是这条回退链出了问题。

举个例子：用户用中文登录，但某个事务码在TSTCT表里的ZH语言行缺失，只有EN文本。系统找不到中文描述，就会回退到英文。如果英文文本也没装，那就直接显示成技术名称。生活里有个类似的场景：你点了一份中文菜单，后厨做菜的师傅只认识法文菜谱，端上来就只能给你一份法文菜名，有时候连菜名都没有，直接给你看编号。

2.2 代码页：Unicode与非Unicode的中文菜单

除了语言键，代码页是另一个常见的大坑。SAP里的代码页决定了系统怎么把字符编码成字节，你可以把它理解成系统内部的“语言编码规则”。

非Unicode系统对中文的支持比较敏感。中文通常依赖代码页4102或者4103，如果系统代码页设置不对，比如用的是1100（Latin-1），那中文文本存进去的时候就可能乱掉。这类问题一旦发生，往往不是单个菜单乱码，而是整个系统的中文文本都异常，涉及面很大。

Unicode系统则好一些，整个系统统一用UTF-8编码，中文的存储和显示都有基本保障，乱码问题少很多。但Unicode系统也有坑，如果SAP GUI所在的操作系统区域语言设置不对，或者GUI的字符集配置异常，一样会显示乱码。

代码页出错的典型特征是：你用SE16N看表数据是正常的，但界面显示是乱码。或者同一个角色在一个电脑上乱码、在另一个电脑上正常。这是因为数据库里的字节本身没错，而是客户端在“解码”时选错了规则。就好比你用微信发了一条中文消息，对方的手机系统语言设置成英文，且字体不支持中文，看到的自然是一堆乱码——问题不在服务器，而在手机。

2.3 菜单文本藏在哪：TSTCT与AGR_TEXTS

PFCG菜单文本的来源，主要在两张表上。

一张是TSTCT，事务代码文本表。关键字段包括MANDT（集团）、SPRAS（语言键）、TCODE（事务代码）、TTEXT（事务代码描述）。比如PFCG这个事务码，在ZH语言下的文本是“创建角色”，在EN语言下是“Role Maintenance”。这张表相当于SAP事务码的“字典”，PFCG生成菜单时，很多文本是从这里读取的。

另一张是AGR_TEXTS，角色文本表。它在PFCG保存角色时生成，存储角色各种对象的文本，包括菜单节点的描述。关键字段有MANDT、LANGU、PROFILE（角色配置文件）、OBJECT（对象名）、TEXT（文本内容）。这张表存的就是角色实际保存下来的菜单文本。

SAP中PFCG的使用流程通常是：建角色、在菜单页添加事务码/报表/Web地址、保存角色。保存时SAP会把事务码的描述“冻结”到角色菜单里。所以角色菜单一旦生成，显示文本不会实时跟着事务码文本表变化，必须重新生成菜单才能刷新。这是很多踩坑现场的核心原因。

提示：角色菜单文本一旦在AGR_TEXTS里确定，后续即使TSTCT表的描述改了，角色菜单也不会自动更新。这就是为什么改完事务码描述后，很多角色还要到PFCG里重新生成一遍菜单。

3. 实操排查清单：从现象到处理

3.1 第1步：缩小范围，判断影响面

接到菜单乱码的报障，别急着上手改配置，先花两分钟收集信息。我一般会问这么几个问题：

• 是所有用户乱码，还是个别用户？
• 是所有电脑乱码，还是一台电脑？
• 换英文登录是否还乱码？
• 是刚上线的系统，还是已经跑了很多年的系统？
• 角色是从其他系统传输过来的，还是本地新建的？

这些问题能帮你快速把问题定位到“客户端”或“服务器”的某一侧。我碰到过一种很坑的情况：用户说菜单乱码，结果只是他把SAP GUI的显示语言从中文切到日文又切回来，字体缓存错乱，重启一次就好。这种情况如果在服务器上折腾半天，纯属浪费时间。

排查时顺便看一眼系统状态，用菜单“系统 → 状态”，里面可以看到系统版本、语言、字符集等信息，记录下来备用。做这些事看起来不起眼，但能省下后面大量的无用功。

3.2 第2步：检查用户默认语言与登录语言

如果影响面比较广，先把用户主数据和登录语言捋一遍。操作路径：

• 事务码SU01，输入用户名，双击“登录数据”，查看“登录语言”字段。
• 检查日常登录时SAP GUI界面上填写的语言代码。
• 用SCC4查看当前客户端的默认语言。

如果用户的默认语言设的是JP（日文）或者别的语言，而系统并没有安装对应的语言包，文本显示就可能出问题：有的是乱码，有的是回退到英文，有的是直接显示技术名称。最典型的场景是，用户电脑里SAP GUI语言早先被改成EN，后来有人改了界面字体，结果中文菜单全成了方块。

正确做法是让用户主数据语言、GUI登录语言与系统安装的语言包保持一致。国内环境一般统一成ZH（中文），很少有用英文做日常登录的。改完SU01用户默认语言后，记得让用户重新登录测试，这一步操作简单，但能解决一大部分基础性乱码。

3.3 第3步：检查语言包和系统参数

如果统一语言后依然乱码，就要去服务器端查语言包和系统参数了。主要用两个事务码：

• SMLT：语言维护，查看系统已安装的语言组件。重点看ZH的状态是否正常、是否完整。
• RZ10：实例参数维护，查看参数zcsa/system_language的当前值，确认基准语言是什么。

还要注意：不是“装了中文语言包”就万事大吉，语言包分基础组件和可选翻译组件。有些实施方图省事，只装了部分组件，结果系统登录界面是中文，但角色菜单生成时缺少中文翻译文本，菜单项就悄悄回退成了基准语言。

这里有个容易忽略的细节：SMLT里的语言状态有“完全安装”“部分安装”“未安装”的区别。如果ZH显示已经安装，但点进去看某些组件状态异常，那依然会引发菜单乱码。所以判断标准不是“有没有装中文”，而是“中文组件是不是全的”。

3.4 第4步：直接查文本表，确认数据层是否正常

这一步是决定性的，因为它是从“现象”走向“证据”的关键。用SE16N或SE16打开表，依次查看。

先查TSTCT。输入一个乱码的事务码，比如PFCG，查询后看SPRAS和TTEXT字段。正常情况下应该有ZH行和EN行，文本内容清晰可读。如果看到ZH行本身是乱码，说明系统语言包或文本表有问题。如果ZH行不存在，只有EN或DE行，说明中文文本缺失，SAP在回退。

再查AGR_TEXTS。输入角色名称，按语言查看菜单文本，对比角色下各个对象的文本是否存在、内容是否正常。如果TSTCT正常，但AGR_TEXTS里的角色菜单文本是乱码或缺失，说明角色保存时“冻结”的文本不对，需要在PFCG里重新生成菜单。

这里给出两张表的关键字段说明，方便你查询时对照：

3.5 第5步：PFCG菜单重新生成与修复

如果确认是AGR_TEXTS里的菜单文本不对，解决办法是让PFCG重新读一遍事务码文本表，刷新菜单。操作步骤：

• 打开PFCG，输入角色名，进入角色维护界面。
• 切到“菜单”页签，展开或刷新菜单树。
• 使用菜单路径或工具栏上的“生成菜单”按钮，确认语言范围后执行。
• 保存角色，重新分配或同步用户，然后让用户重新登录测试。

如果TSTCT本身有问题，处理起来会麻烦一些。原则是：生产环境别直接改表。应该通过语言包补充导入的方式来处理，比如在SMLT里执行语言补充安装；或者走传输请求，把开发环境里正确的文本带到生产环境。直接改表在测试系统还能接受，生产系统这么干，后患无穷。

注意：很多人担心“菜单乱码会不会影响权限生效”。我可以负责任地说，菜单乱码基本不影响权限对象的校验。权限是否生效取决于角色里的授权配置，跟菜单显示是两码事。菜单只是一扇门，门上的牌子歪了不影响你刷卡进门。

4. 实战复盘：我遇到过的三类菜单乱码

4.1 复盘一：只有一台电脑乱码，问题在SAP GUI字符集

一次典型的“幽灵报障”。角色是新配的，权限配置没问题，数据检查也正常，但某个业务部门的主管登录进去，菜单一片“口口口”。其他同事用同一个角色登录，一切正常。

我远程看了下他的电脑，发现是两个原因叠加：一是操作系统的“区域和语言”里，非Unicode程序语言被设置成了别的语言；二是SAP GUI的字体被设置成了日文字体，中文字符没法正常渲染。

处理方法是：控制面板 → 区域和语言 → 管理 → 更改系统区域设置，改成“中文（简体，中国）”，重启电脑。同时把SAP GUI的显示字体改成中文字体，比如宋体或微软雅黑。重启客户端后，菜单恢复正常，前后花了不到半小时。

这个案例告诉我们，显示层的问题往往被过度高估。遇到单点乱码，先看电脑，别急着查服务器。很多人一看到乱码就怀疑系统坏了，其实是自己电脑的编码环境出了问题。

4.2 复盘二：新部署系统，中文语言包不完整导致菜单中英混杂

另一种常见情况在新上线项目中特别典型。某个ECC系统刚接手，登录后界面大部分是中文，但某些菜单节点显示英文甚至德文。用户以为系统出问题了，实际上系统的中文语言包装得不完整。

排查时先查SMLT，发现ZH语言包状态是“已安装”，但点进去看，部分组件状态异常。再用SE16N查TSTCT，发现一批常用事务码在ZH语言下根本没有文本记录，只有DE和EN。由于系统的基准语言是德文，文本回退时就直接回到了德文，所以很多菜单看起来就是“乱码”。

处理方式是：在SMLT里对ZH执行继续安装、补充导入缺失的语言组件，然后再去PFCG重新生成受影响角色的菜单。整套流程走完，菜单文本恢复正常。

这个案例给了一个重要提醒：评估一个ECC系统的本地化程度，不能只看登录界面是不是中文，语言包的子组件、翻译组件都要完整。否则平时不显眼，一旦生成角色菜单，漏的文本全暴露出来了。

4.3 复盘三：跨系统传输后角色菜单乱码

第三种场景也很常见：开发环境改角色、传输入口到测试或生产环境，然后生产环境菜单乱码。

这里要理解SAP的角色传输对象是带语言键的。如果开发系统是中文环境，生成的AGR_TEXTS里主要是ZH文本；传到生产环境时，如果生产环境缺少中文语言包，或者传输请求没有包含完整文本对象，就会出现“部分菜单乱码、部分菜单空白”的情况。

处理步骤一般是：

• 登录生产环境，用SE16N查AGR_TEXTS，对比角色的文本语言。
• 检查生产环境的SMLT语言包，补装对应语言组件。
• 在PFCG中重新生成菜单，必要时手动调整文本，再重新传输。

日常预防的重点在于：传输角色前，先确认目标系统的语言环境和角色菜单文本的语言范围；传输后安排一次菜单文本的回归检查，别等用户来报障。跨系统乱码的问题，多数都是“语言环境不一致”造成的，提前核对能省很多事。

5. 常见问题速查表与日常预防心得

5.1 快速排查对照表

做成一张速查表，方便你遇到问题时直接对照：

这张表不用背，放在手边，遇到问题直接对照着查就行。排查顺序记住一个原则：先客户端后服务器，先单点后全局，先显示后数据。

5.2 日常预防与操作习惯

前面讲了很多“怎么修”，其实更值钱的是别让它坏。整理几个我日常坚持的习惯：

• 用户默认语言统一规范。新用户创建时，默认语言一律设置为ZH，避免登录语言五花八门。
• 上线前全面检查语言包。新系统上线或新语言包导入后，用SMLT确认语言组件完整，别只看登录界面。
• 角色菜单生成时保持语言一致。从PFCG生成菜单时，尽量与系统主要用户的登录语言保持一致；需要多语言支持时，确认生成时选择了正确的语言范围。
• 传输角色前核对目标系统语言环境。开发、测试、生产系统的语言配比要做到心中有数。
• 禁止直接修改TSTCT和AGR_TEXTS表。测试系统改改还可以，生产系统优先走语言包或传输流程。
• 定期做菜单文本巡检。用SE16N抽查几个核心角色的AGR_TEXTS，看是否存在语言缺失或文本异常。

这几条习惯里，最容易被忽略的是“角色菜单生成时保持语言一致”。因为角色菜单在保存瞬间会固化文本，如果生成时后台语言或操作界面语言不对，后续就会带着错误的文本跑很久，用户每次登录看到的都是乱码。

再分享一个小经验。接到菜单乱码报障时，我习惯先问用户三句话：只有你乱还是所有人都乱？换英文登录乱不乱？换一台电脑乱不乱？这三句问完，方向基本就明确了，剩下的就是按文章里的清单一步步查。

最后再送一个小技巧。如果只是想快速验证是不是文本表问题，可以用SE16N打开TSTCT，手动输入一个乱码事务码，看看它的TTEXT字段在不同语言下是什么样子。这个动作花不了两分钟，但能帮你少走很多弯路。菜单乱码这个事，看着吓人，其实只要理清了语言链和数据存储机制，排查起来并不复杂。希望这篇文章能让你下次遇到它的时候，心里多一分底气。