在 TagLib 中打开文件名中包含 Unicode 字符的文件
我对 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) 公共： __thiscall TagLib::文件名::文件名(wchar_t 常量 *)"
如果我尝试类似的操作：
TagLib::FileRef f(reinterpret_cast<char*>(fpath.GetBuffer(0)));
fpath.ReleaseBuffer();
我摆脱了编译错误，但“f”是无效的指针/对象..当我尝试读取标签时，我收到断言失败。
那么，任何人都可以给我关于如何将 Unicode 形式的 CString 传递给 TagLib ?
更新： TagLib 地址：http://developer.kde.org/~wheeler/taglib .html
谢谢你，
亚历克斯
I am quite new to the C++ 'area' so I hope this will not be just another silly 'C++ strings' question.
Here is my problem. I want to integrate TagLib (1.5, 1.6 as soon as I manage to build it for Windows) into an existing Windows MFC VS2005 project. I need it to read audio files metadata (not write).
The problem is that the program stores the input file names using CString(), and it has the Unicode option turned on (so the default chars are "wchar_t"). The reason for this (I think, the project was started by someone else) is that some of the 'input' file names could contain Unicode charaters (for example, Japanse or Arabic characters).
For example, the file path is something like "d:\docs\audio_test\stragecharڝhere.mp3", but I get it with:
CString fpath = tmpFile->GetFilePath();
Now.. if I try to do:
TagLib::FileRef f(fpath.GetBuffer(0));
fpath.ReleaseBuffer();
I get something like:
unresolved external symbol
"__declspec(dllimport) public:
__thiscall TagLib::FileName::FileName(wchar_t
const *)"
If I try something like:
TagLib::FileRef f(reinterpret_cast<char*>(fpath.GetBuffer(0)));
fpath.ReleaseBuffer();
I get rid of the compilation errors, but "f" is an invalid pointer/object.. and when I try reading a tag, I receive an assert failed.
So, can anyone give me some pointers on how should I pass that CString, in it's Unicode form, to the TagLib ?
Update: TagLib address: http://developer.kde.org/~wheeler/taglib.html
Thank you,
Alex
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该问题可能是由此处描述的问题引起的。基本上，MSVC 有一个选项以不同的方式处理
wchar_t类型，这会导致编译的库与没有该选项编译的应用程序不二进制兼容。不幸的是，CMakeLists.txt构建文件默认启用/Zc:wchar_t-选项。我会尝试编辑该文件，删除该选项并重新编译 TagLib。最好是 1.6 版本，因为它包含许多错误修复。It's possible that the problem is caused by the issue described here. Basically MSVC has an option to treat the
wchar_ttype differently, which causes the compiled library is not binary compatible with an application compiled without that option. Unfortunately theCMakeLists.txtbuild file enables the/Zc:wchar_t-option by default. I'd try to edit the file, remove the option and re-compile TagLib. Ideally version 1.6, as it contains a lot of bug fixes.当我第一次读你的文章时，我错过了一些重要的东西，所以这里是另一个新的和改进的答案：
错误来自链接器，而不是编译器。因此，似乎 TagLib::FileName 确实 有一个采用
wchar_t const*的构造函数，但问题是您没有链接到实现它的库，或者链接到不包含它的库版本。IIUC，这个库来自Linux世界（其中文件名表示为
char数组），后来移植到Windows（其中文件名表示为wchar_t数组） 。因此，采用wchar_t数组的 FileName 构造函数可能会在 Windows 上进行条件编译（即，在#ifdef _WIN32或类似的内容中），以及您要链接的库（如果您正在链接库）未使用相同的预处理器定义进行编译。I missed something essential when I first read your post, so here is another, new and improved answer:
The error comes from the linker, not the compiler. It thus seems that TagLib::FileName does have a ctor taking
wchar_t const*, but the problem is that you don't link with the library implementing it, or link with a version of the library that does not include it.IIUC, this library comes from the Linux world (where file names are expressed as
chararrays), and was later ported to Windows (where file names are expressed aswchar_tarrays). The FileName ctor taking awchar_tarray is thus probably conditionally compiled on Windows (i.e., inside#ifdef _WIN32or something similar), and the library you are linking with (if you are linking the library) was not compiled with the same preprocessor defines.