什麼是 OLE 物件 —— 內嵌與連結的機制以及業務文件中的陷阱

「連按兩下 Word 規格書裡的表格，功能表竟然變成 Excel 的。」這是把表格當成 OLE 物件、而不是單純的圖片放進文件時才會有的行為。

OLE 是 Object Linking and Embedding(物件的連結與內嵌)的縮寫。它把其他應用程式建立的文件資料，以內嵌或連結的形式整合進作為容器的文件。技術上的實體，是能夠內嵌到文件或被文件連結的 COM 物件。¹²

理解的起點是「資料本體究竟在哪裡」。想清楚這一點，就能理清文件為什麼會變大、伺服器搬遷後連結為什麼會斷、表格明明看得見卻為什麼無法編輯。

本文寫給中小企業的資訊系統負責人與業務應用程式開發者。先比較內嵌與連結，再依序談日常操作、依症狀分類的處理方式，以及 Access 與資安方面需要注意的地方。COM、結構化儲存體等內部結構集中在第 7 章，今後維運與設計的判斷集中在第 8 章。

1. 先說結論：內嵌是「文件內的複本」，連結是「指向別處的參照」

內嵌與連結的差異，在於資料本體儲存在什麼地方。可攜性、檔案大小、更新方式，都由這個差異決定。³

內嵌適合希望文件獨立於原始檔案的場景。連結適合多份文件共用同一份資料、並希望原始資料的修改能夠反映出來的場景。不過，連結的更新未必是自動的。到底是自動更新還是手動更新，由文件端的設定決定。⁴⁵⁶

flowchart TB
    accTitle: 內嵌與連結的差異
    accDescr: 內嵌把資料本體整份儲存在作為容器的文件內部，因而自成一體，代價是文件變大；連結只在文件中放置參照、更新設定與通常的顯示資訊，資料本體留在連結來源檔案裡，因此文件較小，並可依連結更新的設定（自動或手動）套用連結來源的修改
    doc["作為容器的文件（Word 文件等）"] --> emb["內嵌：連資料本體一起儲存"]
    doc --> lnk["連結：參照、設定與顯示資訊（通常）"]
    emb -.-> self["自成一體但會變大"]
    lnk --> src["連結來源檔案（本體在這裡）"]
    src -.-> upd["可套用原始資料的修改（取決於設定）"]

圖 1：文件內部持有本體，還是參照別處的本體。這個差異決定了大小、更新與交付方面的性質。

「資料在文件裡」和「在任何 PC 上都能編輯」是兩回事。另外，只要顯示快取還在，即使無法使用建立來源應用程式或連結來源，也可能仍會顯示出最後一次的外觀。把「看得見」「能編輯」「已更新到最新」分開來想，是釐清問題的基本功。⁷⁸

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 25 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 它用在哪裡，又是怎麼進入文件的

2.1 會在 Word、Excel、Access 與老舊業務文件中遇到

OLE 是從 1990 年代起支撐 Windows 文件文化的技術。它的機制至今仍在運作，但與其說是新設計中會主動採用的技術，不如把它理解成會在既有文件與資料庫裡遇到的技術，這樣更貼近實務。

用 OLE 物件資料類型儲存員工照片與產品影像的 Access 資料庫，也是典型的既有資產。這類用途存在檔案膨脹的問題，第 5 章會談移轉的判斷。⁹

2.2 「插入物件」與「選擇性貼上」

在「插入物件」中，可以選擇新建一個物件，或是從既有檔案產生物件。另外還有「顯示為圖示」這種顯示方式。

在「選擇性貼上」中，除了資料的格式之外，還要選擇要做成內嵌還是連結。這裡列出的「～ 物件」，就是以 OLE 方式貼上的選項。它與單純當成圖片貼上不同，儲存的資料不同，之後的編輯方式也不同。¹⁰¹¹

這兩者對應到 OLE 的標準對話方塊 Insert Object 與 Paste Special，MFC 中也備有用來顯示它們的類別。從複製貼上或拖放產生物件的路徑，與直接依已註冊的類別或檔案產生物件的路徑差在哪裡，將在 7.1 說明。¹⁰¹²

3. 連按兩下之後到底發生了什麼

3.1 承載方是「容器」，負責編輯的應用程式是「伺服器」

