Java FileNotFoundException 反覆踩坑：Windows 隱藏 Unicode 控制字符 (LRE/U+202A) 導致路徑解析失敗

Java FileNotFoundException 反覆踩坑：Windows 隱藏 Unicode 控制字符 (LRE/U+202A) 導致路徑解析失敗

現象復現

• 從 Windows 文件屬性「位置」複製路徑，粘貼到 IDE/Eclipse 字符串字面量。
• 代碼：new File("C:\\Users\\Admin\\Documents\\data.txt") 顯示無誤。
• 運行拋出 java.io.FileNotFoundException，但文件明確存在。
• 同目錄下甚至出現「兩個同名文件」的怪象 (實為同一文件，資源管理器顯示異常)。

根因深挖：隱形 Unicode 方向控制字符

Windows 為支持 RTL (右到左) 語言 (阿拉伯語、希伯來語)，在文件路徑中自動插入 LRE (Left-to-Right Embedding, U+202A) 或 RLE (U+202B) 等雙向文本控制字符。這些字符：

• 不可见，不佔寬 (零寬)。
• 複製路徑時會被一同複製進剪貼板。
• Java File 構造器將其視為合法路徑字符，導致實際路徑不匹配。
• 資源管理器渲染時按雙向算法重排，造成「雙文件」視覺假象。

驗證方法：HTML/JS 字符碼點檢測

<!DOCTYPE html>
<html><body>
<script>
    // 將複製的路徑字符串粘貼到此處
    const raw = "C:\\Users\\Admin\\Documents\\data.txt"; // 實際粘貼內容
    for (let i = 0; i < raw.length; i++) {
        console.log(i, raw[i], raw.charCodeAt(i).toString(16).toUpperCase().padStart(4,'0'));
    }
</script>
</body></html>

輸出中若出現 202A (LRE) 或 202B (RLE) 即確認攜帶控制字符。

解決方案

1. 源頭規避：在資源管理器地址欄點擊選中路徑 (而非屬性對話框)，或使用「複製地址」功能 (Win10+)。
2. IDE 清洗：粘貼後在編輯器中全選重新鍵入關鍵路徑段，或使用正則替換：str.replace(/[\u200E\u200F\u202A-\u202E]/g, '')。
3. 代碼層面清洗 (推薦)：

public static String sanitizePath(String raw) {
    // 移除所有雙向控制字符: LRE(202A) RLE(202B) PDF(202C) LRO(202D) RLO(202E) LRM(200E) RLM(200F)
    return raw.replaceAll("[\\u200E\\u200F\\u202A-\\u202E]", "");
}

// 使用
String raw = "C:\\Users\\Admin\\Documents\\data.txt"; // 含隱形字符
File file = new File(sanitizePath(raw));

Notepad++ / VS Code 可視化檢查

• Notepad++：編碼 → 以 UTF-8 無 BOM 編碼 → 視圖 → 顯示符號 → 顯示所有字符，控制字符顯示為 LRE/RLE。
• VS Code：安裝 Render Whitespace / Control Characters 擴展，或設置 "editor.renderControlCharacters": true。

Windows 文件命名規範補充

總結

Windows 路徑複製帶入的 Unicode 雙向控制字符 (U+202A LRE 等) 是 Java FileNotFoundException 反覆發生的隱形殺手。通過 源頭規避複製源、編輯器可視化檢測、代碼統一清洗 三重防線，可徹底根治此類「明明文件存在卻找不到」的靈異問題。建議團隊將路徑清洗工具方法納入公共庫，新員工入職必講此坑。