写UE5 C最绕不开的就是字符串尤其是TCHAR、FString和那个让人迷惑的运算符。新手第一次看到UE_LOG(LogTemp, Warning, TEXT(%s), *MyString)时基本都会问一句这里为什么非要加星号FString不是字符串对象吗直接传进去不行吗我刚开始也这么想后来把源码翻了一遍才明白FString内部其实放着一个TCHAR字符数组而运算符就是把这个数组的首地址暴露给外界用的接口。今天这篇就把这个链路从头到尾拆一遍看完你不仅会打印还能彻底理解UE5字符体系的设计逻辑。1. 先搞清楚TCHARUE5字符串体系的基石1.1 TCHAR究竟是宏还是类型先说结论TCHAR在UE5里是“类型别名”不是函数不是一个“能存字符的宏”。很多入门教程里叫它“单字符宏”这个说法容易让人误解其实它更接近C里的typedef/using。在UE5的源码里你会看到类似这样的定义#if PLATFORM_TCHAR_IS_CHAR typedef ANSICHAR TCHAR; #else typedef WIDECHAR TCHAR; #endifANSICHAR就是charWIDECHAR就是wchar_t。当前主流的游戏开发平台上TCHAR都会被解析成wchar_t。这里有个很关键的知识点wchar_t在不同平台上占的宽度不一样。Windows上wchar_t一般是2字节也就是UTF-16编码而在Linux、Mac这些平台上wchar_t通常是4字节对应UTF-32。正因为两边宽度不同UE5才需要TCHAR这层包装来处理差异。UE5工程里最常用的FString它的每个字符元素就是TCHAR。也就是说FString和TCHAR的关系就像std::wstring和wchar_t的关系只是UE5把这层关系用TCHAR统一了起来。理解了这一点后面再看*运算符就顺理成章了FString内部就是一个TCHAR数组*运算符让你拿到这个数组的起点。1.2 为什么UE5不直接使用char有人可能会问C标准库里有std::string底层是char数组为什么不直接用问题出在char太“窄”了。char只有1字节处理ASCII没问题但放到中文、日文、韩文、Emoji这些字符面前就抓瞎。游戏行业又是国际化最重的领域一个游戏可能要出多语言版本名字、对话、道具描述全是非ASCII字符所以必须有一个宽字符体系。Windows平台给了两个选择char对应ANSI编码wchar_t对应UTF-16编码。UE5为了和Windows API自然对接也为了让FString在内存里直接喂给系统层函数就必须让默认字符类型等于wchar_t。又因为其他平台上的wchar_t宽度不一致干脆用TCHAR把这一层差异包起来。于是你在写UE5代码时养成了一个习惯只要是字符串字面量就套上TEXT()宏。比如TEXT(你好)在编译期会被当成宽字符字面量和TCHAR数组匹配。不套TEXT宏写你好就是const char[]经常在UE_LOG那里报类型不匹配或者编译通过但输出乱码。1.3 FChar与TChar的真实身份标题里提到“结构体 TChar、FChar”这里我得稍微纠正一下。UE5源码里其实并没有一个叫“TChar”的常用结构体大家日常看到的都是TCHAR这个类型别名。很多资料把TCHAR简写成TChar久了以后就被误传成“有个结构体叫TChar”。真正在源码里常见的是FChar它确实是一个结构体但它的作用不是“表示一个字符”而是“提供一组字符分类工具函数”。FChar在UE源码里大致长这样struct FChar { static const TCHAR* Spaces; static bool IsAlpha(TCHAR Char); static bool IsAlnum(TCHAR Char); static bool IsDigit(TCHAR Char); static bool IsWhitespace(TCHAR Char); static bool IsLower(TCHAR Char); static bool IsUpper(TCHAR Char); static TCHAR ToLower(TCHAR Char); static TCHAR ToUpper(TCHAR Char); };你可以把FChar理解成C语言里ctype.h那套函数的C封装。需要判断某个TCHAR是不是数字、是不是空格、转大写转小写时就用FChar::IsDigit、FChar::IsWhitespace这些静态方法。它不是“背包里的一件物品”而是“整理物品的工具箱”。记住这个区分看源码时就不会被误导。2. FString的底层TCHAR字符数组的封装2.1 源码视角下的FString内部结构直接看UE5源码FString内部核心成员其实就是一个TArrayTCHAR Data。TArray是UE自己的动态数组容器它保证元素在内存中连续排列。FString并没有额外维护一个“长度变量”和“指向堆内存的裸指针”它把这一切都交给了TArray管理。简化后的核心结构大概是class FString { private: TArrayTCHAR Data; public: const TCHAR* operator*() const { return Data.GetData(); } int32 Len() const { return Data.Num(); } };为什么这里用连续存储很关键因为不管是外部C API还是UE_LOG的格式化输出它们需要的都是一个const TCHAR*指针然后从这个指针地址开始顺着内存一格一格往后读直到遇到TCHAR(0)结束符。如果FString内部用链表存字符那*运算符就没法返回一个连续的数组首地址了。所以“FString底层是TCHAR字符数组”这句话不只是概念上的说法而是字面上的实现事实。2.2 封装带来的好处与使用约束FString把TCHAR数组包起来最大的好处是安全。你不需要手动new一个TCHAR[]不需要自己算结尾要留几位存结束符也不需要担心忘记释放内存。它提供了Append、InsertAt、RemoveAt、Replace、Left、Mid、Right这些方法全部在内部操作TArray帮你处理好扩容和缩容。但封装也带来了一个典型约束外部系统不一定认识FString对象。Windows API、一些第三方C库、甚至UE5内部老的C风格接口它们只认const TCHAR*。于是FString必须提供一种方式让外界能拿到内部数组的首地址。*运算符就是干这件事的。这就像你住在一个高档小区FString小区物业帮你管水电燃气和安保但外卖员不认物业系统他只需要你告诉他“几号楼几单元”就行。*运算符就是告诉外卖员小区入口地址的那个动作。2.3 理解字符数组与FString对象的关系很多人学到这里还会有一个小疑惑FString对象本身是在栈上或者堆里的一个对象它内部的TCHAR数组的内存又在另一处这两个东西到底谁是谁简单说FString对象里保存的是“数组的元信息”首地址、元素个数、容量真正的字符们躺在TArray管理的连续堆内存里。*MyString返回的是那堆字符内存的首地址不是FString对象自身的地址。所以你能写const TCHAR* Ptr *MyString;但不能写const TCHAR* Ptr (const TCHAR*)MyString; // 这是错的别这么干前者拿到字符数组的首元素地址后者拿的是FString对象头地址完全不是一回事。打印字符串时格式化函数会从Ptr位置开始逐字符读一直读到结束符为止。所以FString能打印、能传参本质靠的都是“内部那个TCHAR数组的连续性”。3. 解析FString的*运算符从对象到C字符串的桥梁3.1 运算符重载背后的实现逻辑运算符在C里一般用来解引用指针但FString不是指针它是个类。它能加星号是因为重载了operator*()。UE5源码里FString的operator实现非常短const TCHAR* operator*() const { return Data.GetData(); }TArray::GetData()返回数组第一个元素的指针。所以整个调用链是调用*MyString触发FString::operator*()返回Data.GetData()结果类型是const TCHAR*这个指针指向FString内部TCHAR数组的第一个字符这里还有个小细节函数是const的返回的也是const TCHAR*。这意味着你不能通过这个星号拿到可写的TCHAR指针去改字符串内容。UE5刻意把这条路径设成只读防止外部代码不经FString方法直接乱改内部缓冲区。3.2 用一段手写代码推演*运算符如果觉得源码太抽象可以自己模拟一个极简的字符串类感受一下这个模式class MySimpleString { TArrayTCHAR Buffer; public: void Append(const TCHAR* Str) { while (*Str) { Buffer.Add(*Str); Str; } Buffer.Add(0); // 结尾结束符 } const TCHAR* operator*() const { return Buffer.GetData(); } };然后这样用MySimpleString Msg; Msg.Append(TEXT(Hello UE5)); const TCHAR* P *Msg; while (*P ! 0) { UE_LOG(LogTemp, Log, TEXT(char code %d), (int32)*P); P; }这里每循环一次P往后挪一格*P取到当前TCHAR字符的数值。整个过程就是典型的“对C风格字符串做遍历”。你会发现FString提供的*运算符本质上就是让一个现代C对象能够无缝参与到这种老式字符数组遍历中。3.3 *运算符与GetData、GetCharArray的对比在FString里除了*运算符还有几个相关接口容易混淆。我整理了一张对比表接口返回值适用场景GetCharArray()const TArrayTCHAR需要遍历所有字符、需要数组容器能力时GetData()const TCHAR*和*运算符类似直接拿数组首地址operator*()const TCHAR*最常用用于格式化输出和C接口传参operator[]TCHAR按索引取单个字符如果你只是想把FString传给UE_LOG或者一个接收const TCHAR的函数用就够了。如果你需要在循环里逐个字符处理也可以先用const TCHAR* P *Str然后移动指针遍历。如果想多用一些TArray的便利方法比如按索引批量访问那GetCharArray()更顺手。不过实际开发中运算符出现频率是最高的。因为格式化参数那里几乎是固定写法尤其UE_LOG要求%s必须对应const TCHAR。我建议新手先把*运算符练成肌肉记忆再去了解其他接口。3.4 使用*运算符时的三个注意事项第一星号拿到的指针是“借用”的不是“拥有”的。它指向FString内部TArray管理的内存。原FString对象一旦析构指针立刻悬空。如果是临时对象比如*FString::Printf(...)这种写法用完就结束别把指针存下来长期使用。第二FString内部数组发生扩容后原来的指针会失效。比如你先拿了const TCHAR* P *Str接着对Str执行Append把字符串加长TArray可能重新分配内存老地址就废了。这种“先取指针再改字符串”的顺序属于典型的使用错误。第三不要试图通过const TCHAR*去修改字符内容。你会收到编译错误或者如果自行强转去掉const容易破坏FString内部的长度一致性和结束符约定。真要修改字符请用FString自带方法或者使用非常量版本接口。注意拿到const TCHAR*后如果这个指针来自一个临时FString千万不要保存它。临时对象在语句结束时就析构了指针指向的内存可能立即被回收后面再访问完全是未定义行为。4. 实操在UE5工程里完成基础数据类型打印4.1 搭建一个最小测试工程动手验证是最好的学习方式。流程很简单用UE5编辑器新建一个C工程选Basic Code模板等待生成完项目后右键.uproject文件选择Generate Visual Studio project files然后用VS打开。在项目中新建一个Actor类我习惯叫它CharPrintActor。头文件里只需要声明一个BeginPlay重载#pragma once #include CoreMinimal.h #include GameFramework/Actor.h #include CharPrintActor.generated.h UCLASS() class ACharPrintActor : public AActor { GENERATED_BODY() public: virtual void BeginPlay() override; };为什么在BeginPlay里做测试因为它是运行时最早执行的逻辑之一控制台能看到UE_LOG输出不需要额外搭UI最适合做字符打印实验。把下面几小节的代码都塞进BeginPlay里编译运行后看Output Log就行。4.2 打印TCHAR的大小、字符与编码先把字符类型的基本信息打出来void ACharPrintActor::BeginPlay() { Super::BeginPlay(); UE_LOG(LogTemp, Warning, TEXT(sizeof(char) %d), (int32)sizeof(char)); UE_LOG(LogTemp, Warning, TEXT(sizeof(TCHAR) %d), (int32)sizeof(TCHAR)); UE_LOG(LogTemp, Warning, TEXT(sizeof(wchar_t) %d), (int32)sizeof(wchar_t)); TCHAR MyChar TEXT(A); UE_LOG(LogTemp, Warning, TEXT(MyChar %c), MyChar); UE_LOG(LogTemp, Warning, TEXT(MyChar code %d), (int32)MyChar); }如果你的项目跑在Windows平台输出大概是sizeof(char) 1、sizeof(TCHAR) 2、sizeof(wchar_t) 2。这个结果说明TCHAR在这里就是2字节宽字符。如果项目跑在Linux或Macsizeof(TCHAR)很可能是4。同一套代码不同平台字符宽度不同这正是TCHAR屏蔽差异带来的现象。打印单个TCHAR时格式化符号用%c如果想看字符的编码值就强转成int32用%d打印。这里有个小经验TCHAR在2字节平台上可能带符号也可能不带最好先转成int32再打印避免编译器在符号扩展上给出不同结果。4.3 FString和TCHAR数组相互转换的完整示例接下来看FString和TCHAR数组怎么互相转换FString MyStr TEXT(Hello UE5); // 从FString拿const TCHAR* const TCHAR* Ptr *MyStr; // 拷贝到本地TCHAR数组 TCHAR Buffer[128]; FCString::Strcpy(Buffer, 128, Ptr); // 打印数组内容 UE_LOG(LogTemp, Warning, TEXT(Buffer %s), Buffer); // 从TCHAR数组构造FString TCHAR FixedBuffer[] TEXT(World); FString AnotherStr FixedBuffer; UE_LOG(LogTemp, Warning, TEXT(AnotherStr %s), *AnotherStr);FCString是UE里专门处理TCHAR字符串的静态函数库类似C语言的string.h。FCString::Strcpy接受目标缓冲区和源字符串指针正好我们手上有*MyStr直接传进去就行。这体现了“字符数组”和“FString”在UE开发中不是对立关系而是经常互相配合FString负责安全存储TCHAR数组负责和底层函数打交道。这里必须注意拷贝时给缓冲区留够空间。如果字符串很长用FCString::Strcpy就有溢出风险。稳妥做法是先FCString::Strlen(Ptr)算出字符数再决定缓冲区大小或者直接用FString的中间态来转换。4.4 用Printf把字符串、整数、浮点拼在一起输出实际开发里更多情况是把多种数据拼成一条日志。看这个例子int32 HP 100; float Ratio 0.75f; FString PlayerName TEXT(Alice); FString Msg FString::Printf( TEXT(Player%s HP%d Ratio%.2f), *PlayerName, HP, Ratio ); UE_LOG(LogTemp, Warning, TEXT(%s), *Msg);输出结果是PlayerAlice HP100 Ratio0.75。这里有两层运算符第一层FString::Printf返回一个临时FString对象第二层传给UE_LOG时还要用*Msg把它解引用成const TCHAR。如果你对临时对象不放心也可以先把它存到命名变量里再传*变量这样代码更容易读。格式符这块UE5的规则和C语言的printf接近但有几个坑%s对应const TCHAR*不是std::string更不是FString%d对应int32%f对应float/double%.2f表示保留两位小数。务必把类型和格式符匹配好否则输出会错得非常离谱而且编译期不一定能抓出来。5. 常见问题与排查技巧实录5.1 编译报错FString无法转成const TCHAR*这是新手最高频的报错之一。代码写成这样UE_LOG(LogTemp, Warning, TEXT(%s), MyString);编译器直接报cannot convert argument from FString to const TCHAR *。原因就是我们前面分析的UE_LOG的%s需要的是const TCHAR*FString本身是一个类对象编译器不会自动帮你转换成指针。解决办法就一个加*。写成*MyString。这个错误本质上不是一个“语法错误”而是“类型模型错误”。理解了*运算符的作用后你会觉得这个报错非常合理FString是“字符串对象”而格式化系统要的是“字符数组地址”两者需要一个显式转换。还有一类类似报错发生在自己写的接口上。比如定义一个函数void PrintMyString(const FString InStr) { UE_LOG(LogTemp, Warning, TEXT(Str %s), InStr); // 报错 }这里同样要给InStr加*。很多人一开始只觉得奇怪“为什么教程里都加星号”其实就是因为UE_LOG内部用C风格的可变参数必须传const TCHAR*。5.2 中文乱码几乎都和TEXT()有关打印中文时乱码概率极高。常见写法UE_LOG(LogTemp, Warning, TEXT(%s), *FString(中文));这里FString的构造函数接收的是const char*它会把UTF-8的“中文”字符串转成TCHAR数组。如果源文件保存编码和编译器预期不一致转出来就是乱码。更稳妥的做法是用TEXT()宏把字面量在编译期就转成宽字符UE_LOG(LogTemp, Warning, TEXT(%s), TEXT(中文));写FString(中文)这类代码本质是在“让FString的构造函数帮你转码”。如果项目源文件是UTF-8编译器和MSVC对UTF-8的处理历史上有过不少坑很容易出现“源码看着对输出全乱码”的情况。用TEXT()宏能从源头上规避这一层。我的经验是UE5 C里所有字符串字面量不管英文中文一律套TEXT()。这个习惯养成后乱码问题至少减少一半。剩下的乱码场景大概率发生在“从文件/网络/第三方库读入非UTF-8文本”时那就要用专门的编码转换工具不是字面量问题了。5.3 跨平台下的字符宽度差异前面说过Windows上TCHAR是2字节Linux和Mac上可能是4字节。这带来一个很实际的坑如果你把FString里的内存通过二进制协议发给服务端在Windows上发的是2字节一个字符的数据在Linux上发的是4字节一个字符的数据服务端解析规则就得写两套。更安全的做法是在网络传输和文件存储层面统一用UTF-8。UE5提供了FTCHARToUTF8和FUTF8ToTCHAR两个转换器用法很直接FString LocalStr TEXT(跨平台文本); FTCHARToUTF8 Converter(*LocalStr); const char* Utf8Str Converter.Get();在这个方向做转换时得到的是普通char数组可以安全写入文件或发送网络。反过来接收时用FUTF8ToTCHAR把UTF-8转回FString。这个习惯能避开大量跨平台编码坑算是我个人强烈推荐的一个实践。如果是临时打印直接用UE_LOG就够了。但一旦涉及到存档、联网、数据库请务必显式转成UTF-8不要直接裸传FString的底层内存。5.4 常用字符转换操作速查表有些操作太常用了直接做成速查表方便后面写代码时翻操作需求推荐写法UE_LOG打印FStringUE_LOG(LogTemp, Warning, TEXT(%s), *MyStr);打印单个TCHARUE_LOG(LogTemp, Warning, TEXT(%c), MyChar);FString转const TCHAR*const TCHAR* Ptr *MyStr;FString拷贝到TCHAR数组TCHAR Buf[128]; FCString::Strcpy(Buf, 128, *MyStr);从TCHAR数组构造FStringFString NewStr SomeTCharArray;FString转UTF-8FTCHARToUTF8 Conv(*MyStr); const char* Out Conv.Get();遍历FString字符for (const TCHAR Ch : MyStr) { ... }快速取字符数int32 Count MyStr.Len();保存这份表日常写字符串相关代码基本不怎么需要查文档。等你用熟了你会发现这些操作背后都是同一件事搞懂TCHAR数组的内存布局以及FString如何把它的内部数组暴露出来。6. 写在最后一点个人经验我自己刚学UE5 C时也被*FString搞得一头雾水。最开始的几周我纯粹是“教程写就跟着写”完全没想过它到底解了什么引用。后来有一次自己封装一个底层日志模块需要把FString传给一个C接口死活编译不过才痛下决心把源码翻出来看。看到return Data.GetData()那一行时整个人一下子踏实了。这段经历给我最大的启发是UE5的很多“神奇语法”背后都是非常朴实的C工程决策。FString用TCHAR数组做底层是为了兼容系统API和格式化输出*运算符返回数组首地址是为了让对象和C风格接口共存TCHAR做类型包装是为了跨平台不炸。搞懂这些设计动机之后你写代码就不只是“照着写”而是能判断“为什么这么写”了。如果你现在还在被各种字符类型绕晕我给的建议很简单先强制自己所有字符串都用FString TEXT() *这套组合把最常见的链路跑通再慢慢研究FChar、FTCHARToUTF8这些进阶工具。这条路我自己走过确实是最省力的入门方式。后面等你有余力了不妨试试自己写一个基于TCHAR的小字符串工具类对这套机制的理解会更深。