當 Word 文件中有一張 Excel 表格時，Word 是作為容器的 OLE 容器，負責編輯表格的 Excel 則是 OLE 伺服器。在同一份文件裡處理來自多個應用程式的資料，這樣的文件在 OLE 中稱為複合文件。¹²

並不是 Word 自己實作了 Excel 的全部編輯功能。這是一種在操作物件時借用建立來源應用程式功能的機制。因此，即使資料本體已經儲存在文件內部，編輯時仍然需要建立來源應用程式。

3.2 連按兩下執行的是物件自己決定的「主動詞」

OLE 物件會把可以對自己執行的操作定義為動詞(verb)。表格對應「編輯」，聲音對應「播放」，諸如此類。

容器應用程式在接到連按兩下等操作後會呼叫 IOleObject::DoVerb。決定預設操作也就是主動詞(OLEIVERB_PRIMARY)內容的，不是容器而是物件這一端。DoVerb 會自動啟動 OLE 伺服器應用程式，並執行與該物件相稱的操作。連按兩下並不總是代表「編輯」。¹³

3.3 能在 Word 內部編輯的情況，與另開視窗的情況

只要內嵌物件與容器雙方都支援 In-Place Activation(就地啟用)，就可以在容器的視窗內部編輯。功能表列會被換成把容器與伺服器兩邊功能表合成起來的複合功能表列。Word 裡會出現 Excel 的編輯功能表，正是這個機制。點一下物件外側就會取消啟用，回到原本的功能表。¹⁴

sequenceDiagram
    accTitle: 從連按兩下到 In-Place Activation
    accDescr: 容器應用程式接到連按兩下後透過 IOleObject 的 DoVerb 執行主動詞，OLE 隨之啟動伺服器應用程式；當容器與伺服器雙方都支援 In-Place Activation 時，內嵌物件會在容器視窗內部合成功能表進行編輯，點一下外側則取消啟用並回到原本的功能表（若不支援，就改為在另一個視窗中編輯）
    participant U as 使用者
    participant C as 容器應用程式（Word 等）
    participant S as OLE 與伺服器應用程式
    U->>C: 連按兩下內嵌物件
    C->>S: 用 DoVerb 執行主動詞
    alt 雙方都支援 In-Place Activation
        S->>C: 啟動伺服器並合成功能表
        U->>C: 就地編輯
        U->>C: 點一下物件外側
        C->>S: 取消啟用並回到原本的功能表
    else 有一方不支援
        S->>C: 在另一個視窗中編輯
    end

圖 2：要就地編輯內嵌物件，需要容器與伺服器雙方都支援。不支援時就改為在另一個視窗中編輯。

開啟的方式，取決於物件的種類、所執行的動詞以及應用程式的支援情況。

In-Place Activation 是以內嵌為前提的機制，不用於連結。而且對容器與伺服器雙方而言，實作它都是選用的。單憑「同一份文件開啟方式卻不一樣」，還不能判定為故障。¹¹⁴¹³

4. 從症狀著手釐清：不更新、檔案大、打不開

4.1 表格看得見，連結來源的修改卻沒有反映出來

先確認連結來源的位置，以及連結的更新方式。連結在文件端持有的不是資料本體，而是連結來源的名稱與位置、更新設定等管理資訊，通常還有顯示快取。¹⁵⁵

追溯連結來源這項工作，由 COM 的一個元件——名稱物件(moniker)來承擔。檔案伺服器搬遷、資料夾改名、共用路徑變更、原始檔案被刪除等情況會讓變更後的位置無法再被追溯到，連結解析隨之失敗。這就是連結中斷。

此時只要已儲存顯示快取，文件裡就會留下舊的表格。表格顯示得出來，並不能證明連結是正常的。如果物件是以不帶快取的方式建立的，連最後那份顯示也不會留下。⁷⁸

處理方式是在文件的「編輯連結」中，把連結來源路徑改指到新的位置。路徑正確卻仍不更新時，也有可能只是被設成手動更新，因此要一併確認更新方式。連結來源的修改要在什麼時候套用，取決於自動更新還是手動更新的設定。⁶

如果大量使用連結的文件很多，就要把搬遷前的盤點與搬遷後的連結更新一併納入檔案伺服器搬遷計畫。可能的話，也把批次更新一起規劃進去。等搬遷之後才發現，就只能一份一份文件去找以前的負責人當初用的連結來源了。

4.2 Word 或 Excel 文件大得離譜

