如何加密 Java：使用 GroupDocs 的自訂 XOR 加密

介紹

這是一個你可能曾經遇過的情境：你正在開發一個需要以數位方式簽署文件的應用程式，但內建的加密選項並不完全符合你的需求。也許你必須與遺留系統整合，該系統期待特定的加密格式；又或者你需要在效能關鍵的應用程式中使用輕量級加密，因為像 AES 這類重量級演算法會顯得過於龐大。

這時 自訂加密 就派上用場，而且實作起來比你想像的還要簡單。在本指南中，我們將以 XOR 運算作為範例，逐步說明如何建立自訂加密機制。雖然 XOR 加密不適合用於高安全性需求（我們會說明何時適用、何時不適用），但它非常適合學習 如何加密 Java 程式碼的原理，並滿足一些特殊的整合需求。我們會使用 GroupDocs.Signature for Java，它讓將自訂加密整合到文件簽署工作流程變得相當直接。

你將學到的內容：

• 為什麼一開始就會想要自訂加密
• XOR 加密的運作原理（以簡單英文說明）
• 使用 GroupDocs.Signature for Java 的逐步實作
• 真實案例與安全性考量
• 常見錯誤與避免方式

快速回答

• 什麼是 XOR 加密？ 一種對稱運算，使用金鑰翻轉位元；使用相同金鑰加密兩次即可還原原始資料。
• 什麼時候該使用自訂加密？ 為了相容遺留系統、效能關鍵的混淆或學習目的——絕非保護敏感資料。
• 本教學使用哪個函式庫？ GroupDocs.Signature for Java（v23.12 或更新版本）。
• 需要授權嗎？ 免費試用可用於測試；正式上線需購買完整授權。
• 之後可以把 XOR 換成 AES 嗎？ 可以——只要替換 encrypt/decrypt 的實作，介面 IDataEncryption 保持不變。

如何使用 XOR 加密 Java

XOR 加密是一個經典的 java xor example，展示了對稱加密的核心概念。透過本教學，你將看到如何將自訂演算法插入 GroupDocs.Signature Java 工作流程，從而完全掌控簽署資料的保護方式。

為什麼自訂加密很重要

在寫程式碼之前，先談談為什麼你可能需要自訂加密。

大多數函式庫（包括 GroupDocs）都內建加密選項。那麼為什麼還要自己寫？以下是自訂加密合理的實務情境：

遺留系統整合：你必須與舊系統溝通，該系統只接受特定的加密方式。整個系統改造不可行，因此必須配合它的加密方法。

效能優化：AES 等標準演算法安全但計算成本較高。對於非敏感資料（例如浮水印或內部文件 ID）只需要基本混淆時，輕量級的自訂方式能顯著提升效能。

專屬需求：某些產業或客戶因合規或相容性要求，必須使用特定的加密實作。

學習與彈性：了解自訂加密的實作過程，可讓你更好評估安全方案，並因應獨特需求做出調整。

不過（這點很重要），自訂加密絕不應是保護敏感資料的首選。凡涉及個人資訊、金融資料或受法規管制的內容，請使用已驗證的演算法，如 AES‑256。自訂加密最適合用於你了解其安全權衡的特定情境。

理解 XOR：基礎概念

如果你不熟悉 XOR（Exclusive OR），別擔心——它是最簡單的加密概念之一。

XOR 是一種二元運算，比較兩個位元，若不同則回傳 1，相同則回傳 0：

• 0 XOR 0 = 0
• 0 XOR 1 = 1
• 1 XOR 0 = 1
• 1 XOR 1 = 0

XOR 之所以適合加密，是因為它 對稱：使用金鑰對資料做 XOR，之後再以相同金鑰 XOR 結果，即可還原原始資料。就像同一把鑰匙同時能鎖也能解鎖。

以下是一個簡單的 java xor example：

Original data: 5 (binary: 0101)
Key: 3 (binary: 0011)
Encrypted: 5 XOR 3 = 6 (binary: 0110)
Decrypted: 6 XOR 3 = 5 (binary: 0101) ← We're back!

