Question

我对C ++'领域'很陌生，所以我希望这不仅仅是另一个愚蠢的'C ++字符串'问题。

这是我的问题。我希望将TagLib（1.5,1.6，一旦我设法为Windows构建它）集成到现有的Windows MFC VS2005项目中。我需要它来读取音频文件元数据（不写）。

问题是程序使用CString（）存储输入文件名，并且它启用了Unicode选项（因此默认字符为“wchar_t”）。原因（我认为，该项目是由其他人启动的）是某些“输入”文件名可能包含Unicode字符（例如，日语或阿拉伯字符）。

例如，文件路径类似于“d：\ docs \ audio_test \ stragecharڝhere.mp3”，但我得到它：

CString fpath = tmpFile->GetFilePath();

现在......如果我试着这样做：

TagLib::FileRef f(fpath.GetBuffer(0));
fpath.ReleaseBuffer();

我得到类似的东西：

未解决的外部符号 “__declspec（dllimport）public： __thiscall TagLib :: FileName :: FileName（wchar_t const *）“

如果我尝试这样的话：

TagLib::FileRef f(reinterpret_cast<char*>(fpath.GetBuffer(0)));
fpath.ReleaseBuffer();

我摆脱了编译错误，但“f”是一个无效的指针/对象..当我尝试读取标记时，我收到一个断言失败。

那么，任何人都可以给我一些指示，我应该如何将它的Unicode格式的CString传递给TagLib？

更新：TagLib address: http://developer.kde.org/~wheeler/taglib.html

谢谢，

亚历

Answer 1

问题可能是由here描述的问题引起的。基本上，MSVC可以选择不同地处理wchar_t类型，这会导致编译库与没有该选项编译的应用程序不是二进制兼容的。遗憾的是，CMakeLists.txt构建文件默认启用/Zc:wchar_t-选项。我尝试编辑该文件，删除该选项并重新编译TagLib。理想情况下版本1.6，因为它包含许多错误修复。

Answer 2

当我第一次阅读你的帖子时，我错过了一些必要的东西，所以这是另一个新的和改进的答案：

错误来自链接器，而不是编译器。因此，似乎TagLib :: FileName 有一个ctor采用wchar_t const*，但问题是你没有链接到实现它的库，或链接到库的版本不包括它。

IIUC，这个库来自Linux世界（文件名表示为char数组），后来移植到Windows（文件名表示为wchar_t数组）。因此，采用wchar_t数组的FileName ctor可能是在Windows上有条件地编译的（即，在#ifdef _WIN32内部或类似的东西），并且您链接的库（如果您正在链接库）未编译使用相同的预处理器定义。

在TagLib中打开文件，文件名中包含Unicode字符

2 个答案: