## Case #3: 中文模式下臨時英文輸入維持小寫

### Problem Statement
業務場景：中文模式打字時，按住 SHIFT 原期望出小寫英文以維持節奏，但 Vista IME 變更為大寫，打字不順、錯誤增多。
技術挑戰：IME 沒有提供「臨時英文小寫」開關；需攔截鍵位而不影響其他程式。
影響範圍：程式碼輸入、聊天、表單欄位填寫。
複雜度：低-中

### Root Cause Analysis
直接原因：
1. 新 IME 將 SHIFT 視為大寫修飾鍵。
2. 缺少臨時英文小寫模式選項。
3. 鍵位行為跨應用一致，難精準例外。

深層原因：
- 架構：TSF 將修飾鍵行為統一處理。
- 技術：缺少 API 細緻控制臨時英文行為。
- 流程：未建立個人化鍵盤層策略。

### Solution Design
解決策略：以 AHK 在 IME 開啟且未按 CapsLock 時，攔截 +[A..Z] 改送小寫；在特定應用（IDE/Word）允許原生行為。

實施步驟：
1. 鍵位攔截條件建置
- 細節：判斷 IME 啟用且 CapsLock 關閉時生效。
- 資源：AutoHotkey
- 時間：30 分鐘

2. 例外清單
- 細節：對需要大寫的應用（如 Office）不啟用規則。
- 資源：App 名稱清單
- 時間：15 分鐘

3. 使用者驗證與調整
- 細節：收集誤觸案例修正規則。
- 資源：Usage log
- 時間：1 天

關鍵程式碼：
```ahk
#If IsIMEOn() && !GetKeyState("CapsLock", "T") && !WinActive("ahk_exe WINWORD.EXE")
; 將 Shift + A..Z 轉小寫
+::return
+a::Send, a
+b::Send, b
; ... 其他字母類推，可用迴圈產生
#If

## Case #4: 注音選字時以 Backspace 取消（遊戲/即時通訊相容）

### Problem Statement
業務場景：原流程會以 Backspace 取消組字，但 Vista 注音選字狀態不支援，遊戲內（WoW）卡住，技能施放失敗。
技術挑戰：需精準判斷「組字態」再轉譯 Backspace -> ESC，避免誤刪字。
影響範圍：遊戲、通訊即時性。
複雜度：中

### Root Cause Analysis
直接原因：
1. 新 IME 在選字態對 Backspace 解讀為刪除音節而非取消。
2. 遊戲採 DirectInput/Raw Input，與 IME 互動複雜。
3. 無標準 API 公布組字態。

深層原因：
- 架構：TSF/IME 與遊戲輸入堆疊的相容性。
- 技術：組字態偵測困難。
- 流程：遊戲場景未事先壓測 IME。

### Solution Design
解決策略：對指定遊戲視窗啟用規則，Backspace 優先送 ESC 取消，若無組字態回退再送 Backspace；並提供快速切換英/中模式避免組字。

實施步驟：
1. 遊戲視窗偵測
- 細節：鎖定 WoW.exe（或指定遊戲）窗口。
- 資源：AutoHotkey
- 時間：20 分鐘

2. Backspace 轉譯與回退
- 細節：先送 ESC，檢查剪貼板/輸入緩衝是否變更（簡化以時間延遲）。
- 資源：AHK
- 時間：30 分鐘

3. 快速語言切換
- 細節：為遊戲加 Ctrl+Space 強制英文模式宏。
- 資源：AHK
- 時間：10 分鐘

關鍵程式碼：
```ahk
#If WinActive("ahk_exe Wow.exe")
Backspace::
Send, {Esc}
Sleep 30
; 如需回退行為可選擇性補送 Backspace
; Send, {Backspace}
return

^Space:: ; 快速切英文
Send, ^{Space}
return
#If

## Case #5: Console 無法拖放檔案（UAC 隔離）下的高效率貼路徑

### Problem Statement
業務場景：Vista 後將檔案拖到命令提示字元輸入路徑行為失效（特別是 console 以系統管理員執行時），必須手動輸入完整路徑，效率大幅下降。
技術挑戰：UIPI（User Interface Privilege Isolation）阻止低完整性程序向高完整性視窗拖放；需建立替代路徑粘貼流程。
影響範圍：日常腳本、批次作業、開發調試。
複雜度：低