實務上，我們會將每個位元組與金鑰值做 XOR。此方法快速、記憶體需求低，非常適合示範自訂加密概念。請記住：使用單一位元組金鑰的 XOR 很容易被具備基礎密碼學知識的人破解。僅適用於混淆，不適合作為保護手段。

前置條件

在使用 GroupDocs.Signature for Java 實作自訂加密之前，請先確認以下項目：

必要的函式庫與相依性

• GroupDocs.Signature for Java：版本 23.12 或更新（本教學所使用的 API）
• Java Development Kit：JDK 8 以上（建議生產環境使用 JDK 11+）

環境設定需求

• IntelliJ IDEA、Eclipse 或支援 Java 的 VS Code 等 IDE
• Maven 或 Gradle 進行相依性管理（以下範例同時支援兩者）

知識前置條件

• 能熟練撰寫 Java 程式（了解類別、方法與介面）
• 基本的加密概念（已在前面說明 XOR）
• 了解位元組陣列與位元運算較佳，但非必須

以上都備妥了嗎？太好了！接下來設定 GroupDocs。

設定 GroupDocs.Signature for Java

將 GroupDocs 加入專案相當簡單。請依照你的建置工具選擇：

Maven

<dependency>
    <groupId>com.groupdocs</groupId>
    <artifactId>groupdocs-signature</artifactId>
    <version>23.12</version>
</dependency>

Gradle

implementation 'com.groupdocs:groupdocs-signature:23.12'

直接下載
如果你偏好手動下載（或無法使用建置工具），請從 GroupDocs.Signature for Java releases 取得 JAR，並加入專案的 classpath。

取得授權步驟

GroupDocs 並非免費，但提供試用機制：

1. 免費試用：下載並使用全部功能，但會有水印與評估限制
2. 臨時授權：申請臨時授權以獲得完整功能（適合概念驗證）
3. 購買授權：正式上線前購買正式授權

基本初始化與設定

以下是最簡單的 GroupDocs 初始化範例——所有範例都會以此為基礎：

import com.groupdocs.signature.Signature;

class InitializeGroupDocs {
    public static void main(String[] args) {
        Signature signature = new Signature("path/to/your/document");
        // Additional setup and operations can be performed here.
    }
}

很簡單吧？Signature 物件是所有文件簽署操作的主要介面。接下來我們讓它真的加密一些資料。

實作指南

自訂 XOR 加密功能

現在進入實作重點。我們將建立一個自訂加密類別，讓 GroupDocs 在需要加密簽署資料時使用。

步驟 1：實作 IDataEncryption 介面

GroupDocs 期待加密處理器實作 IDataEncryption 介面。只要實作這些方法，GroupDocs 就會知道如何使用你的加密：

import com.groupdocs.signature.domain.extensions.encryption.IDataEncryption;

class CustomXOREncryption implements IDataEncryption {
    private int auto_Key;
    
    public final int getKey() {
        return auto_Key;
    }
    
    // Additional methods for encryption and decryption will be implemented here.
}

說明：我們定義了一個類別，承諾提供加密/解密功能。auto_Key 欄位儲存 XOR 金鑰值（即要 XOR 的數字）。getKey() 方法讓其他程式碼可以檢查目前使用的金鑰。

步驟 2：定義加密與解密方法

接下來是實際的加密邏輯。因為 XOR 是對稱的（記得嗎？），加密與解密其實是同一個運算：

class CustomXOREncryption {
    private int auto_Key;

    public byte[] encrypt(byte[] data) {
        if (auto_Key == 0 || data == null) return data;
        
        byte[] result = new byte[data.length];
        for (int i = 0; i < data.length; i++) {
            result[i] = (byte) (data[i] ^ auto_Key);
        }
        return result;
    }

    public byte[] decrypt(byte[] encryptedData) {
        // Since XOR is symmetric, use the same method as encryption
        return encrypt(encryptedData);
    }
}

拆解說明：

• 檢查金鑰是否為 0（無效）或資料是否為 null（避免當機）
• 建立新位元組陣列以存放加密結果
• 逐一遍歷輸入資料的每個位元組
• 每個位元組與金鑰做 XOR：data[i] ^ auto_Key
• 必須使用 (byte) 轉型，因為 Java 中 XOR 會回傳 int，但我們需要位元組

