`MarshalAs(UnmanagedType.ByValTStr, SizeConst=256)` 导致字符串截断或乱码？

Question

在 P/Invoke 调用 Win32 API（如 `GetWindowText`、`OPENFILENAME`）时，若结构体字段声明为 `string` 并用 `[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]` 修饰，极易引发字符串截断或乱码。根本原因在于：`ByValTStr` 按**字符数**（非字节数）分配固定长度缓冲区，但 .NET 默认以 UTF-16 编码传递字符串；而部分 API 实际期望 ANSI（单字节）编码，或未正确以 `\0` 结尾。若原生代码写入超长字符串（>255 字符）、未置零终止，或调用方未显式指定 `CharSet = CharSet.Ansi/Unicode`，则 Marshaler 可能读取到残留内存数据，表现为乱码、截断、甚至越界访问。典型症状：中文显示为问号、末尾出现随机符号、长度恒为255等。解决方案需三者协同：明确 `CharSet`、确保 native 端严格按 `SizeConst` 写入并 null-terminate、必要时改用 `IntPtr` + 手动 marshaling 控制精度。

Answer 1

```html

一、现象层：典型症状与现场表现

• 调用 GetWindowText 后中文全显示为 ???? 或乱码字符（如 ）
• OPENFILENAME.lpstrFile 返回字符串长度恒为 255，末尾拼接随机 ASCII 符号（如 文档.txt\x00\x9A\xB3\xF1...）
• 同一 API 在不同 Windows 版本/区域设置下行为不一致（如简体中文系统 vs 英文系统）
• 调试器观察托管内存中字符串缓冲区前 256 字节存在非零残留数据

二、机制层：ByValTStr 的底层语义与编码错配

关键事实：UnmanagedType.ByValTStr 是唯一按 字符数（not bytes）分配固定长度缓冲区的 marshal 类型。其行为受三重上下文约束：

约束维度	默认值	风险点
DllImport.CharSet	CharSet.Ansi（.NET Framework）/CharSet.Unicode（.NET 5+）	隐式切换导致 ANSI/Unicode 编码解释冲突
Marshal.SizeOf(typeof(T))	UTF-16 字符 × SizeConst → 实际分配 256 × 2 = 512 字节	但原生 API 若按 ANSI 写入，则仅填充 256 字节，后 256 字节为垃圾数据

三、交互层：Win32 API 的双模契约与未定义行为

以 OPENFILENAME 为例，其字段 lpstrFile 声明为 LPCSTR 或 LPCWSTR，取决于编译宏 UNICODE —— 但 P/Invoke 层无法感知该宏，必须显式对齐：

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct OPENFILENAMEW { /* ... */ 
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)] 
    public string lpstrFile; // ✅ Unicode 模式下：260 UTF-16 chars = 520 bytes
}

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct OPENFILENAMEA { /* ... */
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)] 
    public string lpstrFile; // ⚠️ Ansi 模式下：260 bytes ≠ 260 chars（中文占2字节）
}

四、诊断层：三步定位法

1. 查 CharSet 一致性：确认 [DllImport]、[StructLayout]、[MarshalAs] 三者 CharSet 值严格相同
2. 验 native 写入边界：使用 WinDbg 或 Process Monitor 观察 API 是否在 SizeConst - 1 处写入 \0（如 255 字符后必置零）
3. 测内存镜像：用 Marshal.UnsafeAddrOfPinnedArrayElement 获取缓冲区首地址，逐字节 dump 验证 null-termination 位置

五、解决层：纵深防御策略

graph LR
A[首选方案：显式 CharSet + 安全 SizeConst] --> B[强制 native 端 null-terminate]
B --> C{是否需跨编码兼容？}
C -->|是| D[改用 IntPtr + Marshal.PtrToStringAuto/Ansi/Uni]
C -->|否| E[保留 ByValTStr，但 SizeConst 设为 API 文档要求值+1]
D --> F[手动 AllocHGlobal/FreeHGlobal，规避 GC 移动风险]

六、工程实践：生产就绪代码模板

// ✅ 经过验证的 OPENFILENAMEW 安全声明
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct OPENFILENAMEW {
    public uint lStructSize;
    public IntPtr hwndOwner;
    public IntPtr hInstance;
    public string lpstrFilter;
    public string lpstrCustomFilter;
    public uint nMaxCustFilter;
    public uint nFilterIndex;
    
    // 关键：SizeConst=260 对应 MAX_PATH，且确保 native 写入 ≤259 chars + \0
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
    public string lpstrFile;
    
    public uint nMaxFile;
    // ... 其余字段省略
}

// ⚠️ 调用时必须指定 EntryPoint 和 CharSet
[DllImport("comdlg32.dll", CharSet = CharSet.Unicode, EntryPoint = "GetOpenFileNameW")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool GetOpenFileName(ref OPENFILENAMEW ofn);

七、进阶警示：ByValTStr 的不可替代性陷阱

尽管 IntPtr + 手动 marshaling 更可控，但 ByValTStr 在以下场景仍不可替代：

• 结构体嵌套传递（如 DLGTEMPLATE 中的字符串数组）
• 需要栈内连续布局的 COM 接口（避免堆分配导致 lifetime mismatch）
• 性能敏感路径（避免每次调用的 Marshal.AllocHGlobal 开销）

八、历史兼容：.NET Framework 与 .NET Core/.NET 5+ 的差异

注意：.NET Framework 默认 CharSet = CharSet.Ansi，而 .NET 5+ 默认 CharSet = CharSet.Unicode。若迁移旧代码，必须显式补全所有 CharSet 声明，否则：

• 在 .NET 6+ 上调用 ANSI 版 API（如 GetWindowTextA）会因 UTF-16 → ANSI 自动转换丢失中文
• 未声明 CharSet 的 [DllImport] 将触发 runtime warning（CS1699）

九、测试验证：自动化断言清单

1. 输入 259 个中文字符 → 验证返回字符串长度为 259，无截断
2. 输入 260 个 ASCII 字符 → 验证末尾为 \0，无越界读取
3. 调用前后用 GC.Collect() + GC.WaitForPendingFinalizers() 测试 GC 移动鲁棒性
4. 在英文系统（ANSI Code Page 1252）与中文系统（936）下分别运行，比对输出一致性

十、终极原则：P/Invoke 字符串契约的黄金三角

任何安全的字符串 P/Invoke 必须同时满足：

• 声明侧：结构体 [StructLayout(CharSet = X)] 与字段 [MarshalAs(..., SizeConst = N)] 显式一致
• 实现侧：native 函数严格遵守 N-1 字符上限 + \0 终止
• 运行侧：托管端使用 Marshal.PtrToStringXxx 或 Encoding.GetString 进行显式解码，不依赖自动 marshal

```