### Root Cause Analysis
直接原因：
1. Explorer（標準權限）無法向 Elevated console 投遞 drop。
2. Console 未提供可信通道接收 drop。
3. 使用者未優化路徑貼上與引號處理流程。

深層原因：
- 架構：UAC/UIPI 設計避免權限提升注入。
- 技術：拖放是跨程序訊息，受完整性等級限制。
- 流程：缺少替代操作 SOP（Copy as Path 等）。

### Solution Design
解決策略：建立「Copy as Path + 快速貼上 + 自動加引號」的標準流程；提升 Tab 補全使用率；必要時以 ConEmu/Console2 作為前端改善 UX。

實施步驟：
1. 使用 Copy as Path
- 細節：Shift + 右鍵 -> Copy as Path，確保含引號。
- 資源：Explorer 內建
- 時間：5 分鐘教學

2. Console 快速貼上
- 細節：啟用 QuickEdit，滑鼠右鍵貼上；或使用 Ctrl+V 的替代工具。
- 資源：Console 內容->選項
- 時間：3 分鐘

3. PowerShell 輔助處理引號
- 細節：處理引號重複與空白。
- 資源：PowerShell
- 時間：10 分鐘

4. 可選：ConEmu/Console2
- 細節：安裝與啟用拖放到非提權工作階段。
- 資源：ConEmu、Console2
- 時間：20-30 分鐘

關鍵程式碼：
```powershell
# 將剪貼簿的路徑規範化，避免重複引號
$path = Get-Clipboard
if ($path.StartsWith('"') -and $path.EndsWith('"')) { $path = $path.Trim('"') }
$norm = '"' + $path.Replace('"','""') + '"'
Set-Clipboard $norm

## Case #6: 保留拖放體驗：以 Console 前端（ConEmu/Console2）替代

### Problem Statement
業務場景：使用者依賴拖放至終端；UAC 導致失效。希望保留 drag&drop 使用體驗。
技術挑戰：需在相同完整性等級下接收 drop，並安全地橋接至命令。
影響範圍：開發/測試作業流程。
複雜度：中

### Root Cause Analysis
直接原因：
1. Elevated console 無法接收低權限拖放。
2. 傳統 cmd.exe 缺少拖放橋接。
3. 無建制的 drop->command pipeline。

深層原因：
- 架構：終端與檔案總管權限隔離。
- 技術：需要前端容器提供 drop 事件處理。
- 流程：權限與 UX 沒分離規劃。

### Solution Design
解決策略：以 ConEmu/Console2 作為終端前端，在非提權工作階段完成拖放，必要命令以按鍵瞬時提權執行。

實施步驟：
1. 安裝 ConEmu/Console2
- 細節：設定 cmd/powershell 作為 shell，啟用 drop->paste path。
- 資源：ConEmu/Console2
- 時間：30 分鐘

2. 建立「瞬時提權」按鍵
- 細節：綁定快捷鍵呼叫 elevate 指令（見 Case #8）。
- 資源：AHK/內建宏
- 時間：20 分鐘

3. 流程訓練
- 細節：正常輸入/拖放皆在非提權；需要 admin 時才 elevate 單指令。
- 資源：SOP
- 時間：30 分鐘

關鍵程式碼：
```ahk
; 在 ConEmu 中綁定 Ctrl+Enter -> Elevate 當前行命令（搭配 elevate.vbs）
^Enter::
Send, ^c
Run, wscript.exe "%A_ScriptDir%\elevate.vbs" %Clipboard%
return

## Case #7: 「只在需要時」提權：Elevate 單指令的 sudo 體驗

### Problem Statement
業務場景：UAC 頻繁打斷；但關閉 UAC 風險高。希望保留標準使用者環境，僅特定命令以管理者執行。
技術挑戰：以快捷操作達成「當次提權」，又不破壞拖放與一般作業。
影響範圍：系統維運、開發調試。
複雜度：中