XOR 的美妙之處在於：decrypt() 只要再次呼叫 encrypt() 即可。相同的運算既能加密也能解密！

金鑰設定選項

auto_Key：你的加密金鑰。需要注意的要點：

• 必須非零（XOR 0 等於不變）
• 單位元組 XOR 建議使用 1‑255 之間的值（超過 255 只會取低 8 位）
• 實務上可透過環境變數或設定檔讓金鑰可配置
• 正式環境應使用更完善的金鑰管理機制

設定範例：

CustomXOREncryption encryption = new CustomXOREncryption();
encryption.setKey(42); // Any non-zero value works

常見實作錯誤

以下列出我（以及其他開發者）常犯的錯誤，幫助你省下除錯時間：

錯誤 #1：忘記設定金鑰

CustomXOREncryption encryption = new CustomXOREncryption();
// Oops! Never called setKey(), so auto_Key is 0
byte[] encrypted = encryption.encrypt(myData); // Returns data unchanged!

修正：使用加密前務必先初始化金鑰。

錯誤 #2：未處理 null 資料
若缺少 if (data == null) return data; 檢查，最糟情況會拋出 NullPointerException。

錯誤 #3：誤以為 XOR 很安全
此加密極易被破解。只適合混淆，千萬別用於保護機密資料。

錯誤 #4：解密時使用錯誤金鑰
因為解密必須使用相同金鑰，金鑰遺失或變更會導致資料永久無法還原。正式環境應有金鑰備份與管理機制。

安全性考量

讓我們坦白談談安全性，因為這非常重要：

XOR 加密絕不適合保護敏感資料

千萬別低估它的危險性。單位元組 XOR 在幾秒鐘內就能被任何具備基礎密碼學知識的人破解。原因如下：

1. 頻率分析 – 若攻擊者了解資料格式（通常會），即可猜測常見位元組，進而推算金鑰。
2. 已知明文攻擊 – 若攻擊者掌握部分明文，只要將明文與密文 XOR，即可直接得到金鑰。
3. 暴力破解 – 金鑰只有 255 種可能，毫秒級即可測完。

何時適合使用 XOR 加密：

• 混淆非敏感的內部識別碼
• 快速處理快取鍵或暫存資料
• 學習加密概念
• 符合使用 XOR 的遺留系統需求
• 效能關鍵且資料安全已在其他層面處理的情境

何時應使用正式加密：

• 個人資訊（姓名、電子郵件、地址）
• 金融資料
• 醫療資訊
• 認證憑證
• 任何受 GDPR、HIPAA、PCI‑DSS 等法規管制的資料

更佳的替代方案：

• AES‑256 – 業界標準，安全性與效能兼具
• RSA – 適合加密少量資料（如金鑰本身）
• ChaCha20 – 現代對稱演算法，在行動裝置上有時更快

好消息是，我們使用的 IDataEncryption 介面在任何加密演算法下都能保持相同使用方式。只要把 XOR 的 encrypt()、decrypt() 改成 AES 的實作即可。

實務應用

了解「什麼」與「為什麼」之後，來看看實際會用到的情境：

1. 安全的文件簽署工作流程

假設你在建置合約管理系統，文件需要數位簽署，而簽署的中繼資料（簽署者 ID、時間戳、部門）在儲存前需要做基本混淆：

Signature signature = new Signature("contract.pdf");
CustomXOREncryption encryption = new CustomXOREncryption();
encryption.setKey(73); // Configure your key

// GroupDocs will use your encryption for signature data
// (Actual integration depends on specific GroupDocs API methods)

實際好處：資料庫不會直接存放明文中繼資料，降低被爬蟲或日誌意外洩漏的風險。

2. 資料完整性驗證

你可以利用自訂加密作為輕量級的完整性檢查。將已知值加密後與文件一起儲存，之後解密驗證即可：

String integrityToken = "VALID_SIGNATURE_2025";
byte[] encrypted = encryption.encrypt(integrityToken.getBytes());
// Store encrypted with document...
// Later, decrypt and compare to verify nothing changed

這不是加密等級的完整性（若需更高保證請使用 HMAC），但足以偵測意外損毀。