先確認是否真的需要重新編輯，再重新檢視文件內部持有資料本體的必要性。內嵌會把本體複製一份儲存在文件內部，因此一般比連結同樣內容時更大。通常還會儲存顯示快取，所以文件裡未必只有編輯用的資料。⁴⁷

如果一份內嵌了大量表格的報告變得很大、開啟也很慢，就該懷疑這個結構。處理方式要依使用情形來選。

不過，為了縮小檔案而改成連結，管理連結來源的責任就會隨之增加。對外散布的文件中參照很容易失效，因此單純「把所有內嵌都改成連結」並不合適。

4.3 連按兩下也打不開、無法編輯

首先確認該物件的建立來源應用程式在目前這台 PC 上是否也存在。內嵌的自成一體講的是資料儲存位置，並不代表連編輯功能也裝進了文件裡。

沒有建立來源應用程式時，只要已儲存顯示快取，就還能利用那份顯示。快取下來的顯示資料在設計上就是為了在伺服器應用程式未啟動或無法使用時，仍能由容器加以利用。⁷

不過，如果是以「顯示為圖示」的方式貼上的，即使看得見圖示也無法確認內容。對於本身不帶快取的物件，連最後的外觀也不會留下。是否帶有快取，取決於建立時對 OLERENDER 的指定。⁸

建立來源應用程式存在卻打不開時，依下列順序釐清。

1. 確認應用程式的版本相容性。有時需要轉換種類，OLE 也提供了用於轉換的標準對話方塊。
2. 確認 COM 類別註冊(CLSID)是否缺漏或損壞。有時需要透過重新安裝應用程式等方式修復註冊。
3. 確認資安設定造成的阻擋，以及文件本身是否損壞。¹⁰

對於來源不明的文件，不要先想著把它打開，而應採取不啟用其中物件的做法。資安方面的處理會在第 6 章說明。

5. 在 Access 中要區分「只是想存起來」還是「需要 OLE 的行為」

5.1 把影像放進 OLE 物件資料類型容易膨脹

Access 的 OLE 物件資料類型，是用來把 Excel 試算表、Word 文件、圖形、聲音等內嵌到資料表或與資料表建立連結的欄位類型。上限約為 1GB。⁹

如果只是為了儲存員工照片與產品影像就使用這個類型，儲存效率就會成為問題。Microsoft 說明指出，附件資料類型比 OLE 物件資料類型更有彈性，而且不會產生原始檔案的點陣圖影像，因此儲存空間的使用也更有效率。⁹

不過，改用附件資料類型並不等於容量上限就消失了。

這些是 Access 附件資料類型的限制。它們與 OLE 物件資料類型約 1GB 的上限，針對的對象並不相同。¹⁶

5.2 只是要存的話，改用附件資料類型或資料夾加路徑管理

如果是只儲存影像與檔案的新設計，沒有必要選擇 OLE 物件資料類型。可以考慮附件資料類型，或是把檔案放到資料夾裡、資料庫中只保存路徑的設計。對既有資料庫來說，這兩者也是移轉目標的選項。

另一方面，如果需要連結、啟用等 OLE 特有的行為，那就是另一回事了。這種情況下要連維持現狀一起納入判斷。不要因為「是 OLE 物件資料類型就立刻替換」，而應先分清究竟只是單純的儲存，還是確實需要讓它以物件的身分運作。⁹¹⁶

6. 資安：把一般的內嵌與 OLE 套件分開對待

6.1 文件會成為執行其他應用程式的入口

在 OLE 中，其他應用程式的物件被帶進文件，並在開啟端的 PC 上運作。這個結構對攻擊者來說同樣是運送手段。

實際上，透過含有精心構造的 OLE 物件的 PowerPoint 檔案等執行任意程式碼的漏洞 CVE-2014-4114，就被用在目標式攻擊中。由於能夠存放 OLE 物件的 Office 格式等都可能成為攻擊路徑，「本來以為只是讀一讀文件」就變成了執行的入口。¹⁷

6.2 從組織層面禁止 OLE 套件的啟用

特別需要留意的是 OLE 套件(Object Packager)。這是一種把任意檔案當成 OLE 物件包裹進文件的老舊機制，連可執行檔也裝得進去。與 Object Packager 相關的遠端程式碼執行漏洞，也已經公開。¹⁸