### Root Cause Analysis
直接原因：
1. 持續在 Elevated console 下工作導致拖放/相容問題。
2. 沒有現成 sudo 體驗。
3. 使用者為求省事關閉 UAC（原文）。

深層原因：
- 架構：Windows 的提權模型與 *nix sudo 差異。
- 技術：需要 ShellExecute runas、任務排程或 COM Elevation。
- 流程：缺少提權 SOP。

### Solution Design
解決策略：建立 elevate.vbs（或 PowerShell 函數）包裝 ShellExecute "runas"，以「e」前綴執行需 admin 的命令，平時用標準權限終端。

實施步驟：
1. 建置 elevate.vbs
- 細節：ShellExecute cmd /c <args>，Verb=runas。
- 資源：wscript
- 時間：10 分鐘

2. 建立批次包裝 e.cmd
- 細節：e <command> 轉交給 elevate.vbs。
- 資源：cmd
- 時間：10 分鐘

3. PowerShell 函數
- 細節：Start-Process -Verb RunAs 包裝。
- 資源：PowerShell
- 時間：10 分鐘

關鍵程式碼：
```vbscript
' elevate.vbs
Set sh = CreateObject("Shell.Application")
args = ""
For i = 0 To WScript.Arguments.Count-1
  args = args & WScript.Arguments(i) & " "
Next
sh.ShellExecute "cmd.exe", "/c " & args, "", "runas", 1

## Case #8: 以工作排程（Task Scheduler）實現「零提示」的固定提權腳本

### Problem Statement
業務場景：固定腳本（檔案整理、hosts 更新）每次執行都彈出 UAC。希望一鍵執行且不彈。
技術挑戰：在不關閉 UAC 的前提下達成。
影響範圍：IT 維運、例行工作。
複雜度：中

### Root Cause Analysis
直接原因：
1. 腳本需要寫系統位置或修改登錄。
2. 每次手動 runas 或點擊提示，流程冗長。
3. 缺少標準化「高權限排程」。

深層原因：
- 架構：UAC 設計即阻斷靜默提權。
- 技術：需使用 Task Scheduler 的 Highest Privileges。
- 流程：未把常用腳本納入排程庫。

### Solution Design
解決策略：建立 on-demand 觸發的排程項，勾選「以最高權限執行」，再為其建立捷徑或熱鍵。

實施步驟：
1. 建立排程
- 細節：schtasks /create /SC ONDEMAND /RL HIGHEST /TR "wscript your.vbs"
- 資源：schtasks
- 時間：10 分鐘

2. 快速啟動
- 細節：捷徑目標指向 schtasks /run；配桌面/熱鍵。
- 資源：捷徑
- 時間：5 分鐘

3. 版本控管
- 細節：腳本改動後自動更新排程。
- 資源：批次
- 時間：15 分鐘

關鍵程式碼：
```cmd
schtasks /create /tn "ArchiveJob" /sc ONDEMAND /RL HIGHEST /tr "wscript.exe C:\Tools\archive.vbs" /f
schtasks /run /tn "ArchiveJob"

## Case #9: 將 PowerToys「Image Resizer」以 WIC 重製（.NET/WPF）

### Problem Statement
業務場景：原先仰賴 PowerToys Image Resizer 進行批次縮圖；在 Vista 因影像管線改用 WPF/WIC，舊 PowerToy 不相容。
技術挑戰：需快速打造替代工具，支援常見格式、保留 EXIF、批次處理。
影響範圍：影像工作流、內容發佈。
複雜度：中

### Root Cause Analysis
直接原因：
1. Vista 影像棧改為 WIC，舊工具（GDI+/殼層擴充）失效。
2. RAW 解碼改以 WIC Codec。
3. 舊工具未維護。

深層原因：
- 架構：影像處理標準化（codec 模型）。
- 技術：需改用 System.Windows.Media.Imaging。
- 流程：未及時替換工具鏈。

### Solution Design
解決策略：用 .NET 3.0/3.5 WPF 的 WIC 封裝（BitmapDecoder/BitmapEncoder）重寫縮圖工具，保留 EXIF Orientation，支援 JPEG/PNG/WMP（HD Photo）。

