共用方式為

Microsoft 資訊保護 （MIP） SDK 常見問題和問題

  • 發行項

本文提供常見問題（常見問題）的解答，以及已知問題和常見錯誤的疑難解答指引。

常見問題集

元數據記憶體變更

我們 宣佈 要變更 Office 檔案的標籤數據儲存位置（Word、Excel、PowerPoint），以支援 Office 365、SharePoint Online 和其他服務的新功能。

元數據常見問題

問題：其他格式是否受到影響，例如 PDF？

  • 否，只有 Office 檔案，特別是 Word、Excel 和 PowerPoint 檔案。

問題：是否需要特定版本的 MIP SDK？

  • MIP SDK 1.7 和更新版本完全相容。

問題：是否有使用此儲存位置所需的特定 Office 用戶端版本？

  • 2021 年 9 月之後發行的所有 Microsoft 365 Apps 用戶端都支援這個新的元數據位置。 在租用戶系統管理員啟用受保護的共同撰寫功能之前，不會使用新的儲存位置。

問題：現有元數據是否儲存為custom.xml中的自定義屬性保持最新狀態？

  • 否。 第一次在啟用新的儲存位置之後儲存檔時，標籤數據會移至新位置。 透過 LabelingOptions.ExtendedProperties 寫入的元數據會保留在custom.xml中。

問題：是否可以讀取沒有 MIP SDK 的標籤數據？

  • 是，但您需要實作自己的程式碼來剖析檔案並擷取資訊。

問題：目前，從檔案中擷取索引鍵/值組字串，即可輕鬆地「讀取」標籤。 元數據仍然可以以這種方式讀取嗎？

  • 是，Office 檔案 XML 中仍然可以讀取元數據。 您的應用程式必須從原則檔案讀取共同撰寫設定，才能知道已啟用新功能集。 此設定會定義標籤數據的讀取/寫入位置（custom.xml與labelinfo.xml）。 檢閱 MS-OFFCRYPTO：LabelInfo 與自定義文檔屬性 |Microsoft Docs。 如需實作詳細數據。

問題：如何? 判斷是否在標籤原則中啟用共同撰寫？ 共同撰寫設定的狀態會從原則引擎傳回。 應用程式可以從原則引擎讀取原始位元組，以判斷共同撰寫狀態。

問題：標籤如何移轉至新位置？

  • 下列邏輯可用來判斷讀取哪個區段，以及用來讀取或寫入標籤數據。
動作 功能未啟用 已啟用功能
參閱 custom.xml （未受保護的） 或 Doc SummaryInfo 中的標籤（protected）。 如果標籤存在於labelinfo.xml中，則它是有效的標籤。
如果labelinfo.xml中沒有標籤，custom.xml或 Doc SummaryInfo 中的標籤就是有效的標籤。
寫入 所有新的標籤都會寫入custom.xml（未受保護的）或 Doc SummaryInfo（protected）。 所有新的標籤都會寫入labelinfo.xml。

檔案剖析

問題：我可以寫入目前使用檔案 SDK 讀取的相同檔案嗎？

MIP SDK 不支援同時讀取和寫入相同的檔案。 任何已標記的檔案都會導致 輸入檔的複本 ，並套用標籤動作。 您的應用程式必須以加上標籤的檔案取代原始檔案。

SDK 字串處理

問題：SDK 如何處理字串，以及我應該在程式代碼中使用哪些字串類型？

SDK 旨在用於跨平臺，並使用 UTF-8（Unicode 轉換格式 - 8 位） 來處理字串。 特定指引取決於您所使用的平臺：

平台 指引
Windows 原生 對於 C++ SDK 用戶端，C++標準連結庫類型 std::string 用於將字串傳遞至 API 函式或從 API 函式傳遞。 MIP SDK 會在內部管理 UTF-8 的轉換。 std::string從 API 傳回 時，您必須預期使用 UTF-8 編碼，並在轉換字串時據以管理。 在某些情況下，字串會當做向量（例如發佈授權（PL）的一 uint8_t 部分傳回，但應該視為不透明的 Blob。

如需詳細資訊與範例，請參閱：
  • WideCharToMultiByte 函 式可協助將寬字元字串轉換成多位元組，例如UTF-8。
  • SDK 下載中包含的下列範例檔案：
    • 中的 file\samples\common\string_utils.cpp範例字串公用程式函式，用於轉換至寬UTF-8字串。
    • 中的file\samples\file\main.cpp實wmain(int argc, wchar_t *argv[])作，其使用上述字串轉換函式。
.NET 針對 .NET SDK 用戶端，所有字串都會使用預設的UTF-16編碼，而且不需要特殊轉換。 MIP SDK 會在內部管理 UTF-16 的轉換。
其他平台 MIP SDK 支援的其他所有平臺都有UTF-8的原生支援。

