网站开发策划案wordpress做音乐网插件吗
2026/1/11 13:51:52 网站建设 项目流程
网站开发策划案,wordpress做音乐网插件吗,个人网页设计作品 布局,广西住房城乡建设领域三新技术网之前在用 Kotlin/Native 写 codex-kkp 的时候遇到了一个问题#xff1a; 当我尝试在 Windows 的命令行上向它的产物 exe 传递参数的时候#xff0c;传入的中文参数会变成我们熟悉又陌生的乱码“锟斤拷”。 codex-kkp-cli.exe 分析代码 # 实际收到的参数变成了乱…之前在用 Kotlin/Native 写 codex-kkp 的时候遇到了一个问题当我尝试在 Windows 的命令行上向它的产物 exe 传递参数的时候传入的中文参数会变成我们熟悉又陌生的乱码“锟斤拷”。codex-kkp-cli.exe分析代码# 实际收到的参数变成了乱码问题分析那么为什么会这样呢众所周知“锟斤拷”系列的乱码通常是 GBK 和 UTF-8 之间的错误转码导致的。而又众所周知Windows 存在两套字符APIGBK 是 Windows 默认的中文系统编码(A 版本, ANSI)UTF-16 则是内核的原生编码(W 版本, 宽、Unicode)。参考文档Windows API 中的 Unicode代码页而 Kotlin/Native mingwX64 平台 的 main 函数编译后会使用 ANSI 版本的API的入口点launcher.cpp#L72-L78中的Konan_main函数extern C RUNTIME_EXPORT int Konan_main(int argc, const char** argv) { return Init_and_run_start(argc, argv, 1); }和 StubIrDriver.kt#L225-L232里面生成的 main 函数out(extern int Konan_main(int argc, char** argv);) out() out(__attribute__((__used__))) out(int $entryPoint(int argc, char** argv) {) out( return Konan_main(argc, argv);) out(})也就是:extern int Konan_main(int argc, char** argv); int main(int argc, char** argv) { return Konan_main(argc, argv); }它没有使用wmain或wchar_t** argv所以它使用的是 ANSI 的 API 而不是 Unicode 的那个。这个问题在 YouTrack 上也有相关记载KT-82801: Kotlin/Native: Windows Non-ASCII command-line arguments garbled charactersKT-80201: K/N: Windows main(args) receives corrupted Unicode arguments在 KT-80201 中也有热心网友贴出了解决方案这也是接下来要进行介绍的内容。解决方案如果你比较熟悉 Windows 的 API那么应该很快就能想到该如何了解。但是我就不一样了我对这类 native 相关的东西一窍不通OK 言归正传由于 Kotlin 的main函数接收到的args已经是处于乱码状态的错误参数因此我们不能直接使用这个args了而是要用 Windows 的 W 版本 API 来直接获取通过 UTF-16 编码的正确参数以此绕过 ANSI 的入口点带来的错误结果。那么怎么绕开呢说难也不难我们可以直接通过platform.windows.GetCommandLineW()来获取 UTF-16 的命令行参数。完整代码参考如下fun getUnicodeArgs(): ArrayString memScoped { // 获取原始的 UTF-16 命令行 val commandLine GetCommandLineW() ?: returnmemScoped emptyArray() // 解析命令行为参数数组 val argc allocIntVar() val argv CommandLineToArgvW(commandLine.toKString(), argc.ptr) ?: returnmemScoped emptyArray() try { val argCount argc.value if (argCount 1) { // 只有程序名本身没有其他参数 returnmemScoped emptyArray() } // 转换参数跳过程序名 Array(argCount - 1) { index - argv[index 1]?.toKStringFromUtf16() ?: } } finally { LocalFree(argv) } }通过GetCommandLineW获取到W版本的命令行参数然后通过CommandLineToArgvW将它们解析为参数数组随后将程序名之后的真正的 args 们通过toKStringFromUtf16转化为 Kotlin String 之后就得到了之最终我们需要的东西不乱码的 args 数组。在一个 KMP 项目中我们现在可以通过expect/actual来实现 mingwX64 平台下对参数的解析至少我现在是这么做的// commonMain - 声明期望函数 internal expect fun resolveArgs(args: ArrayString): ArrayString // appleMain linuxMain - 直接返回原参数这些平台默认 UTF-8 internal actual fun resolveArgs(args: ArrayString): ArrayString args // mingwMain - 使用 Windows Unicode API 重新获取参数 internal actual fun resolveArgs(args: ArrayString): ArrayString { // ... Unicode 处理逻辑 }main方法中fun main(args: ArrayString) { val processedArgs resolveArgs(args) // 接下来使用 processedArgs 而不是 args你直接用 args 覆盖也行 }总结根据 KT-80201 的状态至少目前来看官方还没有解决这个问题。如果你比较关心这个问题的话可以追踪下这个 issue跟踪它的未来进展。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询