3. 與遺留系統整合

這是最常見的實務需求。你正在將舊系統升級為現代應用，但必須與 2000 年代初的系統交換 XOR 加密的資料：

// Old system expects data encrypted with XOR key 42
CustomXOREncryption legacyEncryption = new CustomXOREncryption();
legacyEncryption.setKey(42);

// Encrypt data before sending to legacy system
byte[] dataForOldSystem = legacyEncryption.encrypt(modernData);
sendToLegacyAPI(dataForOldSystem);

你不是因為 XOR 更好而選它，而是因為對方系統只能理解 XOR。

效能考量

使用輕量級加密（如 XOR）的主要原因之一是效能。但即使是簡單運算，若處理不當仍可能成為瓶頸。以下列出需要注意的地方：

效能最佳化

小資料（< 1 KB） – 上述 XOR 實作已足夠，開銷可忽略不計。

大文件（> 10 MB） – 建議採取以下優化：

1. 分塊處理 – 不要一次 XOR 整個文件，改以 4 KB 為單位分段處理。
2. 平行運算 – 對超大型檔案，可將工作分配給多個執行緒。
3. 避免不必要的複製 – 目前的實作會產生新位元組陣列，會暫時加倍記憶體使用。

// More memory‑efficient for large data
public void encryptInPlace(byte[] data) {
    if (auto_Key == 0 || data == null) return;
    
    for (int i = 0; i < data.length; i++) {
        data[i] = (byte) (data[i] ^ auto_Key);
    }
}

資源使用指引

記憶體 – 目前的實作需要：

• 原始資料的記憶體
• 加密後資料的記憶體（大小相同）
• 處理過程中的暫存物件

以 50 MB 文件為例，加密期間大約會佔用 100 MB 記憶體。

CPU – XOR 極快，對小文件（< 100 KB）通常在 1 ms 以內完成。以下為大致估算（依硬體與 JVM 優化程度而異）：

• 1 MB ≈ 10 ms
• 10 MB ≈ 100 ms
• 100 MB ≈ 1 s

Java 記憶體管理最佳實踐

在 Java 中處理加密時，請留意：

1. 清除敏感資料 – 完成金鑰或解密資料後，務必手動清除：

   Arrays.fill(decryptedData, (byte) 0); // Overwrite with zeros
   

2. 使用 try‑with‑resources – 確保串流自動關閉：

   try (FileInputStream fis = new FileInputStream("encrypted.dat")) {
       // Process data
   } // Automatically closed
   

3. 監控 Heap 使用 – 若同時處理多份文件，可考慮 -XX:+UseG1GC 以提升 GC 效能。
4. 避免使用 String 處理二進位資料 – 千萬不要把加密後的位元組轉成 String 再轉回，會造成資料損毀，應保持為 byte[]。

常見問題排除

問題 1：「解密後變成雜訊」

症狀 – 解密後得到看似隨機的位元組，而非原始資料。

原因 – 解密金鑰不一致、資料在儲存/傳輸過程受損，或在途中將位元組轉成 String。

解決方式 – 確認使用完全相同的金鑰，並在整個流程中保持 byte[]。

問題 2：「加密時拋出 NullPointerException」

症狀 – 呼叫 encrypt() 時發生 NullPointerException。

原因 – 傳入的資料為 null。

解決方式 – 如實作範例所示，在 encrypt/decrypt 方法內先檢查 null。

問題 3：「看起來沒有加密效果」

症狀 – 加密後的資料與明文相同。

原因 – 金鑰為 0 或根本未設定。

解決方式 – 在開發階段加入斷言檢查：

assert auto_Key != 0 : "Encryption key must be set!";

問題 4：「處理大型檔案時 OutOfMemoryError」

症狀 – 加密大型文件時應用程式崩潰。

原因 – 一次將整個檔案載入記憶體。

解決方式 – 改用串流或分塊處理：

try (FileInputStream in = new FileInputStream(path);
     FileOutputStream out = new FileOutputStream(encryptedPath)) {
    byte[] buffer = new byte[4096];
    int bytesRead;
    while ((bytesRead = in.read(buffer)) != -1) {
        encryptInPlace(buffer, 0, bytesRead);
        out.write(buffer, 0, bytesRead);
    }
}

