我正在为C库做贡献。它具有接受char*文件路径名参数的功能。作者主要是UNIX开发人员，这在char*通常表示UTF-8的Unix上运行良好。（至少在GCC中，该字符集是可配置的，并且默认为UTF-8。）
但是，char*在Windows上表示ANSI，这意味着当前无法在Windows上的此库中使用Unicode路径名，wchar_t*应该在哪里使用Unicode路径名，并且仅支持UTF-16。（对StackOverflow的快速搜索显示ANSI Windows API函数不能与UTF-8一起使用。）
问题是，解决此问题的正确方法是什么？我们已经提出了多种解决方案，但是我们都不是Windows专家，因此我们无法真正决定如何正确地进行。我们的目标是该库的用户应该能够编写可在Unix和Windows上运行的跨平台代码。
在后台，该库已#ifdef到位以区分操作系统，以便可以在UNIXes上使用POSIX函数，在Windows上使用Win32 API。
到目前为止，我们提出了以下可能性：
wchar_t*。#ifdef库标头，以便该函数wchar_t*在Windows上可以接受。char*到wchar_t*和调用widechar的Windows API。选项1-4的问题在于，它们将要求用户自己有意识地照顾可移植性。选项5听起来不错，但我不确定这是否是正确的方法。
我也欢迎其他可以解决此问题的建议或想法。:)
由于可移植性是您的重要目标，因此我认为必须精确定义功能语义。除其他外，这意味着参数的类型和含义在不同平台之间没有变化。因此，如果您有一个接受char基于常规路径的函数，那么它应该在所有系统上都接受此类路径，并且这些路径的预期编码应该定义明确（不一定表示“相同”）。那排除了选项（2）和（3）。
此外，可移植性要求相同的功能可在所有平台上使用。排除（1）。如果基于流和/或文件描述符的方法是您的库提供的唯一方法，则选项（4）可能是正确的，但是它仅针对那些函数而不是基于路径的函数提供可移植性。（并且请注意，stream（FILE *）API由C定义，而文件描述符是POSIX概念，不是C固有的。因此，从原则上讲，流比文件描述符更具可移植性。）
（5）可以工作，但是它比您实际需要的约束要强。函数可以定义期望的编码（虽然可以），但这不是必需的。足以定义如何确定该编码。
另外，您可以添加可在任何地方使用的wchar_t基于函数（与仅Windows相对）。这些对于Windows用户可能更方便。但是，与备选方案（4）相似，该备选方案仅针对这些功能提供可移植性。假设您不想删除基于-的变量，则需要将此替代方案与（5）的某些变化形式配对。char
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句