因此，透過登錄檔設定禁止在 Word、Excel、PowerPoint 中啟用 OLE 套件就成了一項強化措施。Microsoft 針對澳洲政府 Essential Eight 所寫的指引，示範了用 Intune 把設定用的 PowerShell 指令碼發布到整個組織的步驟。¹⁹

實務做法分成以下三點。

• 不開啟、也不讓別人開啟來源不明文件中的物件。把啟用當成與開啟另一個檔案同等分量的操作來對待。
• 從組織層面阻擋 OLE 套件的啟用。日常工作中幾乎不會需要它，因此不能只靠個人的注意力。
• 不要把內部文件中一般的內嵌與連結也一律禁止。要把套件與被動過手腳的文件所帶來的風險，跟既有的業務使用分開判斷。

本文的結論不是「全面禁止 OLE」。與其把連一般 Excel 表格的內嵌都一律禁止、把業務停下來，不如集中處理來源不明的物件與 OLE 套件——這才是本文的整理方向。

7. 內部結構：COM、結構化儲存體與名稱物件各自的角色

從這裡開始，是維護業務應用程式與調查文件資產時會用到的、偏實作面的說明。把前面各種症狀對應到「由哪個機制負責」。

7.1 支撐 OLE 複合文件的三大基礎

OLE 複合文件建立在 COM、結構化儲存體與統一資料傳輸之上。物件除了 COM 的 IUnknown 之外，還會公開 IOleObject、IViewObject2 等複合文件專屬的介面。連結物件還會再實作 IOleLink。²

在資料傳輸這條路徑上，OLE 伺服器用 IDataObject 提供自己的資料，並透過專用的剪貼簿格式告訴容器：這份資料能不能當成內嵌貼上、能不能當成連結貼上。這就接上了「選擇性貼上」裡的那些選項。¹²

不過，並不是所有建立操作都會經過 IDataObject。從「插入物件」新建，或是從既有檔案產生時，走的是直接依已註冊的類別或檔案建立物件的另一條路徑。剪貼簿與拖放本身的機制，在「剪貼簿與拖放的機制」中討論。

7.2 結構化儲存體是「一個檔案內部的檔案系統」

在結構化儲存體中，可以在一個檔案內部建立相當於目錄的儲存區(IStorage)與相當於檔案的資料流(IStream)的階層。根儲存區之下，可以巢狀放入子儲存區與資料流。²⁰

COM 提供的標準實作，就是複合檔案(Compound Files)。這是一種不依賴 FAT、NTFS 等檔案系統即可處理的單一檔案格式，格式本身已作為 MS-CFB(Compound File Binary File Format) 公開。²¹²²

容器負責準備物件的儲存位置。用 IPersistStorage 做持續性儲存的物件，會把自己的資料寫入被交給它的 IStorage。如果實作使用的是 IPersistStream，儲存位置就是 IStream。²

flowchart TB
    accTitle: 複合檔案的內部結構
    accDescr: 複合檔案在根儲存區之下擁有相當於目錄的儲存區與相當於檔案的資料流所構成的階層，用 IPersistStorage 做持續性儲存的內嵌物件放在子儲存區中，用 IPersistStream 做持續性儲存的物件放在資料流中；內嵌物件的儲存區可以帶上用來識別建立來源應用程式的 CLSID（也可能是空的），顯示快取的資料流通常會被儲存，但依建立時的指定也可能沒有，整體上就像一個檔案內部的檔案系統
    root["根儲存區（文件本體）"] --> s0["資料流：內文資料"]
    root --> st1["儲存區：內嵌（IPersistStorage）"]
    st1 --> s1["資料流：物件的資料"]
    st1 --> s2["資料流：顯示快取（通常）"]
    st1 -.-> cls["可用 CLSID 標示建立來源（選用）"]
    root -.-> s3["資料流：IPersistStream 持續性儲存"]

圖 3：在文件內部建立階層，由物件自己儲存資料。要區分使用儲存區的持續性儲存，與使用資料流的持續性儲存。

目錄項目中可以帶上用來識別物件建立來源的 CLSID。只要內嵌的儲存區裡有 CLSID，就能判斷這個物件該用哪個應用程式開啟。不過 CLSID 也可能是空的，顯示快取依建立時的指定也可能並不存在。²²⁸

7.3 即使變成 .docx，OLE 的儲存格式也沒有消失

舊 Office 格式的 .doc / .xls，檔案本身就是複合檔案。文件內文以資料流儲存，內嵌物件則以子儲存區儲存。

