Windows下Haskell FFI调用fopen的FilePath编码问题求解

问题根因 #

Windows 平台窄字符版本（char* 入参）的fopen 内部走ANSI代码页解析逻辑，不支持完整Unicode字符集，只要文件名包含当前代码页覆盖范围外的字符，就会出现路径解析失败。GHC 提供的getFileSystemEncoding 在Windows环境下正是映射到这套已废弃的旧代码页机制，和官方文档提示的风险一致，天然无法覆盖所有Unicode文件名场景，这就是带变音符号的文件打不开的核心原因。

方案1：原生宽字符适配（推荐，全平台兼容，无额外依赖） #

如果可以修改对接的C库代码，这是最稳定的解决方案：仅需在C侧加一层平台适配，Windows环境下使用支持UTF-16宽字符的_wfopen 替代fopen，类Unix环境保持原有窄字符逻辑不变，Haskell侧同步做平台分支处理即可。

首先替换原有greeting.c的适配代码：

#include <stdio.h>
#include <stdlib.h>

#ifdef _WIN32
#include <wchar.h>
// Windows平台接收UTF-16宽字符路径
FILE *greeting_fopen (const wchar_t *filename) {
  wprintf(L"Hello, now trying to open %ls\n", filename);
  return _wfopen(filename, L"r");
}
#else
// 类Unix平台保持原有char*路径逻辑
FILE *greeting_fopen (const char *filename) {
  printf("Hello, now trying to open %s\n", filename);
  return fopen(filename, "r");
}
#endif

对应修改Haskell侧的FFI逻辑，加入平台分支判断：

{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE CPP #-}
#if defined(_WIN32)
import Foreign.C (CWString)
#else
import Foreign.C (CString)
#endif
import Foreign.Ptr (Ptr, nullPtr)
import qualified GHC.Foreign as GHC
import qualified GHC.IO.Encoding as GHC
import Prelude hiding (writeFile)
import System.IO (writeFile, putStrLn, error)
import Control.Monad (when)

filename = "Ümlauts.txt"

main = do
  writeFile filename "content"  -- 确保目标文件存在
#if defined(_WIN32)
  -- Windows下使用系统原生UTF-16LE编码生成宽字符串
  GHC.withCString GHC.utf16le filename $ \wpath -> do
    handle <- greeting_fopen wpath
#else
  -- 类Unix系统沿用文件系统编码生成窄字符串
  fsEncoding <- GHC.getFileSystemEncoding
  GHC.withCString fsEncoding filename $ \fscpath -> do
    handle <- greeting_fopen fscpath
#endif
    when (handle == nullPtr) $ error $ "Could not open file " ++ filename
    putStrLn "file opened successfully"

-- FFI导入按平台匹配参数类型
#if defined(_WIN32)
foreign import ccall "greeting.c greeting_fopen"
  greeting_fopen :: CWString -> IO (Ptr ())
#else
foreign import ccall "greeting.c greeting_fopen"
  greeting_fopen :: CString -> IO (Ptr ())
#endif

该方案完全符合Windows官方API使用规范，支持任意Unicode文件名，类Unix侧逻辑不受影响，编译后可在全平台正常运行。

方案2：无源码适配（仅适用于无法修改C库的场景） #

如果你用的是预先编译好的第三方C库、无法修改源码，可以在Windows侧先调用GetShortPathNameW API获取目标文件的8.3格式短路径——这类路径仅包含ASCII字符，不存在编码问题，再将短路径转为CString传给库的fopen 接口即可。

注意该方案依赖系统开启8.3短路径生成功能，部分精简定制版Windows默认关闭该特性，兼容性弱于方案1，仅作为兜底方案使用。

不要尝试手动将路径转成当前系统ANSI代码页编码再传递，这种方式只能覆盖当前代码页收录的字符，遇到未收录的Unicode字符依然会报错，无法从根本上解决问题。

内容的提问来源于stack exchange，提问作者tarleb