實施步驟：
1. 建專案與核心轉檔器
- 細節：以 BitmapDecoder/TransformedBitmap 縮放，Encoder 寫檔。
- 資源：.NET 3.0/3.5
- 時間：4 小時

2. EXIF 保留與旋轉
- 細節：讀取 BitmapMetadata，按 Orientation 旋轉。
- 資源：WIC Metadata
- 時間：2 小時

3. 批次與 CLI
- 細節：支援目錄遞迴批次、尺寸參數。
- 資源：Console app
- 時間：2 小時

關鍵程式碼：
```csharp
using System;
using System.IO;
using System.Windows.Media;
using System.Windows.Media.Imaging;

class WicResizer {
  static void Main(string[] args) {
    var src = args[0];
    var dst = args[1];
    var max = int.Parse(args[2]); // max dimension
    var decoder = BitmapDecoder.Create(new Uri(src),
      BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.OnLoad);
    var frame = decoder.Frames[0];
    var scale = Math.Min((double)max / frame.PixelWidth, (double)max / frame.PixelHeight);
    if (scale > 1) scale = 1;
    var tb = new TransformedBitmap(frame, new ScaleTransform(scale, scale, 0, 0));

    var encoder = new JpegBitmapEncoder { QualityLevel = 90 };
    encoder.Frames.Add(BitmapFrame.Create(tb, frame.Metadata as BitmapMetadata, frame.ColorContexts, frame.Thumbnail));
    using (var fs = File.OpenWrite(dst)) encoder.Save(fs);
  }
}

## Case #10: 使用 WIC 讀取 RAW（NEF/CR2）並進行歸檔

### Problem Statement
業務場景：自製「歸檔」程式依賴 RAW Image Viewer wrapper 讀取 Canon RAW；Vista 後該 PowerToy 不相容導致工具失效。
技術挑戰：需改用 WIC 且依賴相機廠商的 WIC Codec；同時要向下容忍未安裝編解碼器的環境。
影響範圍：影像歸檔、備份、預覽。
複雜度：高

### Root Cause Analysis
直接原因：
1. 影像棧切換導致舊 wrapper 失效。
2. RAW 格式需對應 WIC Codec（Nikon 提供，Canon 需等待）。
3. 現場環境 codec 安裝狀態不一。

深層原因：
- 架構：WIC codec 化，統一入口。
- 技術：RAW 處理需正確使用 WIC 與 Metadata。
- 流程：工具對外部 codec 依賴未管理。

### Solution Design
解決策略：以 WIC 讀取 RAW 縮圖/預覽與 Metadata；提供 codec 檢查與導引安裝；未裝情況使用外部解碼（libraw/dcraw）降級。

實施步驟：
1. WIC 讀取 RAW
- 細節：BitmapDecoder.Create -> 取 Frames/Metadata。
- 資源：.NET WIC API
- 時間：4 小時

2. Codec 檢測與指引
- 細節：當解碼失敗提示下載 Nikon/Canon WIC Codec。
- 資源：下載連結/檢測邏輯
- 時間：2 小時

3. 降級解碼
- 細節：呼叫外部 libraw/dcraw 產生臨時 JPEG。
- 資源：libraw/dcraw
- 時間：4 小時

關鍵程式碼：
```csharp
try {
  var dec = BitmapDecoder.Create(new Uri(path),
    BitmapCreateOptions.IgnoreColorProfile, BitmapCacheOption.OnLoad);
  var preview = dec.Thumbnail ?? dec.Frames[0];
  // 儲存預覽
  var enc = new JpegBitmapEncoder { QualityLevel = 85 };
  enc.Frames.Add(BitmapFrame.Create(preview));
  using (var fs = File.OpenWrite(outJpeg)) enc.Save(fs);
} catch (NotSupportedException ex) {
  // 提示安裝 WIC Codec 或走外部解碼
  Console.WriteLine("RAW codec not found. Falling back to libraw...");
  // 呼叫外部工具
}

## Case #11: 以 WIC 實作 HD Photo（JPEG XR）轉檔與體積對比