現行的 .docx / .xlsx 是以 ZIP 為基礎的 Open XML 格式，但遺留的 OLE 內嵌二進位檔 oleObject*.bin，至今仍以複合檔案格式儲存。另一方面，新版 Office 文件之間的內嵌，有時會讓 .xlsx 等檔案原樣收進 ZIP 裡。²²

也就是說，複合檔案並不只是「過去的文件格式」，它作為一種巢狀的儲存格式，也留在了現行文件的內部。

7.4 連結的所在由名稱物件負責，更新由連結的設定管理

名稱物件是 COM 中用來把物件的所在位置表示成名稱、並在需要時加以解析的元件。這個解析過程稱為繫結。連結物件使用名稱物件，管理連結來源的命名、追蹤與啟動。¹⁵

IOleLink 是向容器提供連結來源管理功能的介面。容器可以依它是否存在，判斷這是內嵌還是連結。即使儲存了含有連結的文件，連結的資料本體仍然儲存在連結來源。留在文件裡的，是名稱與位置、更新設定等連結自身的管理資訊，通常還有顯示快取。¹⁵

這樣的分工，正好對應 4.1 的「表格看得見卻不更新」。連結來源解析失敗就到不了本體，即使到得了，若是手動更新也不會自動更新。把所在位置的解析、更新設定與快取的顯示分開來查，原因就能理清。⁶⁷

8. 現在該怎麼與它相處：不增加新的依賴，掌握既有的依賴

新設計中避免依賴 OLE 內嵌，既有資產則以「維持能夠開啟的環境」與「盤點」來對待，這是基本方針。要不要繼續使用，依場景逐一判斷。

關於 Access 與資安的判斷，分別與 Microsoft 的資料相對應。⁹¹⁹

在長期保存上，不只是資料，能夠開啟它的環境同樣是資產的一部分。隨著應用程式世代交替與作業系統變化，「建立來源應用程式還能用」這個前提會逐漸失去。除了保留重要文件的 PDF 版本之外，還需要用虛擬機器維持能夠開啟的環境這類補救手段。

只要 Windows 繼續守住向後相容，OLE 的機制就會一直運作下去。但每一個物件能不能開啟，取決於建立來源應用程式是否還在。只要能確保這個前提，就沒有必要急著全面廢除。

盤點時要掌握三樣東西：存放連結來源的伺服器、含有內嵌的文件、使用 OLE 物件資料類型的資料庫。弄清楚這些相依關係，就能把搬遷、資安強化與移轉納入計畫。

9. 總結

OLE 物件，是用來把其他應用程式的文件資料以內嵌或連結方式加以處理的 COM 物件。內嵌把本體儲存在文件內部，連結則參照別處的本體。請先把這個差異記牢。²⁴⁵

其次，要把顯示、編輯、更新分開來想。即使顯示快取還在，沒有建立來源應用程式也無法編輯；追溯不到連結來源就無法更新。連按兩下時的開啟方式，也會隨物件的種類與動詞、以及對 In-Place Activation 的支援情況而改變。

新的做法上不要增加依賴，既有文件則要掌握並維持能夠開啟的環境與參照目標。Access 裡單純的影像與檔案存放，改用附件資料類型或路徑管理；OLE 套件的啟用，則從組織層面加以阻擋。

COM、剪貼簿與拖放，以及本文的複合文件，是 OLE 這個詞的不同面向。把元件基礎、資料傳輸、整合進文件這三種角色分開來看，就更容易追查老舊業務資產內部到底發生了什麼。

相關文章

• 什麼是 COM / ActiveX / OCX - 差異與關係一次講清楚
• 剪貼簿與拖放的機制 —— 在業務應用程式中正確處理 OLE 資料傳輸
• COM STA/MTA 基礎知識 - 執行緒模型與避免當機的思路
• C# 操作 Excel 時 EXCEL.EXE 殘留的問題 —— COM 參考的釋放模式與替換判斷
• 現在該如何對待 ActiveX / OCX - 保留、封裝、替換的判斷表
• VB6 / Access 業務應用程式的延續使用與移轉 —— 保留、封裝、替換的判斷表

相關諮詢領域

