明确使用Unicode / ANSI Windows API并让它们由别名处理之间的区别？(Difference between explicitly using Unicode/ANSI Windo

明确使用Unicode / ANSI Windows API并让它们由别名处理之间的区别？(Difference between explicitly using Unicode/ANSI Windows APIs and letting them be handled by aliases?)

我明确地将我在项目中使用的每个Win32 API定义为W（宽）或A（ANSI）并让它由解决方案/项目配置决定之间的区别是什么？ 除了能够动态改变它，就是这样。

说我出于某种原因目前只需要Unicode，让我们自动扩展到正确的或者明确定义它们会更好吗？ 如果我只针对ANSI或Unicode进行开发而不是支持两者，它会在发布时破坏某些系统吗？

What's the difference between me explicitly defining every Win32 API I use in my project as W (Wide) or A (ANSI) and letting it be decided by the solution/project configuration? Apart by being able to change it on the fly, that is.

Say I only need Unicode at the moment for some reason, would it be better of me to just let them expand to the correct one automatically or explicitly define them? Would it break some systems on release if I only develop for ANSI or Unicode versus supporting both?

最满意答案

基于“ANSI”字符集（Windows 9x）的Windows的最新版本很久以前就达到了使用寿命。 所有较新的版本（基于NT），甚至是嵌入式版本，都使用UTF-16来提供完整的Unicode支持。 对于那些，所有ANSI函数都实现为包装器，这会导致开销（转换需要时间和空间）和数据丢失（ANSI只是Unicode的一个子集）。

我只会使用宽版本。 特别是，在导出接口时，我会避免使用基于TCHAR的字符串，因为它需要我提供两种不同的实现，因为现代代码不需要它。

The last versions of Windows that were based on an "ANSI" charset (Windows 9x) reached end of life long ago. All newer versions (based on NT), even the embedded ones, use UTF-16 to provide full Unicode support. For those, all the ANSI functions are implemented as wrappers which cause overhead (conversion needs time and space) and loss of data (ANSI is only a subset of Unicode).

I would only use the wide versions. In particular, when exporting interfaces, I would refrain from using TCHAR-based strings, because it would require me to provide two different implementations and because it shouldn't be necessary for modern code.