### Problem Statement
業務場景：Vista 引入 HD Photo（Windows Media Photo / JPEG XR），希望驗證在同等視覺品質下的體積優勢，用於網站/歸檔。
技術挑戰：選擇合適 Encoder、品質參數、與瀏覽端相容性。
影響範圍：儲存成本、傳輸效能。
複雜度：中

### Root Cause Analysis
直接原因：
1. 舊流程僅使用 JPEG。
2. 未測試 WMP Encoder 的品質/體積折衷。
3. 客戶端支援不明確。

深層原因：
- 架構：Vista/WIC 支援 WMP Encoder。
- 技術：需要實測 PSNR/SSIM 與檔案大小。
- 流程：缺少格式評估步驟。

### Solution Design
解決策略：以 WmpBitmapEncoder 測試不同品質參數，統計體積與品質；保留可回退為 JPEG 的流程。

實施步驟：
1. 建立轉檔器
- 細節：支援 JPEG、WMP（JPEG XR）輸出。
- 資源：.NET WIC
- 時間：2 小時

2. 批次測試
- 細節：對 100 張圖測試不同品質參數。
- 資源：資料集
- 時間：2 小時

3. 報告與決策
- 細節：SSIM/體積比較。
- 資源：分析腳本
- 時間：2 小時

關鍵程式碼：
```csharp
var enc = new WmpBitmapEncoder(); // HD Photo / JPEG XR
enc.ImageQualityLevel = 0.8; // 0..1
enc.Frames.Add(BitmapFrame.Create(bitmapSource));
using (var fs = File.OpenWrite(dst)) enc.Save(fs);

## Case #12: 為影像處理工具導入並檢查相機 WIC Codec（NEF/CR2）

### Problem Statement
業務場景：使用 Nikon/Canon RAW；需在客戶端快速導入對應 WIC Codec。
技術挑戰：檢測是否安裝、版本、並引導安裝。
影響範圍：工作站布建、相容性。
複雜度：中

### Root Cause Analysis
直接原因：
1. RAW 讀取取決於廠商 WIC Codec。
2. 環境差異造成失敗。
3. 無自動檢查與導引。

深層原因：
- 架構：第三方 codec 依賴。
- 技術：需透過登錄或 WIC Factory 檢查。
- 流程：部署流程缺漏。

### Solution Design
解決策略：在啟動時檢查指定 Container/PixelFormat 的 Decoder 是否可建立；若無，提示下載網址與靜默安裝選項。

實施步驟：
1. 檢測可用解碼器
- 細節：嘗試建立 Decoder，捕捉 NotSupported。
- 資源：.NET WIC
- 時間：30 分鐘

2. 提示安裝與一鍵導引
- 細節：打開廠商下載頁或內網封裝。
- 資源：安裝包
- 時間：30 分鐘

3. 版本檢查
- 細節：比對檔案版本/登錄 CLSID。
- 資源：登錄查詢
- 時間：30 分鐘

關鍵程式碼：
```csharp
bool CanDecode(string path) {
  try {
    BitmapDecoder.Create(new Uri(path), BitmapCreateOptions.None, BitmapCacheOption.OnLoad);
    return true;
  } catch (NotSupportedException) { return false; }
}

## Case #13: 對 UAC 友善的檔案腳本（FileSystemObject）設計

### Problem Statement
業務場景：舊有 VBS/WSH 腳本用 FileSystemObject 操作系統目錄；UAC 讓流程受阻；AV 亦會誤報。
技術挑戰：按需提權、簽章、白名單、日誌化。
影響範圍：自動化任務、內控。
複雜度：中

### Root Cause Analysis
直接原因：
1. 腳本未提權即嘗試寫系統區。
2. 未簽章導致 AV 誤報。
3. 無白名單/路徑隔離。

深層原因：
- 架構：安全機制遲滯於舊流程。
- 技術：WSH 缺少 manifest。
- 流程：缺少安全信任鏈。

### Solution Design
解決策略：結合 Case #8 的排程高權限執行；腳本加簽；對 AV 加例外；操作限縮到專屬資料夾。

實施步驟：
1. 提權執行
- 細節：Task Scheduler Highest Privileges。
- 時間：30 分鐘

2. 加簽
- 細節：使用企業代碼簽章憑證簽 .vbs。
- 時間：30 分鐘