小村軟體有限公司承接與 OLE、COM 相關的遺留文件與資料庫資產的調查與移轉(擺脫 Access 的 OLE 物件資料類型、內嵌文件的盤點與 PDF 化、連結中斷的批次處理)、含有 COM 元件的業務應用程式的維護與改修，以及 Office 整合應用程式的設計。就算只是處在「這份文件連按兩下之後到底發生了什麼，我們也搞不清楚」的階段，也歡迎來諮詢。

• Windows 應用程式開發
• COM 元件開發
• 技術諮詢與設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

內嵌和連結到底差在哪裡？

差別在於資料本體放在什麼地方。內嵌(Embedding)會把物件的資料本體整份儲存到作為容器的文件內部。文件因此獨立於原始檔案，交給別台 PC 也不會發生參照中斷的情況(不過要編輯的話，接收端的 PC 上同樣需要建立來源應用程式。沒有的話，只有在已儲存顯示快取時才看得到那份快取，而以圖示方式顯示的物件連內容都無法確認)。代價是檔案會變大，而且修改原始資料也不會套用到文件裡。連結(Linking)只在文件中放置參照(連結來源的名稱與位置)、更新設定與顯示用的資訊，資料本體仍留在連結來源檔案裡。文件保持較小，連結來源的修改可以套用到文件中(是自動還是手動，取決於連結的更新設定)，但一旦連結來源被移動或改名、無法再追溯去向，就會發生連結中斷。要用哪一種方式貼上，可以在「選擇性貼上」或「插入物件」對話方塊裡選擇。

為什麼連按兩下文件裡的內嵌物件也打不開、無法編輯？

最常見的原因是目前這台 PC 上沒有安裝建立該物件的來源應用程式。編輯內嵌物件必須啟動建立來源應用程式(OLE 伺服器)才能進行，因此沒有這個應用程式時，只有在已儲存顯示快取的情況下才能顯示那份快取，而以圖示方式顯示時連內容都看不到。如果建立來源應用程式存在卻仍打不開，請依序懷疑這幾點：因版本差異而需要「轉換」的情況、可透過重新安裝等方式修復的 COM 類別註冊(CLSID)缺漏或損壞、文件本身損壞，以及資安設定阻擋了啟用。

為什麼 Word 或 Excel 檔案帶了內嵌物件之後會大得離譜？

因為內嵌是把資料本體複製一份儲存到文件內部的做法。與用連結持有同一個物件的文件相比，持有內嵌的文件一般更大。此外文件中通常除了編輯用的資料本體之外，還會儲存顯示快取(是否持有快取由建立時的指定決定)。想讓檔案變小，可選的做法有：改用連結而不是內嵌、以圖片形式貼上(接受不再需要重新編輯這個前提)、把原始檔案另行分享而文件中只放連結或圖片。不過連結需要有人管理連結來源，因此不適合用於對外散布的文件。

搬遷檔案伺服器之後，文件裡的連結物件不再更新了，這是為什麼？

因為連結物件在文件內持有的不是資料本體，而只有連結來源的名稱與位置資訊(名稱物件)、更新設定與顯示快取。檔案伺服器搬遷、資料夾改名、共用路徑變更等原因會讓連結來源的位置改變，一旦無法再追溯到變更後的位置，連結解析就會失敗，文件裡只剩下舊的顯示快取(若物件是以不儲存快取的方式建立的，連這份顯示也不會留下)。要修復的話，必須在各份文件的「編輯連結」中，把連結來源路徑改指到新的位置。另外，如果路徑正確卻仍不更新，也可能並不是連結中斷，而只是連結被設成手動更新，所以請一併確認更新方式的設定。文件數量很多時，請在搬遷前先盤點含有連結的文件，並盡可能把連結的批次更新納入計畫。

聽說 OLE 物件有資安風險，還能繼續用嗎？

「把別的應用程式的物件帶進文件，並在開啟端執行」這個 OLE 結構，對攻擊者來說同樣是方便的運送手段，利用精心構造的 OLE 物件達成任意程式碼執行的漏洞，確實被用在真實的目標式攻擊中。尤其是能夠包裹任意檔案的 OLE 套件最為危險，澳洲政府的 Essential Eight 等公開指引建議透過登錄檔設定，禁止在 Word、Excel、PowerPoint 中啟用 OLE 套件。並不需要連內部文件中一般的內嵌與連結也一律禁止；比較務實的折衷做法是：不開啟來源不明文件中的物件，並從組織層面阻擋 OLE 套件的啟用。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。