[BUG]: Fail to fetch using ARM NPU Embedder on Windows when user has non-ASCII characters in username.

快速结论：这个报错通常出现在 Windows ARM（Snapdragon）设备上，Windows 用户名包含非 ASCII 字符（如 ø、中文、西里尔字母）时使用 AnythingLLM 的 NPU Embedder 嵌入文档。优先排查路径在交给 QnnSDK / ONNX Runtime 原生绑定时的编码转换问题。[BUG]: Fail to fetch using ARM NPU Embedder on Windows when user has non-ASCII characters in username.

适用环境：AnythingLLM Desktop（Windows），Windows ARM / Snapdragon PC；NPU Embedder 使用 QnnSDK aarch64-windows-msvc 后端；使用 all-minilm-l6-v2 嵌入模型。

最快修复方案：暂无确认的一步修复方案。Issue 中已验证的临时绕过方法是：以管理员身份打开命令提示符，在错误路径和正确路径之间创建符号链接，例如 mklink /d C:\Users\HxxxxxFￃﾸrxx C:\Users\HxxxxxFørxx。此外还有其他可优先尝试的方向（将存储目录设为纯 ASCII 路径），但未经该硬件端到端验证。

注意事项：符号链接方案需要管理员权限，且需替换为实际用户名对应的错误/正确路径；存储目录指向纯 ASCII 路径的做法在该 Issue 中仅作为建议提出，未在本机验证。真正的代码层修复尚在进行/迁移中（评论提到 moved to #6481），在包含修复的版本发布前，绕过方案仍是主要手段。

问题场景

在 Windows ARM（Snapdragon）PC 上运行 AnythingLLM 桌面版，选择 NPU Embedder 对文档进行嵌入（embed）时触发失败。日志显示 NPU 已启用，使用 QnnSDK 后端加载位于用户目录下的 model.onnx。当 Windows 用户名含非 ASCII 字符（本例为 ø）时，加载模型失败并返回 “Failed to fetch”；若 Windows 用户名不含国际字符则可以正常工作。

报错原文

[backend] info: [QnnNativeEmbedder] NPU is enabled, using QnnSDK backend at C:\Users\HxxxxxFørxx\AppData\Local\Programs\AnythingLLM\resources\QnnSDK\aarch64-windows-msvc\QnnHtp.dll
Runtime options:
backend_path: C:\Users\HxxxxxFørxx\AppData\Local\Programs\AnythingLLM\resources\QnnSDK\aarch64-windows-msvc\QnnHtp.dll
soc_model: 60
htp_arch: 73
htp_performance_mode: high_performance
enable_htp_fp16_precision: 1

Load model from C:\Users\HenrikFￃﾸrli\AppData\Roaming\anythingllm-desktop\storage\models\qnn-embedder\all-minilm-l6-v2\model.onnx failed:Load model C:\Users\HxxxxxFￃﾸrxx\AppData\Roaming\anythingllm-desktop\storage\models\qnn-embedder\all-minilm-l6-v2\model.onnx failed. File doesn't exist

原因分析

最可能的原因是 Windows 路径在交给 QnnSDK / ONNX Runtime ARM64 原生绑定时发生了编码/字符集转换错误。评论中指出，ø（U+00F8，UTF-8 字节为 0xC3 0xB8）被原生绑定按 Latin-1 / OEM 代码页解释并再次编码，最终产生乱码 ￃﾸ，导致原生层打开文件失败并报告 File doesn't exist。同类 LLM 模型加载路径正常，是因为它经过不同的代码路径（如 TokenManager 层）构造，未以同样方式跨过原生 ABI 传递路径字符串。此外，日志中打印的路径仍是 JS 的 UTF-8 字符串，真正的转码发生在交给 QnnSDK 原生函数的那一刻。这类问题在使用原生绑定的 Windows 应用中，只要用户名含非 ASCII 字符就可能反复出现。

环境排查

确认运行的是 AnythingLLM Desktop 而非 Docker/浏览器部署。
确认操作系统为 Windows on ARM（Snapdragon），并使用 NPU Embedder。
确认 QnnSDK 后端路径为 aarch64-windows-msvc\QnnHtp.dll。
检查 Windows 用户名是否含非 ASCII 字符（如 ø、CJK、西里尔字母等）。
确认嵌入模型为 qnn-embedder\all-minilm-l6-v2\model.onnx，且存储目录位于用户配置目录下。
对照 LLM 模型加载路径（本例中路径正确），确认是否只有 Embedder 路径被转码破坏。

解决步骤

先确认问题可复现：使用含非 ASCII 字符的 Windows 账号登录，安装 AnythingLLM，选择 NPU Embedder，尝试嵌入文档，观察日志是否出现 File doesn't exist 及路径乱码。
可优先尝试已验证的临时绕过：以管理员身份打开命令提示符，为错误路径创建指向正确路径的符号链接：mklink /d C:\Users\HxxxxxFￃﾸrxx C:\Users\HxxxxxFørxx（将用户名替换为实际值）。此方法在该 Issue 中已验证可用。
可优先尝试的替代方向（未在本机验证）：将 QNN embedder 的存储目录设置为不含非 ASCII 字符的路径（例如 C:\AnythingLLM），使交给原生绑定的路径为纯 ASCII，从而绕开转码问题。
若需代码层修复：定位 NPU/QNN embedder 路径构造代码（可能在 server/utils/EmbeddingEngines/ 或 QnnNativeEmbedder 类中），对比 LLM 模型路径的构造方式，改用 path.join() 等原生路径 API 而非字符串拼接，或在交给 ONNX Runtime 前修正字符集转换，并增加非 ASCII 路径的单元测试。
关注上游修复进度：评论提到问题已迁移至 #6481，等待包含修复的版本发布后再升级验证。

验证方法

在应用临时绕过（符号链接或纯 ASCII 存储路径）后，重新执行一次文档嵌入操作：正常情况下不再出现 “Failed to fetch”，日志中不再出现 File doesn't exist，且路径中的 ø 不再被显示/解析为 ￃﾸ，嵌入流程可正常完成。若在含非 ASCII 用户名的 ARM 设备上嵌入成功，则说明绕过生效。