3. AV 白名單
- 細節：指定簽章/路徑白名單。
- 時間：30 分鐘

關鍵程式碼：
```powershell
# 為腳本簽章（需要代碼簽章憑證）
Set-AuthenticodeSignature -FilePath .\archive.vbs -Certificate (Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert)[0]

## Case #14: 不關閉 UAC 的前提下最小化提示（應用分割與 manifest）

### Problem Statement
業務場景：原文作者最終關閉 UAC；但企業環境需要保留 UAC，同時減少提示。
技術挑戰：將需要提升的操作隔離到小工具，主程式維持 asInvoker。
影響範圍：內部工具、部署。
複雜度：中

### Root Cause Analysis
直接原因：
1. 主程式混雜高低權限功能。
2. manifest 要求 requireAdministrator 導致常駐高權限。
3. 提示頻繁。

深層原因：
- 架構：權限邊界未設計。
- 技術：缺少 per-task 提權。
- 流程：用戶體驗未優先。

### Solution Design
解決策略：主程式 manifest 設定 asInvoker；將高權限操作拆成微工具，當次呼叫以 runas 啟動。

實施步驟：
1. 調整主程式 manifest
- 細節：requestedExecutionLevel asInvoker。
- 時間：15 分鐘

2. 拆分高權限工具
- 細節：單一職責原則；CLI + 清楚參數。
- 時間：2 小時

3. 呼叫時提權
- 細節：ShellExecute runas。
- 時間：30 分鐘

關鍵程式碼：
```xml
<!-- app.manifest -->
<requestedExecutionLevel level="asInvoker" uiAccess="false" />

## Case #15: 以第三方 Dock/工具列取代「浮動工具列」行為

### Problem Statement
業務場景：原文提到內建工具列不能拖出工作列成浮動；影響快速啟動/常用資料夾 workflow。
技術挑戰：Vista 變更 deskband 行為；要保留浮動體驗需外掛。
影響範圍：桌面操作效率。
複雜度：低

### Root Cause Analysis
直接原因：
1. 工具列浮動行為受限。
2. Quick Launch 亦有差異。
3. 需求為視覺+動作可達性。

深層原因：
- 架構：Shell 變更 Deskband API 行為與 UI 政策。
- 技術：內建功能無法回復舊樣。
- 流程：缺乏替代 Dock 選型。

### Solution Design
解決策略：採用 RocketDock/True Launch Bar/Free Launch Bar 提供浮動/停駐工具列；同步導入鍵盤快速啟動作為備援。

實施步驟：
1. 安裝 Dock/工具列
- 細節：建立常用資料夾/捷徑 dock。
- 資源：RocketDock/TLB
- 時間：20-30 分鐘

2. 快速鍵綁定
- 細節：為常用項設熱鍵。
- 資源：Dock 設定
- 時間：15 分鐘

3. UI/UX 調整
- 細節：自動隱藏、位置與圖示大小。
- 資源：設定
- 時間：10 分鐘

關鍵設定：
```text
RocketDock:
- AutoHide: Enabled
- Position: Left/Right
- Run with Windows: On
- Hotkeys: Ctrl+Alt+<digit>

## Case #16: 以 PowerShell Profile 提升路徑與指令輸入效率（補 Console 拖放）

### Problem Statement
業務場景：缺少拖放後，頻繁輸入長路徑與複雜命令；需要提升輸入效率。
技術挑戰：改善補全、別名、快速導航。
影響範圍：日常終端工作。
複雜度：低

### Root Cause Analysis
直接原因：
1. cmd 補全面弱。
2. 使用者未配置 PowerShell Profile。
3. 無常用別名與函數。

深層原因：
- 架構：PS 可高度客製化但預設簡陋。
- 技術：需要腳本化設定。
- 流程：缺少個人化開發環境 SOP。

### Solution Design
解決策略：建立 PS Profile：啟用 MenuComplete、快速跳轉函數（pj/pushd/popd）、常用命令別名、Copy-QuotedPath。

實施步驟：
1. 建立 Profile
- 細節：New-Item -Path $PROFILE。
- 資源：PowerShell
- 時間：10 分鐘

2. 增加函數與別名
- 細節：pj、cqp 等。
- 資源：Profile 腳本
- 時間：20 分鐘

3. 測試與優化
- 細節：常用場景迭代。
- 資源：無
- 時間：1 天

關鍵程式碼：
```powershell
# $PROFILE
Set-PSReadlineKeyHandler -Key Tab -Function MenuComplete