結論

我們已涵蓋相當多的內容！現在你已掌握 如何加密 Java，以 XOR 為學習範例，並將其整合至 GroupDocs.Signature。也了解了何時該使用自訂加密、何時不該使用。

重點回顧

• 自訂加密適用於特定情境（遺留系統、效能需求、學習）
• XOR 方便理解原理，但不適合保護機密資料
• GroupDocs.Signature 透過 IDataEncryption 介面提供簡易整合方式
• 實作前務必評估安全性風險

後續建議

1. 實作 AES 加密 – 將 CustomXOREncryption 改寫為使用 AES（Java javax.crypto 套件即可）。
2. 加入金鑰輪替 – 建置可在不中斷服務的金鑰更換機制。
3. 探索更多 GroupDocs 功能 – 簽章驗證、範本建立、多簽章工作流程等。

掌握了這個「實作介面提供自訂行為」的模式，你將能在 GroupDocs API 中自由客製化更多功能。

現在去加密吧！（但請先確保在升級到真正的加密演算法前，不要用於任何必須保密的資料。）

FAQ 區

1. 如何選擇合適的 XOR 金鑰？

對於 XOR 而言，只要非零整數皆可，但金鑰本身並不提供安全性。若真的在意安全，請改用 AES 或其他驗證過的演算法。若僅用於混淆，隨機挑選 1‑255 之間的值，並安全地存放於設定檔或環境變數。

2. 可以在執行期間動態變更 XOR 金鑰嗎？

可以，直接呼叫 setKey() 並傳入新值。但要注意：使用舊金鑰加密的資料仍須以舊金鑰解密。若更換金鑰，必須重新加密既有資料或記錄每筆資料使用的金鑰。這也是金鑰管理在密碼學中的重要議題。

3. 有哪些 XOR 的替代方案？

學習或非安全用途：凱撒密碼、ROT13、Base64（僅混淆不加密）。
正式安全需求：AES‑256（對稱）、RSA‑2048+（非對稱）、ChaCha20（現代對稱）。Java 的 javax.crypto 已支援上述演算法。

4. GroupDocs.Signature 在處理大型檔案加密時的表現如何？

GroupDocs 已針對大型檔案做了串流優化。但若你的自訂加密實作一次載入全部資料，仍可能成為瓶頸。建議對超過 50 MB 的檔案實作分塊加解密，以降低記憶體佔用。

5. 能將此功能整合到 Web 應用程式嗎？

完全可以！使用 Spring Boot、Jakarta EE 或任意 Java Web 框架皆可。幾點建議：

• 將加密類別註冊為 singleton 或 application‑scoped bean
• 金鑰存放於環境變數或外部安全配置，切勿硬編碼
• 在資料離開應用伺服器前先加密
• 多使用者同時上傳大型文件時，留意記憶體與執行緒使用

Spring Boot 整合範例：

@Component
public class EncryptionService {
    private CustomXOREncryption encryption;
    
    public EncryptionService(@Value("${app.encryption.key}") int key) {
        this.encryption = new CustomXOREncryption();
        this.encryption.setKey(key);
    }
    // Use in your controllers...
}

6. 可以在 PDF 文件上使用嗎？

可以！GroupDocs.Signature 支援 PDF、Word、Excel、影像等多種格式。加密發生在簽署資料層面，與檔案類型無關，所有支援的格式皆可使用。

7. 若金鑰遺失會怎樣？

對稱加密（如 XOR）若金鑰遺失，資料將無法復原，沒有任何備援機制。正式系統應具備：

• 金鑰備份機制
• 金鑰託管（Escrow）以符合法規要求
• 金鑰輪替政策與交叉期間
• 金鑰使用紀錄與稽核

這也是使用成熟加密函式庫的好處——它們通常內建金鑰管理工具。

參考資源

• GroupDocs.Signature for Java Documentation
• API Reference
• Latest Release Download
• Purchase License
• Free Trial
• Temporary License Request
• GroupDocs Support Forum

最後更新日期： 2026-02-18
測試環境： GroupDocs.Signature 23.12 for Java
作者： GroupDocs