KR引擎更改编码显示异常
qtlark opened this issue · comments
概要
游戏名：ひこうき雲の向こう側
参考视频：https://www.bilibili.com/video/BV1m64y187df
实现目标：不转区运行本体EXE
流程
-
直接打开原版EXE，显示找不到某某文件的后缀名
-
提取data.xp3，将所有asd, func, tjs, ks, txt, ini, csv (以及stage, stand特有文件后缀)的编码从shift-js转到utf16 LE有签名，并且在Config.tjs里挂载了路径，在Override.tjs里挂载了CSV插件。最后打包成patch.xp3。
-
运行游戏，正常无报错。台词，人名，语音，BGM，背景图片等等显示正常，但立绘还是显示不出来。但此时转区运行正常。
想法
之前反应的黑框问题是乌龙，是忘挂载路径了。但挂载路径后，就出现了上述的③问题，就是黑框都没了，一片透明。个人感觉是加载到了TLG图片，但是显示不了？不懂，迷惑。
这个游戏封包里非常多文件使用了日文的文件名，一般这种建议直接走forcedataxp3的方法，因为path.xp3并不能很好的替换，当然想一点点把路径修好也是可以的，只是很麻烦。
目前来说你有两个选择
删除立绘控制txt
- 1、所有操作和你上述一样
- 2、把fgimage文件夹下各个人物名文件夹内的txt从patch里删除，比如 fgimage\いろは１\いろは１.txt，这些文件不要放入patch，其它操作一样，就可以正常显示立绘了
关闭forcedataxp3
关闭forcedataxp3，并修改exe中data.xp3字段成其它，比如date.xp3，使得引擎可以从游戏目录下的data文件夹优先加载文件
由于这个游戏data.xp3很大，所以还需要在data/startup.tjs中添加路径把一些资源的读取重新定向到封包中
谢谢大佬，已通过第一种方式解决！
但还是有点疑惑，这种相当于不对立绘txt转码，仍然是shift-js，按道理来说应该无法正常识别，为什么这样反而可以正常工作？
理论上来说无论什么编码，最终都是一串二进制序列，只要没对编码过的数据进行转换，就可以匹配到相应的文件，顶多只是显示出来的内容有问题，内部运行一般是不会有问题的。
然而比较糟糕的是Windows下通常不认为字符串是二进制序列，当然用户程序内部是可以无视编码的，只要你自己不去操作转换字符串（当然实际上很难做到，因为很多库函数也要和系统api交互，不可避免的涉及到编码转换，比如fopen，内部其是调用系统api CreateFile，但fopen的文件名参数是const char*，窄字节编码，那内部必须转换成wchar_t，那你这个const char*是什么编码呢？utf8？sjis？gbk？没人知道，系统直接假设日文语言区域就sjis，中文语言区域就gbk），但和系统api交互还是要考虑编码问题，不过一般非跨平台的Windows程序，特别是老的在用窄字节编码的Windows程序都很难做到这一点，所以一旦编码假设错，轻则乱码，重则直接崩溃。
不过这种情况只发生在调用窄字节api的程序上，也就是后缀是A的winapi函数，显然Windows至少20多年以前就提供了W系宽字符的api，而且其后的A系api也只不过是在内部转换成宽字节后调用W系的API。那些转区软件，本质上就是hook这些A系列的api，然后在内部使用用户设置的编码来进行转换，再调用W系的api，这样就解决了编码被假设错的问题。
但立本人跟不上时代，还在用窄字节的玩意写程序（当然这和Windows也有关系，没有全面推行宽字节编码，现在的vs都还是默认保存窄字节编码源文件），窄字节在Windows上通常会为字符串假定一个编码（对的只是假设，这些玩意统称为DBCS编码，没有任何标识数据来表示编码类型，这种假设编码的行为一部分可以由程序员决定，但系统的A系api，直接假设了编码依据系统语言决定，这就导致了大量使用sjis编码的程序在中文系统下被假设成gbk编码，如果假设的编码是错误的，那么转换出来的宽字符编码（utf16）的字符串也是有问题的，有可能少字符有可能全是问号，比如一个文件名，输入是sjis编码是但以gbk来转换，转换到utf16后，就完全是乱码的状态了，基本不可能通过这个文件名找到对应的文件（当然如果刚好能映射回去，也是可以能的）。
反正这东西就这样的，编码混乱，替换混乱，有些插件还不支持某些编码
所以最好是forcedataxp3从最顶级的data目录来替换文件，让所有编码都统一成utf16，就没这个问题了（当然有些傻x的插件没做utf16的bom检查和支持除外）
感谢大佬解释Orz