用TagLib在文件名中用Unicode字符打開文件

我對C++的「區域」很陌生，所以我希望這不會是另一個愚蠢的「C++字符串」問題。用TagLib在文件名中用Unicode字符打開文件

這是我的問題。我想將TagLib（1.5，1.6，只要我設法爲Windows構建它）整合到現有的Windows MFC VS2005項目中。我需要它來讀取音頻文件元數據（不寫）。

問題是程序使用CString（）存儲輸入文件名，並且它打開了Unicode選項（所以默認字符是「wchar_t」）。這個原因（我認爲該項目是由其他人開始的）是，某些「輸入」文件名可能包含Unicode字符（例如Japanse或阿拉伯字符）。

例如，文件路徑是一樣的東西「d：\文檔\ audio_test \ stragecharڝhere.mp3」，但我得到它：

CString fpath = tmpFile->GetFilePath();

現在..如果我嘗試做：

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

我得到的是這樣的：

解析外部符號「__declspec（dllimport的）市民： __thiscall標籤庫::文件名::文件名（wchar_t的常量*）」

如果我嘗試類似：

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

我擺脫了編譯錯誤的，但「F」是無效的指針/對象..當我嘗試讀取標籤時，我收到一個斷言失敗。

那麼，任何人都可以給我一些關於如何將該CString，以Unicode形式傳遞給TagLib的指針？

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

謝謝

亞歷

來源

2009-10-05 Alex

我錯過了什麼重要的，當我第一次看到你的帖子，所以這裏是另一個新的和改進的答案：

錯誤來自鏈接器，而不是編譯器。因此，似乎TagLib :: FileName 確實有有一個採取wchar_t const*的策略，但問題是您不會鏈接到實現它的庫，或者鏈接到不包含它的庫的一個版本。這個庫來自Linux世界（其中文件名被表示爲char數組），並且後來移植到Windows（其中文件名被表示爲wchar_t數組）。因此，採用wchar_t陣列的FileName ctor可能是在Windows上有條件地編譯的（即在#ifdef _WIN32或類似內部），並且您鏈接的庫（如果您正在鏈接庫）沒有使用相同的預處理器定義進行編譯。

來源

2009-10-06 15:02:42

的確，圖書館從* nix移植到了windows。實際上，它使用一些#ifdef來根據平臺選擇數據類型。在某些時候，我將不得不爲Windows自己編譯它（最新版本），因爲現在我正在使用預編譯的1.5 MSVC版本。我將再次嘗試使用它 - 目前，項目的優先級已更改:) 謝謝 – Alex 2009-10-07 11:24:05

問題可能是由here所述的問題引起的。基本上MSVC有一個選項，以不同的方式處理wchar_t類型，這會導致編譯的庫與不使用該選項編譯的應用程序不是二進制兼容的。不幸的是，默認情況下，CMakeLists.txt構建文件啓用/Zc:wchar_t-選項。我試着編輯文件，刪除選項並重新編譯TagLib。理想情況下版本爲1.6，因爲它包含很多錯誤修復。

來源

2009-10-06 16:16:12

您好，感謝您的信息。事實上，我將不得不爲windows編譯1.6版本，因爲我特別感興趣的是mp4標籤支持（1.6版本中已添加）。目前我只是測試了1.5版 - 編譯的二進制版本（帶/ for MSVC）。謝謝 – Alex 2009-10-07 11:12:13

當我有完全相同的問題時，這個答案在谷歌上彈出＃1。殺死/ Zc：wchar_t-正是我所需要的。謝謝！ – Kyle 2010-06-15 00:33:54

用TagLib在文件名中用Unicode字符打開文件

回答

相關問題