Hex-Dragon
崩溃报告中的启动器日志有概率乱码
检查项
- [X] 我已在 Issues 页面 和 常见&难检反馈及问题列表 中搜索，确认了这一 Bug 未被提交过。
描述
打开游戏崩溃后的启动器日志乱码， pcl文件夹下的日志没有乱码
重现步骤
似乎是游戏崩溃后有概率出现
日志与附件
PCL 启动器日志.txt
Log1.txt
错误报告-2024-9-7_16.56.57.zip
@LTCatt VSCode部分乱码原因找到了
用WinHex检查了一遍乱码文件，蒙了
文件很显然是用UTF-8编码的，编码头也没问题
然后检查了一下文件编码和VSCode里部分显示异常的关联：
对应了一下正常日志文件，发现第六行处的一个乱码其实是个全角冒号：
我专门在一个空白文件里用UTF-8编码打了一个全角冒号，和故障文件一对比：
EF BC 9A变成了EF BC 3F
我又根据正常文件对比了多个乱码点：
确定所有乱码文字的末两个字符全部变成了3F
而且我这里文件用记事本UTF-8打开后乱码点位与VSCode中保持一致：
我还留意了一下乱码点位的位置，发现它们多位于“加载”二字后，也有很多为全角冒号：
好了，本人初三，能力到此为止！
乱码文件打开时用的是ANSI，PCL2日志正常用的是UTF-8，不知道是哪里出了问题，上面的截屏已经截到了格式信息
至少我这里是这样
检查过了，故障文件用的UTF-8编码头和同样内容的ANSI(GBK)编码头一模一样，可能是Windows自带记事本将其误认为ANSI编码文件了
@wuxiangzhicao @LTCatt author给的乱码游戏崩溃输出文件里：所有中文乱码字符似乎都变成了EF BF BD，这玩意在ANSI(GBK)编码里对应的本来就是“锟斤拷”。
查了一下，用UTF-8编码保存文件时，连续两个“�”（也就是乱码替换符号）会被编码为0xEFBF BDEF BFBD，对应ANSI(GBK)里的“锟斤拷”。
所以有可能————这份乱码文件被使用UTF-8编码重新保存过（PCL2自己处理，或者author重新保存，或者压缩工具搞过，或者github上传干的），而真正的原始文件乱码要么还是“EF BF BD”，要么就是其他乱码情况。
我目前需要知道“EF BF BD”是否为文件原始乱码情况…………
我这里看也是EF BF BD
我还发现一个，当你在游戏崩溃后直接点查看日志时的mc日志中文部分没有乱码，而pcl2导出的错误报告中的mc日志的中文就乱码了(也就是EF BF BD)
错误报告-2024-10-19_17.29.11.zip