內容標記

問題：MIP SDK 是否支援內容標記？

MIP SDK 不支援在任何檔案上直接套用內容標記，包括頁首、頁尾或浮浮水印。 將標籤數據寫入檔案時，檔案 SDK 會 寫入 contentBits 元數據屬性，以指出已套用保護（如果已設定）。 它不會寫入指出已套用頁首、頁尾或浮浮浮浮水印的屬性。 在應用程式中開啟檔案時，應用程式應該評估內容標記組態，並寫入至儲存盤案。

Android 上的保護和原則 SDK

問題：我應該使用哪一個共享連結庫將 MIP SDK 整合到我的 Android 應用程式中？

MIP SDK Android 二進位檔包括libmip_core.so、 libmip_protection_sdk.solibmip_upe_sdk.so 和 lipmip_unified.so。 libmip_unified.so 是包含核心、保護和原則共享連結庫的建議連結庫。

法規遵循

問題：Microsoft 資訊保護 SDK 聯邦資訊處理標準 （FIPS） 140-2 兼容嗎？

請參閱 FIPS 140-2 驗證。

問題和錯誤參考

錯誤：「不支援檔案格式」

問題：為什麼我在嘗試保護或標記 PDF 檔案時收到下列錯誤？

不支援檔案格式

此例外狀況會導致嘗試保護或標記數字簽署或密碼保護的 PDF 檔案。 如需保護及標記 PDF 檔案的詳細資訊，請參閱使用 Microsoft 資訊保護 的新 PDF 加密支援。

錯誤：「NoPolicyException：標籤原則未包含數據」

問題：為什麼嘗試透過 MIP SDK 讀取標籤或清單標籤時收到下列錯誤？

NoPolicyException：卷標原則未包含數據、CorrelationId=GUID、CorrelationId.Description=PolicyProfile、NoPolicyError.Category=SyncFile、NoPolicyError.Category=SyncFile

此錯誤表示標籤原則未在 Microsoft Purview 合規性入口網站 中發佈。 遵循 建立和設定敏感度標籤及其原則 來設定標籤原則。

如果已發佈標籤原則，請確定使用者帳戶包含在標籤原則組態之 發佈至 區段的任何群組中。 如需詳細資訊，請參閱 建立和發佈敏感度標籤。

外部使用者，包括來賓用戶，無法存取另一個組織的標籤原則。 若要容納這些使用者，請實作重試機制。 NoPolicyException如果擲回 ，請將 FileEngineSettings ProtectionOnlyEngine 屬性設定為 true，然後重試要求。 卷標作業將無法供該 IFileEngine 實例使用，但將會提供保護作業。

錯誤：「System.ComponentModel.Win32Exception： LoadLibrary 失敗」

問題：為什麼我在使用 MIP SDK .NET 包裝函式時收到下列錯誤？

System.ComponentModel.Win32Exception：呼叫 MIP 時，LoadLibrary 失敗：[sdk_wrapper_dotnet.dll]。Initialize（）。

您的應用程式沒有必要的運行時間，或未建置為 Release。 如需詳細資訊，請參閱 確定您的應用程式具有必要的運行時間 。

錯誤：「ProxyAuthError 例外狀況」

問題：為何在使用 MIP SDK 時收到下列錯誤？

「ProxyAuthenticatonError：不支援 Proxy 驗證」

MIP SDK 不支援使用已驗證的 Proxy。 若要修正此訊息，Proxy 系統管理員應該將 Microsoft Purview 資訊保護 服務端點設定為略過 Proxy。 這些端點的清單位於 Office 365 URL 和IP位址範圍 頁面。 MIP SDK 要求 *.protection.outlook.com （資料列 9） 和 Azure 資訊保護 服務端點 （第 73 列） 會略過 Proxy 驗證。

錯誤：使用資料流輸出標記圖像檔時發生「未知的錯誤」

問題： 當我嘗試使用數據流輸出從影像文件類型新增或移除卷標或保護時，為什麼會收到「未知的錯誤」？

使用數據流進行輸出時，數據流必須具有讀取和寫入許可權，才能修改影像檔的標籤或保護。

問題： 使用 MIP SDK 時是否有服務型節流限制？

保護 SDK 或檔案 SDK 中的保護作業所使用的保護服務，對於整個組織而言，每 10 秒有 7,500 個要求的限制。 也就是說，如果應用程式 A 每 10 秒產生 4,000 個要求，且相同組織中的應用程式 B 每 10 秒產生 4,000 個要求，則這兩個應用程式可能會開始接收 HTTP 429 Too Many Requests 回應。 收到這些例外狀況時，開發人員必須實作輪詢期間。