一次讲清：宽字节、多字节、UTF-8、GBK、Unicode、代码页（从原理到 Windows/VC6 实战） 这篇文章的目标只有一个：建立不再被“乱码”反复折磨的工程级认知模型。全文从“字符是什么”讲到“Windows 为什么会乱”，再落到 VC6/老项目的可执行结论，一次性讲清，不靠零散记忆，不靠运气。一、乱码的本质只有一句话乱码不是字符错了，而是“同一串字节，被用错了规则去解释”。任何文本问题，都可以还原成下面这条链路：字符含义 → 字符集 → 编码方式 → 字节序列 → 再被解释只要编码方式和解释方式不一致，就一定乱码。二、字符集（Character Set）：先规定“有哪些字”字符集解决的是：世界上有哪些字符，以及它们的编号是什么。常见字符集包括：ASCII、GB2312、GBK、GB18030，而现代世界几乎都以 Unicode 为核心。Unicode 的本质不是编码，它只是一个全球统一的编号表（Code Point）：“中” → U+4E2D“国” → U+56FD😀 → U+1F600Unicode 只负责“编号”，不负责怎么存成字节。三、编码方式（Encoding）：把编号变成字节编码方式解决的是：Unicode 编号如何存储成二进制字节。UTF-8Unicode 的一种编码方式1～4 字节变长完全兼容 ASCII网络和跨平台事实标准例：“中” Unicode：U+4E2D UTF-8：E4 B8 AD（3 字节）UTF-16Unicode 的另一种编码方式2 或 4 字节Windows 内部原生使用C/C++ 中对应 wchar_t例：“中” UTF-16LE：2D 4EGBK中文本地编码1 或 2 字节不是 Unicode强依赖“解释环境”例：“中” GBK：D6 D0四、宽字节 vs 多字节（这是 Windows 语境）这是Windows 编程术语，不是编码学术概念。多字节（MBCS）使用 char*一个字符占用字节数不固定GBK、UTF-8、Shift-JIS 都是多字节多字节 ≠ UTF-8宽字节（Wide）使用 wchar_t*Windows 下固定为 UTF-16一个 wchar_t = 2 字节五、ANSI 是什么（99% 乱码根源）ANSI 不是一种编码。在 Windows 里：ANSI = “当前系统代码页下的多字节解释规则”所有 xxxA API 的真实行为都是：char* → 按当前代码页（CP_ACP） → 转 Unicode → 再处理六、代码页（Code Page）：解释字节的“字典”代码页决定：char* 到底按什么规则被解释。常见代码页：936：GBK（简体中文）65001：UTF-81252：西欧CP_ACP 表示当前 ANSI 代码页，由系统区域设置决定。七、Windows 并不存在“UTF-8 进程”这是一个非常重要的纠正点。Windows 内部统一使用 UTF-16（W API）。 所谓“UTF-8 系统”，只是：把 CP_ACP 改成了 65001让 所有 A API 按 UTF-8 解释 char*W API 永远不受影响。八、VC6 / 老项目乱码的形成公式源码保存编码 ≠ 运行时 CP_ACP ≠ API 解释规则↓乱码典型炸点包括：源码是 GBK，系统 CP_ACP = 65001源码是 UTF-8，系统 CP_ACP = 936DLL 被不同宿主进程加载使用 MessageBoxA / CreateFileA / RegSetValueExA九、为什么 UTF-8 Beta 会“突然把老程序搞炸”Windows 的 “Beta: 使用 Unicode UTF-8 提供全球语言支持” 会：把 CP_ACP 改成 65001所有 A API 改为按 UTF-8 解 char*但老程序仍在传 GBK 字节，于是必然乱码。系统没错，是老程序的隐含假设错了。十、工程级铁律（记住这 4 句就够）char* 没有编码，只有字节编码信息存在于“解释方”，不在字符串本身A API = 按代码页猜W API = 唯一确定行为十一、VC6 / 老项目的最终正确路线在不重构整个项目的前提下，唯一长期稳定方案是：内部 char* 统一 UTF-8与系统交互全部使用 W API在边界做明确转换（MultiByteToWideChar / WideCharToMultiByte）不再依赖 CP_ACP不再关心宿主是 GBK 还是 UTF-8这套方案不靠系统设置、不靠用户环境、不靠运气。十二、结语乱码从来不是“中文太复杂”，而是规则被混用了。 只要你在工程中做到：一处确定、处处确定，乱码问题会从此消失。这篇文章本质上是在帮你建立一个判断标准：“这串字节，是谁、按什么规则，在解释它？”一旦这个问题你能随时回答，乱码就再也不是问题。

Powershell执行权限 解决方法：第一步：以管理员身份运行powershell第二步：执行：get-ExecutionPolicy 一般来说回复都是Restricted，表示状态是禁止的。第三步：执行： set-ExecutionPolicy RemoteSigned 第四步：选择Y，回车

Windows释放磁盘空间 深入解析Windows下的WinSxS目录：能否删除？如何安全清理？WinSxS（Windows Side-by-Side）目录是Windows系统的核心组件库，存放着系统更新、功能模块和版本兼容所需的文件。许多用户因其占用大量磁盘空间而试图手动删除它，但这是极其危险的操作！本文将详解其作用，并提供安全清理方法。一、为什么不能直接删除WinSxS？1. 系统依赖性强组件存储（Component Store）：Windows更新、修复和功能启用（如.NET Framework、语言包）均依赖此目录。硬链接机制：目录中大部分文件是系统文件的“硬链接”（Hard Link），实际物理存储远小于显示的大小。直接删除会导致系统文件丢失、崩溃或无法启动。2. 权限与副作用权限限制：普通用户无权限删除系统保护文件，强行操作会触发错误。更新失效：删除后系统无法安装新更新或回滚旧版本。二、安全清理WinSxS的3种方法方法1：使用磁盘清理工具（推荐）1. 按 `Win + S` 搜索“磁盘清理”并打开。 2. 选择系统盘（通常是C盘），点击“确定”。 3. 点击“清理系统文件”，再次选择系统盘。 4. 勾选“Windows 更新清理”和“Service Pack 备份文件”。 5. 点击“确定”执行清理。方法 2：DISM 命令清理组件存储:: 以管理员身份运行CMD或PowerShell :: 分析可清理空间 DISM /Online /Cleanup-Image /AnalyzeComponentStore :: 执行清理（保留最近版本） DISM /Online /Cleanup-Image /StartComponentCleanup :: 彻底清理（删除所有旧版本，慎用！） DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase方法 3：存储感知自动清理（Windows 10/11）1. 打开 **设置 > 系统 > 存储**。 2. 启用“存储感知”，点击“配置存储感知”。 3. 设置自动清理计划（如每周一次）。 4. 勾选“删除临时文件”和“自动清理下载文件夹”。

Windows硬件状态监控 开源项目： https://github.com/zhongyang219/TrafficMonitor

Windows所有exe右键没有打开修复 以下文件保存为reg后运行修复注册表Windows Registry Editor Version 5.00   [HKEY_CLASSES_ROOT\exefile\shell\open] "EditFlags"=hex:00,00,00,00   [HKEY_CLASSES_ROOT\exefile\shell\open\command] @="\"%1\" %*" "IsolatedCommand"="\"%1\" %*"   [hkey_classes_root\.exe] @="exefile" [hkey_classes_root\exefile\shell\open\command] @="%1" %*