function cqp { param($p) $q = '"' + ($p -replace '"','""') + '"'; Set-Clipboard $q; $q }

Set-Alias ll Get-ChildItem
function pj { param($path) Push-Location $path }
function up { 1..$args[0] | % { Pop-Location } }

## Case #17: 修復「RAW 歸檔」工具鏈中的 EXIF/旋轉與副檔名一致性

### Problem Statement
業務場景：歸檔工具在轉檔後，方向與 EXIF 未保留，或副檔名（.JPG/.jpg）混亂。
技術挑戰：WIC 正確處理 Orientation 與 Metadata 複寫；檔名規範。
影響範圍：媒資一致性、搜尋。
複雜度：中

### Root Cause Analysis
直接原因：
1. 忽略 EXIF Orientation 導致顯示錯向。
2. 未複寫核心 Metadata（DateTaken 等）。
3. 檔名規則未定義。

深層原因：
- 架構：Metadata 管線設計缺失。
- 技術：WIC Metadata API 未正確使用。
- 流程：檔案命名與欄位標準缺少。

### Solution Design
解決策略：轉檔時依 Orientation 旋轉像素，複寫關鍵 EXIF；統一檔名規則（YYYYMMDD_HHMMSS_序號）。

實施步驟：
1. Orientation 處理
- 細節：若 Orientation != 1 則套旋轉轉換。
- 資源：WIC
- 時間：1 小時

2. Metadata 複寫
- 細節：BitmapMetadata Clone/SetQuery。
- 資源：.NET
- 時間：1 小時

3. 命名規範
- 細節：以 DateTaken 格式化檔名；衝突加序號。
- 資源：程式碼
- 時間：1 小時

關鍵程式碼：
```csharp
var md = frame.Metadata as BitmapMetadata;
int orientation = (int)(md?.GetQuery("/app1/ifd/{ushort=274}") ?? 1); // EXIF Orientation
BitmapSource src = frame;
if (orientation == 6) src = new TransformedBitmap(src, new RotateTransform(90));
else if (orientation == 8) src = new TransformedBitmap(src, new RotateTransform(270));
// ...其他狀態
var copy = md?.Clone() as BitmapMetadata;
var enc = new JpegBitmapEncoder();
enc.Frames.Add(BitmapFrame.Create(src, copy, frame.ColorContexts, frame.Thumbnail));

## Case #18: 透過白名單降低 AV 對自製腳本的誤報與阻斷

### Problem Statement
業務場景：原文提到 AV（如 Norton）會對使用 FileSystemObject 的腳本恐嚇性提示；影響正常工作。
技術挑戰：在不下降防護的前提下降低誤報與提示。
影響範圍：自動化腳本、維運。
複雜度：低-中

### Root Cause Analysis
直接原因：
1. 腳本進行大量檔案操作被判定風險高。
2. 未簽章、來源不明。
3. 缺少白名單策略。

深層原因：
- 架構：企業端防毒策略偏嚴。
- 技術：缺少信任線索。
- 流程：未申請例外。

### Solution Design
解決策略：以簽章（見 Case #13）、固定路徑與雜湊白名單、排除掃描的工作資料夾；建立變更流程。

實施步驟：
1. 簽章與散列
- 細節：提供檔案雜湊（SHA256）與簽章。
- 時間：30 分鐘

2. 防毒白名單
- 細節：以 Publisher（簽章）/Path/Hash 白名單策略。
- 時間：30 分鐘（需 AV 管控台）

3. 例外申請流程
- 細節：維護變更紀錄與證據。
- 時間：1 小時

關鍵設定：
```text
AV Console:
- Application Control: Allow -> Publisher: <Your Company Code Signing CA>
- Exclusions: Path -> C:\Tools\Automation\
- Hash Whitelist: archive.vbs SHA256=<...>