Canon Digital Camera 相機獨享 - 記憶卡歸檔工具

Case #1: 批次檔一鍵自動歸檔至日期+主題目錄

Problem Statement（問題陳述）

業務場景：家庭或外拍回來，記憶卡中常有數百張照片。以往需手動建立資料夾、照日期命名並移動檔案，流程冗長。作者希望不安裝第三方相簿軟體，借助命令列快速將照片整理到既定目錄，保留主題名，方便日後瀏覽與備份。技術挑戰：Windows 原生命令需自動建立日期+主題目錄並批次移動不同副檔名檔案。影響範圍：手動流程耗時、容易出錯，降低照片管理效率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

缺乏自動歸檔工具，完全靠手動建立資料夾與搬檔。
檔案數量大，手動分類耗時且易漏檔。
GUI 工具太重，不符合作者僅需「搬檔」需求。深層原因：
- 架構層面：無標準化命名與資料夾結構。
- 技術層面：未善用批次與命令列自動化能力。
- 流程層面：缺少固定流程與可重複執行的指令。

Solution Design（解決方案設計）

解決策略：以批次檔（.cmd）封裝日期推導、目錄建立、檔案分類與搬移流程，一次性完成歸檔，避免手動操作造成的不一致與遺漏。

實施步驟：

建立批次檔
- 實作細節：以環境變數取得日期，組合目標路徑，for /R 遞迴移動.
- 所需資源：Windows CMD（XP 以上皆可）
- 預估時間：0.5 小時
套用與驗證
- 實作細節：在有相片的記憶卡執行，確認目錄命名與檔案皆正確歸位。
- 所需資源：相機記憶卡、讀卡機
- 預估時間：0.5 小時

關鍵程式碼/設定：

set DATETEXT=%DATE:~0,4%-%DATE:~5,2%%DATE:~8,2%
if not "%2"=="" set DATETEXT=%2 
set TRGDIR="c:\Photos\%DATETEXT% [%1]\"
md %TRGDIR%
for /R F:\DCIM %%f in (*.jpg) do @move /-Y %%f %TRGDIR% > nul
for /R F:\DCIM %%f in (*.crw) do @move /-Y %%f %TRGDIR% > nul

實際案例：作者以 copypic.cmd 去公園方式，一次完成當日照片與 RAW 歸檔。實作環境：Windows XP 命令列；Canon 相機；讀卡機。實測數據：改善前：手動建立目錄、複製與命名，步驟多且易錯。改善後：一條指令完成歸檔與命名。改善幅度：質化提升（流程從多步縮減為一步）。

Learning Points（學習要點）核心知識點：

批次檔日期字串處理與目錄建立
for /R 遞迴處理文件
命令列自動化設計

技能要求：必備技能：Windows 命令列、批次檔基本語法進階技能：參數化腳本設計

延伸思考：

可否加入日誌與錯誤處理？
如何支援多國語系路徑？
如何擴充成支援更多副檔名？

Practice Exercise（練習題）基礎練習：新增支援 *.png 的搬檔規則（30 分鐘）進階練習：加入日誌紀錄成功與失敗檔案（2 小時）專案練習：做一個互動式批次工具，支援來源路徑與主題提示輸入（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：能建立日期+主題目錄並正確移動檔案程式碼品質（30%）：變數、註解與參數化良好效能優化（20%）：大量檔案仍可順暢運作創新性（10%）：額外加入日誌/錯誤重試

Case #2: 影片與照片分離歸檔，建立影音處理通道

Problem Statement（問題陳述）

業務場景：同一記憶卡內同時存在相片與影片。後續處理（如剪輯、轉碼）與瀏覽場景不同，若混放在照片目錄，不利於工作流程與儲存規劃。技術挑戰：自動辨識 *.avi 檔，移至專用影片目錄，並保留與活動主題及原始檔名的關聯。影響範圍：混放造成管理與後製效率低。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

相機將照片與影片放在同一 DCIM 階層。
缺乏自動分流策略。
後製需求與瀏覽需求不同。深層原因：
- 架構層面：資料夾結構未分層設計。
- 技術層面：未根據副檔名自動路由。
- 流程層面：將所有媒體當作同類處理。

Solution Design（解決方案設計）

解決策略：在批次檔中針對 *.avi 檔配置專屬目標路徑與命名規則，導入單獨影片目錄與保留原始檔名的命名模式，形成清晰分流。

實施步驟：

新增影片搬移規則
- 實作細節：針對 *.avi，設定 video 目錄與命名。
- 所需資源：Windows CMD
- 預估時間：0.5 小時
後續流程接軌
- 實作細節：在影片目錄建立後製工具鏈（可選）。
- 所需資源：自有剪輯/轉碼工具
- 預估時間：1 小時

關鍵程式碼/設定：

for /R F:\DCIM %%f in (*.avi) do @echo 移動影片中... %%f && ^
@move /-Y %%f "c:\videos\input [dc-avi]\%DATETEXT% [%1 #%%~nf].avi" > nul

實際案例：作者影片被自動移至 c:\videos\input [dc-avi]\YYY-MMdd [主題 #原檔名].avi。實作環境：Windows XP 命令列。實測數據：改善前：影片與照片混放，難以後製。改善後：影片集中於專屬目錄，便於後續批次處理。改善幅度：質化提升（流程清晰度顯著增加）。

Learning Points（學習要點）核心知識點：

依副檔名分流
命名中保留原始檔名
後製工作流規劃

技能要求：必備技能：批次檔副檔名比對進階技能：與後製工具整合

延伸思考：

是否需要自動轉碼？
與 NLE 軟體的 watch folder 整合？
影片檔名中是否加上相機型號？

Practice Exercise（練習題）基礎練習：新增 *.MP4 支援（30 分鐘）進階練習：為每次匯入自動建立播放清單（2 小時）專案練習：建置 watch folder 轉碼流程（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：影片正確分流與命名程式碼品質（30%）：規則清晰、可讀性高效能優化（20%）：大量影片處理效率創新性（10%）：與後製流程整合

Case #3: 自動刪除 .THM 影片縮圖，清潔輸出目錄

Problem Statement（問題陳述）

業務場景：Canon 等相機會為影片產生 .THM 縮圖副檔名，匯入電腦後若不需使用，會佔據目錄並增加視覺雜訊，干擾後續瀏覽。技術挑戰：在自動化歸檔過程中自動且安全地移除不必要的 .THM。影響範圍：干擾檔案管理、影響可讀性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

相機自動生成 .THM；PC 端多半無用。
未自動清理。
手動刪除易漏失。深層原因：
- 架構層面：未定義輸出目錄淨化策略。
- 技術層面：缺乏副檔名的清理規則。
- 流程層面：匯入與清理未整合。

Solution Design（解決方案設計）

解決策略：在批次流程中加入 .THM 刪除步驟，確保輸出目錄乾淨，僅保留必要媒體。

實施步驟：

新增清理規則
- 實作細節：for /R 配合 del /f /q 刪除 .THM。
- 所需資源：Windows CMD
- 預估時間：0.2 小時
驗證安全性
- 實作細節：先以 @echo 列出將刪除清單，再去除 echo。
- 所需資源：測試資料
- 預估時間：0.5 小時

關鍵程式碼/設定：

for /R F:\DCIM %%f in (*.thm) do @echo 刪除影片縮圖... %%f && @del /f /q %%f > nul

實際案例：作者在移動影片後，立即清除 .THM，輸出目錄更乾淨。實作環境：Windows XP 命令列。實測數據：改善前：影片縮圖充斥，視覺雜訊高。改善後：目錄清爽、辨識更易。改善幅度：質化提升（雜訊檔移除）。

Learning Points（學習要點）核心知識點：

批次檔清理規則
安全刪除驗證手法
目錄衛生觀念

技能要求：必備技能：批次檔基礎進階技能：預演與日誌

延伸思考：

是否需保留特定 .THM 作封面？
刪除是否需進回收桶（安全性）？
清理策略如何對應不同相機品牌？

Practice Exercise（練習題）基礎練習：改為先移動到暫存垃圾桶資料夾（30 分鐘）進階練習：增加日誌與回復機制（2 小時）專案練習：實作可配置的清理白名單/黑名單（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：.THM 全數清理且不誤刪程式碼品質（30%）：可讀、安全效能優化（20%）：大量檔案清理表現創新性（10%）：安全回復設計

Case #4: 過午夜日期誤判—以參數覆寫日期

Problem Statement（問題陳述）

業務場景：白天拍攝、午夜後才歸檔，若以「當前系統日期」命名，將導致錯誤日期，影響照片與活動主題對應。技術挑戰：允許使用者在執行時手動覆寫日期，以維持正確的歸檔日期。影響範圍：日期錯置，影響檢索與整潔性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

批次檔初版以執行時系統日期命名。
無法從檔案屬性取拍攝時間。
深夜作業常跨日。深層原因：
- 架構層面：日期來源未抽象為可配置。
- 技術層面：批次檔難以解析檔案時間/EXIF。
- 流程層面：夜間作業習慣未納入考量。

Solution Design（解決方案設計）

解決策略：加入第二個命令列參數供日期覆寫，遇到跨日歸檔時，由使用者指定正確日期字串以修正。

實施步驟：

參數解析
- 實作細節：若 %2 存在則覆寫 DATETEXT。
- 所需資源：Windows CMD
- 預估時間：0.1 小時
使用教學
- 實作細節：copypic.cmd 去公園 2006-0101
- 所需資源：—
- 預估時間：0.1 小時

關鍵程式碼/設定：

set DATETEXT=%DATE:~0,4%-%DATE:~5,2%%DATE:~8,2%
if not "%2"=="" set DATETEXT=%2

實際案例：作者以第二參數指定日期，避免午夜誤判。實作環境：Windows XP 命令列。實測數據：改善前：午夜後歸檔日期錯一日。改善後：可手動覆寫，日期正確。改善幅度：問題完全避免（質化）。

Learning Points（學習要點）核心知識點：

命令列參數處理
日期字串格式
人機互補設計

技能要求：必備技能：CMD 參數語法進階技能：輸入驗證與格式校驗

延伸思考：

可否從檔案/EXIF 自動取得日期以免手動？
日期格式國際化處理？
如何避免手動輸入錯誤？

Practice Exercise（練習題）基礎練習：驗證 %2 是否符合 yyyy-MMdd 格式（30 分鐘）進階練習：若未輸入，提示詢問日期（2 小時）專案練習：實作多來源日期決策（系統/檔案/EXIF/手動）（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：能覆寫日期程式碼品質（30%）：格式校驗完善效能優化（20%）：無關創新性（10%）：人機互補設計

Case #5: 精準日期歸檔—改用檔案/EXIF 日期

Problem Statement（問題陳述）

業務場景：累積數日拍攝後一次歸檔，若只用「執行日期」或「複製時間」，不同天的照片會混在一起，影響活動與日期分類。技術挑戰：從檔案/EXIF 取得正確時間並參與命名與路徑規劃，實現真正按拍攝日分目錄。影響範圍：資料集混雜、不可用的日期索引。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

批次檔無法可靠解析 EXIF。
使用複製/執行時間與拍攝時間不同步。
多日素材批次匯入。深層原因：
- 架構層面：命名策略未綁定來源真實屬性。
- 技術層面：缺少讀取檔案/EXIF 的能力。
- 流程層面：集中處理習慣使問題放大。

Solution Design（解決方案設計）

解決策略：以 .NET 小工具（DigitalCameraFiler.exe）讀取檔案時間/EXIF，並以 {0:yyyy-MMdd} 參與 targetPattern，確保依拍攝日建目錄。

實施步驟：

建立 .NET 工具與設定
- 實作細節：讀取 LastWriteTime/EXIF，格式化日期。
- 所需資源：.NET Framework 2.0
- 預估時間：4-8 小時
配置路徑命名
- 實作細節：設定 targetPattern 使用 {0:yyyy-MMdd}。
- 所需資源：App.config
- 預估時間：0.5 小時

關鍵程式碼/設定：

<add key="photo.targetPattern" value="c:\photos\{0:yyyy-MMdd} [{1}]\{2} #{3}" />
<add key="arguments" value="LastWriteTime,Title,Model,Name,FileNameWithoutExtension"/>

實際案例：作者以 .NET 工具取代批次檔，依 {0}（檔案時間）建立日期資料夾。實作環境：Windows、.NET 2.0。實測數據：改善前：不同天素材混在同一資料夾。改善後：精準按日分目錄。改善幅度：質化提升（分類正確性）。

Learning Points（學習要點）核心知識點：

AppSettings 模板替換
日期格式化
檔案屬性/EXIF 時間的使用

技能要求：必備技能：.NET 讀檔屬性進階技能：EXIF Metadata 解析

延伸思考：

何時用 EXIF DateTaken 優於 LastWriteTime？
影片時間戳的來源？
跨時區拍攝如何處理？

Practice Exercise（練習題）基礎練習：改顯示月/日兩級目錄（30 分鐘）進階練習：加入時區校正（2 小時）專案練習：多來源時間（EXIF/檔案/手動）決策引擎（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：按拍攝日分流正確程式碼品質（30%）：設定與程式解耦效能優化（20%）：大量檔案仍能解析創新性（10%）：時間來源策略

Case #6: 多台相機檔名衝突—以相機型號納入命名

Problem Statement（問題陳述）

業務場景：家中多台 Canon 相機都用 IMG_XXXX 命名，整合匯入時檔名衝突，易覆寫或混淆來源，影響追溯。技術挑戰：自動將相機型號（Model）納入檔名或目錄，確保唯一性與可追溯性。影響範圍：檔案衝突、資料遺失風險。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

相機預設命名相同。
歸檔時未帶入相機識別。
重複檔名覆蓋風險。深層原因：
- 架構層面：命名規則未納入來源識別。
- 技術層面：批次檔無法讀取 EXIF Model。
- 流程層面：多相機來源未制定合併策略。

Solution Design（解決方案設計）

解決策略：以 .NET 工具讀取 Model，將其併入檔名或資料夾命名模板，避免衝突並便於追溯。

實施步驟：

模板配置
- 實作細節：使用 {1} 代表 Model。
- 所需資源：App.config
- 預估時間：0.5 小時
歸檔驗證
- 實作細節：確認不同相機輸出檔路徑不同。
- 所需資源：多機來源測試集
- 預估時間：0.5 小時

關鍵程式碼/設定：

<add key="photo.targetPattern" value="c:\photos\{0:yyyy-MMdd} [{1}]\{2} #{3}" />
<add key="arguments" value="LastWriteTime,Title,Model,Name,FileNameWithoutExtension"/>

實際案例：最終照片路徑如：c:\photos\2006-1102 [Canon PowerShot G2]\Canon PowerShot G2 #IMG_1234.jpg。實作環境：Windows、.NET 2.0。實測數據：改善前：兩台相機檔名衝突。改善後：按 Model 區分，無覆蓋。改善幅度：質化—衝突歸零。

Learning Points（學習要點）核心知識點：

EXIF Model 的讀取與使用
唯一性命名設計
追溯性設計

技能要求：必備技能：.NET 讀取 EXIF 進階技能：命名衝突策略（去重、版本化）

延伸思考：

應該用 Model 還是 Serial Number 更佳？
影片資料如何帶入設備識別？
單一目錄過長如何切分？

Practice Exercise（練習題）基礎練習：將 Model 簡化為別名（30 分鐘）進階練習：加入裝置序號避免同型號衝突（2 小時）專案練習：設計一套全域唯一命名（GUID/哈希）策略（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：不同來源無衝突程式碼品質（30%）：設定清楚、可維護效能優化（20%）：大量檔案不影響創新性（10%）：追溯與可讀性的平衡

Case #7: 模板化命名規則—以 targetPattern 統一標準

Problem Statement（問題陳述）

業務場景：不同活動、不同類型檔案需要一致且可讀的命名與路徑，便於人員與工具識別。手動命名易不一致。技術挑戰：以設定檔定義可參數化、可格式化的命名與路徑規則。影響範圍：長期維護與協作成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

手動命名不一致。
缺乏集中設定與替換機制。
無法根據屬性自動生成。深層原因：
- 架構層面：規則分散在程式碼或手動約定。
- 技術層面：未引入模板與佔位符。
- 流程層面：缺少命名標準。

Solution Design（解決方案設計）

解決策略：以 AppSettings 中的 targetPattern + arguments 清楚定義替換順序與格式，所有檔案生成遵循統一模板。

實施步驟：

定義模板
- 實作細節：設置 general/photo/video 的 targetPattern。
- 所需資源：App.config
- 預估時間：0.5 小時
替換實作
- 實作細節：依 arguments 順序套用佔位符。
- 所需資源：.NET 字串格式化
- 預估時間：1 小時

關鍵程式碼/設定：

<add key="video.targetPattern"   value="c:\video\{0:yyyy-MMdd} [{1} #{4}].avi" />
<add key="general.targetPattern" value="c:\photos\{0:yyyy-MMdd} [{1}]\{3}" />
<add key="photo.targetPattern"   value="c:\photos\{0:yyyy-MMdd} [{1}]\{2} #{3}" />
<add key="arguments" value="LastWriteTime,Title,Model,Name,FileNameWithoutExtension"/>

實際案例：作者用上述模板生成一致命名。實作環境：Windows、.NET 2.0。實測數據：改善前：命名不一致、難維護。改善後：全部受控於設定檔，行為一致。改善幅度：質化提升（標準化）。

Learning Points（學習要點）核心知識點：

佔位符替換與格式化
設定驅動的設計
命名標準化

技能要求：必備技能：.NET 格式字串進階技能：配置管理與驗證

延伸思考：

如何加入條件式命名（有無 Title）？
設定版本控管？
多環境（家/公司）設定切換？

Practice Exercise（練習題）基礎練習：新增相簿子目錄層級（30 分鐘）進階練習：條件式佔位符（Title 為空使用 Default）（2 小時）專案練習：GUI 設定編輯器（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：模板覆蓋三類檔案程式碼品質（30%）：解耦、註解完善效能優化（20%）：大量替換不退化創新性（10%）：條件化與驗證

Case #8: 避免安裝大型相簿軟體—命令列工具實作

Problem Statement（問題陳述）

業務場景：僅需「歸檔」功能，安裝 Picasa/AcdSee 等完整相簿套件過於笨重；偏好用 Windows 內建影像檢視器看圖，歸檔靠命令列一鍵完成。技術挑戰：設計一個可攜、免 GUI 的命令列工具，接受來源路徑與主題。影響範圍：部署負擔、學習成本。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

第三方軟體功能過多不對焦。
使用者操作偏好命令列。
欲整合到既有批次流程。深層原因：
- 架構層面：最小可行工具設計。
- 技術層面：命令列參數與日誌。
- 流程層面：自動化優先，少互動。

Solution Design（解決方案設計）

解決策略：提供 DigitalCameraFiler.exe，僅處理「讀屬性→決策路徑→移動命名」三步，透過參數指定來源磁碟與主題，簡單部署。

實施步驟：

參數設計
- 實作細節：exe <來源路徑> <主題>。
- 所需資源：.NET 2.0
- 預估時間：2 小時
發佈與使用
- 實作細節：xcopy 部署，免安裝。
- 所需資源：執行檔與 config
- 預估時間：0.5 小時

關鍵程式碼/設定：

DigitalCameraFiler.exe F:\ 公園外拍

實際案例：作者以一行命令完成匯入與歸檔。實作環境：Windows、.NET 2.0。實測數據：改善前：需安裝學習第三方軟體。改善後：單一小工具、即用即走。改善幅度：質化（部署與學習成本下降）。

Learning Points（學習要點）核心知識點：

命令列參數處理
輕量工具設計
與批次整合

技能要求：必備技能：C# Console App 進階技能：錯誤處理與日誌

延伸思考：

如何支援拖放（drop to exe）？
與計劃排程器整合？
進度回報與錯誤代碼？

Practice Exercise（練習題）基礎練習：參數檢查與說明輸出（30 分鐘）進階練習：加入 –dry-run 模式（2 小時）專案練習：支援多來源、多主題批次（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：可執行並完成基本歸檔程式碼品質（30%）：參數解析與錯誤訊息效能優化（20%）：大批量處理創新性（10%）：易用性設計

Case #9: 多格式檔案三向分流（JPG/CRW/AVI）

Problem Statement（問題陳述）

業務場景：記憶卡常同時包含 JPG、RAW（CRW）與 AVI。不同類型資料應落至不同目的地，避免混雜。技術挑戰：基於副檔名自動路由至各自 targetPattern。影響範圍：輸出目錄可讀性與後續處理。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

單一資料夾難以承載多種用途。
RAW 與 JPG 用途不同。
影片需要單獨流程。深層原因：
- 架構層面：未建立型別導向的路由。
- 技術層面：缺少多路目的規則。
- 流程層面：下載後再手動分流，易錯。

Solution Design（解決方案設計）

解決策略：在設定中分別提供 general/photo/video 的 targetPattern，程式依副檔名匹配路徑。

實施步驟：

設定分流模板
- 實作細節：配置三種 targetPattern。
- 所需資源：App.config
- 預估時間：0.5 小時
邏輯實作
- 實作細節：副檔名→目標路徑映射。
- 所需資源：.NET 檔案 IO
- 預估時間：1 小時

關鍵程式碼/設定：

<add key="general.targetPattern" value="c:\photos\{0:yyyy-MMdd} [{1}]\{3}" />
<add key="photo.targetPattern"   value="c:\photos\{0:yyyy-MMdd} [{1}]\{2} #{3}" />
<add key="video.targetPattern"   value="c:\video\{0:yyyy-MMdd} [{1} #{4}].avi" />

實際案例：JPG→photo，CRW→general，AVI→video。實作環境：Windows、.NET 2.0。實測數據：改善前：格式混雜。改善後：格式清晰分層。改善幅度：質化提升。

Learning Points（學習要點）核心知識點：

檔案副檔名路由
多目標設定
後續流程對接

技能要求：必備技能：檔案系統操作進階技能：策略配置

延伸思考：

新增 HEIC、MOV 支援？
RAW 檔可否與 JPG 對應成對管理？
大量目錄的效能？

Practice Exercise（練習題）基礎練習：加入 MOV 分流（30 分鐘）進階練習：RAW/JPG 成對對齊移動（2 小時）專案練習：插件化副檔名映射（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：三類分流正確程式碼品質（30%）：結構清晰效能優化（20%）：大批量仍穩定創新性（10%）：對齊與擴充

Case #10: 預設主題標題 default.title 防呆

Problem Statement（問題陳述）

業務場景：執行時偶爾忘記輸入主題，但命名模板需要主題欄位，若留空會影響可讀性。技術挑戰：提供合理的預設標題，避免空值影響命名。影響範圍：命名一致性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

使用者偶爾遺漏主題參數。
模板需要 {Title}。
空字串導致命名難讀。深層原因：
- 架構層面：缺少預設策略。
- 技術層面：未處理缺省值。
- 流程層面：操作容錯不足。

Solution Design（解決方案設計）

解決策略：設定 default.title，當執行時未提供主題則自動帶入預設值，確保模板完整。

實施步驟：

配置預設值
- 實作細節：在 App.config 增加 default.title。
- 所需資源：.NET 設定
- 預估時間：0.2 小時
取值邏輯
- 實作細節：無主題時 fallback default.title。
- 所需資源：C# 邏輯
- 預估時間：0.5 小時

關鍵程式碼/設定：

<add key="default.title" value="未定標題"/>

實際案例：作者將未輸入主題時自動使用「未定標題」。實作環境：Windows、.NET 2.0。實測數據：改善前：命名出現空或不一致。改善後：命名完整一致。改善幅度：質化。

Learning Points（學習要點）核心知識點：

預設值策略
設定檔應用
容錯設計

技能要求：必備技能：設定讀寫進階技能：輸入驗證

延伸思考：

預設值是否加入日期片段？
多語系預設值？
提示使用者確認主題？

Practice Exercise（練習題）基礎練習：加入主題不可包含非法字元的清理（30 分鐘）進階練習：若 default.title 被使用，輸出警示（2 小時）專案練習：主題選單（以常用主題快選）（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：預設值可生效程式碼品質（30%）：容錯清晰效能優化（20%）：無關創新性（10%）：提示與互動

Case #11: 以 arguments 映射欄位順序，提升擴充性

Problem Statement（問題陳述）

業務場景：命名模板中的佔位符需綁定來源屬性（時間、標題、型號、檔名）。硬編碼不利於擴充與維護。技術挑戰：用設定檔定義替換欄位順序，降低耦合。影響範圍：擴充性、維護性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

欄位源與模板綁定固定。
新需求需改程式碼。
欄位多變更風險大。深層原因：
- 架構層面：資料驅動不足。
- 技術層面：映射無外部化。
- 流程層面：每改動需重新發佈。

Solution Design（解決方案設計）

解決策略：在 App.config 的 arguments 指定替換順序，程式解析後動態套入模板，變更不需改碼。

實施步驟：

設定 arguments
- 實作細節：以逗號清單定義欄位順序。
- 所需資源：App.config
- 預估時間：0.2 小時
解析與套用
- 實作細節：依索引對映 {0}..{n}。
- 所需資源：.NET
- 預估時間：1 小時

關鍵程式碼/設定：

<add key="arguments" value="LastWriteTime,Title,Model,Name,FileNameWithoutExtension"/>

實際案例：作者以 {0}..{4} 對應時間、標題、相機型號、完整檔名、去副檔名。實作環境：Windows、.NET 2.0。實測數據：改善前：每次改動需改碼。改善後：改設定即可。改善幅度：質化（維護效率高）。

Learning Points（學習要點）核心知識點：

設定驅動映射
低耦合設計
可擴充架構

技能要求：必備技能：設定解析進階技能：反射/泛型封裝欄位源

延伸思考：

欄位型別與格式化策略如何管理？
不同格式共用映射？
動態驗證設定合法性？

Practice Exercise（練習題）基礎練習：新增 Orientation 欄位（30 分鐘）進階練習：為每欄位提供格式化選項（2 小時）專案練習：設計映射插件系統（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：映射可運作程式碼品質（30%）：設計清晰效能優化（20%）：映射低成本創新性（10%）：插件化構想

Case #12: 直拍自動轉正（EXIF Orientation，示意實作）

Problem Statement（問題陳述）

業務場景：直拍照片需旋轉 90 度，傳統作法要逐張檢視並手轉，耗時費力。文中提出「要自動轉正」需求，批次檔難達成。技術挑戰：讀取 EXIF Orientation 並自動旋轉輸出。影響範圍：大量直拍照片的可用性與處理時間。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

直拍圖 EXIF 有 Orientation，但未被使用。
批次檔缺乏影像處理能力。
手動旋轉費時。深層原因：
- 架構層面：缺少影像處理模組。
- 技術層面：未解析 EXIF Orientation。
- 流程層面：後製與匯入未整合。

Solution Design（解決方案設計）

解決策略：在 .NET 工具中讀取 EXIF Orientation，於搬移前對 jpg 進行自動旋轉與儲存（此段為示意，原文未附實作碼）。

實施步驟：

讀取 EXIF
- 實作細節：System.Drawing 取得 Orientation 標籤。
- 所需資源：.NET 2.0（GDI+）
- 預估時間：1 小時
旋轉與儲存
- 實作細節：按值 RotateFlip 並覆寫。
- 所需資源：影像 API
- 預估時間：1 小時

關鍵程式碼/設定：

// 示意：依 EXIF Orientation 自動旋轉
using (var img = Image.FromFile(srcPath)) {
  const int OrientationId = 0x0112;
  if (img.PropertyIdList.Contains(OrientationId)) {
    var prop = img.GetPropertyItem(OrientationId);
    int orientation = BitConverter.ToUInt16(prop.Value, 0);
    RotateFlipType op = RotateFlipType.RotateNoneFlipNone;
    if (orientation == 3) op = RotateFlipType.Rotate180FlipNone;
    else if (orientation == 6) op = RotateFlipType.Rotate90FlipNone;
    else if (orientation == 8) op = RotateFlipType.Rotate270FlipNone;
    if (op != RotateFlipType.RotateNoneFlipNone) {
      img.RotateFlip(op);
      img.RemovePropertyItem(OrientationId); // 防止重複旋轉
      img.Save(dstPath, ImageFormat.Jpeg);
    }
  }
}

實際案例：文中提到需求「要自動轉正」，並以 .NET 工具取代批次檔以具備 EXIF 能力（示意補充）。實作環境：Windows、.NET 2.0。實測數據：改善前：需逐張手轉。改善後：匯入即正向。改善幅度：質化（大量節省時間）。

Learning Points（學習要點）核心知識點：

EXIF Orientation
GDI+ 基本影像處理
匯入流程整合後製

技能要求：必備技能：C# 圖像 API 進階技能：批次化處理與失敗回復

延伸思考：

無損旋轉與品質控制？
RAW 的方向處理？
平行處理效能？

Practice Exercise（練習題）基礎練習：只對 jpg 啟用轉正（30 分鐘）進階練習：加入 –no-rotate 開關（2 小時）專案練習：實作多執行緒旋轉與日誌（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：能正確判斷與旋轉程式碼品質（30%）：安全、可讀效能優化（20%）：大批量處理創新性（10%）：無損處理

Case #13: 避免覆蓋與安全移動—move /-Y 與去重命名

Problem Statement（問題陳述）

業務場景：同名檔案移動時可能覆蓋，導致資料遺失。需要在自動化同時兼顧安全性。技術挑戰：透過命令列選項與命名策略降低覆蓋機率。影響範圍：資料安全。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

相機檔名可能重複。
移動操作預設可覆蓋。
缺乏唯一性命名。深層原因：
- 架構層面：未考慮衝突策略。
- 技術層面：指令缺少安全參數。
- 流程層面：缺少覆蓋提示。

Solution Design（解決方案設計）

解決策略：使用 move /-Y 在覆蓋時提示，並在命名模板中加入相機型號或原始檔名片段，降低衝突。

實施步驟：

安全移動
- 實作細節：指定 /-Y。
- 所需資源：Windows CMD
- 預估時間：0.1 小時
唯一命名
- 實作細節：模板納入 Model/#原檔名。
- 所需資源：App.config
- 預估時間：0.5 小時

關鍵程式碼/設定：

@move /-Y %%f %TRGDIR% > nul

實際案例：作者批次檔與模板命名同時降低覆蓋風險。實作環境：Windows。實測數據：改善前：覆蓋風險高。改善後：提示與唯一命名並行。改善幅度：質化提升（風險顯著下降）。

Learning Points（學習要點）核心知識點：

move 參數 /-Y
唯一性命名設計
風險控制

技能要求：必備技能：CMD 操作進階技能：命名策略設計

延伸思考：

自動去重（如加後綴 _1、_2）？
以雜湊值檢測重複？
覆蓋發生時的自動回復？

Practice Exercise（練習題）基礎練習：檢測目標已存在則改名（30 分鐘）進階練習：建立去重策略（雜湊）（2 小時）專案練習：設計完整衝突決策引擎（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：避免覆蓋成功程式碼品質（30%）：清晰與可維護效能優化（20%）：大批量決策效率創新性（10%）：去重方法

Case #14: 從批次檔遷移至 .NET 工具，突破 EXIF 與彈性限制

Problem Statement（問題陳述）

業務場景：初版批次檔雖可歸檔，但無法讀 EXIF、日期誤判、無法以相機名稱命名、不能自動轉正。需更強的可擴充方案。技術挑戰：重寫為 .NET 工具，提供設定驅動的模板、擴充欄位與更準確的日期來源。影響範圍：整體流程品質與擴充性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

批次檔功能上限。
無法讀取 EXIF。
命名與分流彈性不足。深層原因：
- 架構層面：需要配置驅動架構。
- 技術層面：需程式存取檔案屬性/EXIF。
- 流程層面：希望一步完成所有處理。

Solution Design（解決方案設計）

解決策略：實作 DigitalCameraFiler.exe，透過 App.config 管理模板與欄位映射，以 .NET API 讀取屬性，統一控制 JPG/CRW/AVI 的歸檔行為。

實施步驟：

Console App 骨架
- 實作細節：參數解析、遍歷來源。
- 所需資源：.NET 2.0
- 預估時間：2 小時
設定與模板
- 實作細節：讀 appSettings、套模板。
- 所需資源：App.config
- 預估時間：1 小時
檔案搬移
- 實作細節：按副檔名分流。
- 所需資源：System.IO
- 預估時間：1 小時

關鍵程式碼/設定：

<configuration>
 <appSettings>
  <add key="default.title" value="未定標題"/>
  <!-- video/general/photo targetPattern 與 arguments 如前 -->
 </appSettings>
</configuration>

實際案例：作者以 .NET 工具完全取代過去批次檔。實作環境：Windows、.NET 2.0。實測數據：改善前：功能受限、人工介入多。改善後：設定驅動、自動化完整。改善幅度：質化（「成效很好」）。

Learning Points（學習要點）核心知識點：

設定驅動程式設計
EXIF 與檔案屬性讀取
多格式分流

技能要求：必備技能：C#、.NET IO 進階技能：配置管理、日誌

延伸思考：

單檔可測試性如何設計？
版本升級與向下相容？
跨平台可行性（.NET Core）？

Practice Exercise（練習題）基礎練習：將批次檔邏輯搬到 C#（30 分鐘）進階練習：加入配置驗證與錯誤報告（2 小時）專案練習：完整 CLI 工具重寫與測試（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：覆蓋批次檔全部功能程式碼品質（30%）：結構良好、可測效能優化（20%）：大量檔案效率創新性（10%）：配置與擴充設計

Case #15: 遞迴掃描 DCIM 子資料夾，避免漏檔

Problem Statement（問題陳述）

業務場景：相機會在 DCIM 下建立多個子資料夾（如 100CANON、101CANON）。若未遞迴掃描，容易漏掉部分素材。技術挑戰：在命令列自動遞迴遍歷所有子資料夾並處理符合副檔名的檔。影響範圍：資料完整性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

DCIM 採子資料夾分片。
非遞迴掃描會漏檔。
手動補抓成本高。深層原因：
- 架構層面：資料組織多層次。
- 技術層面：需支援遞迴。
- 流程層面：一次過濾所有層級。

Solution Design（解決方案設計）

解決策略：採用 for /R F:\DCIM 遞迴匹配副檔名，確保所有層級檔案都被處理。

實施步驟：

調整批次掃描
- 實作細節：for /R 路徑改為 DCIM 根。
- 所需資源：Windows CMD
- 預估時間：0.1 小時
驗證
- 實作細節：比對檔案計數，確認無遺漏。
- 所需資源：檔案清單
- 預估時間：0.3 小時

關鍵程式碼/設定：

for /R F:\DCIM %%f in (*.jpg) do @move /-Y %%f %TRGDIR% > nul

實際案例：作者的批次檔使用 /R 確保全抓。實作環境：Windows。實測數據：改善前：可能漏抓某些子資料夾。改善後：全量處理。改善幅度：質化（完整性提升）。

Learning Points（學習要點）核心知識點：

for /R 遞迴
根路徑選擇
完整性驗證

技能要求：必備技能：CMD for 語法進階技能：檔案比對與校驗

延伸思考：

如何排除指定資料夾？
大量遞迴的效能？
平行處理可能性？

Practice Exercise（練習題）基礎練習：新增 *.JPG 大小寫兼容（30 分鐘）進階練習：排除含「TMP」的資料夾（2 小時）專案練習：產出遞迴掃描報表（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：不漏檔程式碼品質（30%）：語法與註解效能優化（20%）：遞迴效率創新性（10%）：報表與排除規則

Case #16: 影片命名保留原始檔名以利追溯

Problem Statement（問題陳述）

業務場景：影片重命名後可能失去相機原始編號，難以追溯來源與比對記錄。需要在新命名中保留原始檔名資訊。技術挑戰：支援以「#原檔名」樣式注入至目標檔名。影響範圍：可追溯性、問題定位。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

全新命名喪失原始關聯。
影片後製需要原始編號比對。
多來源匯入需追溯。深層原因：
- 架構層面：命名未顧及追溯需求。
- 技術層面：未注入來源標識。
- 流程層面：審核與回查不便。

Solution Design（解決方案設計）

解決策略：模板中加入 FileNameWithoutExtension（{4} 或 %%~nf），命名以 [主題 #原檔名] 形式保留追溯線索。

實施步驟：

批次規則
- 實作細節：%%~nf 插入命名。
- 所需資源：Windows CMD
- 預估時間：0.2 小時
.NET 模板
- 實作細節：使用 {4}。
- 所需資源：App.config
- 預估時間：0.2 小時

關鍵程式碼/設定：

@move /-Y %%f "c:\videos\input [dc-avi]\%DATETEXT% [%1 #%%~nf].avi" > nul

<add key="video.targetPattern" value="c:\video\{0:yyyy-MMdd} [{1} #{4}].avi" />

實際案例：作者保留 #MVI_9999 於影片檔名。實作環境：Windows、.NET 2.0。實測數據：改善前：難以對照原始片段。改善後：命名包含原始編號。改善幅度：質化（追溯性增強）。

Learning Points（學習要點）核心知識點：

批次變數展開（%%~nf）
命名內嵌來源資訊
追溯性設計

技能要求：必備技能：CMD 變數進階技能：模板規劃

延伸思考：

是否加入拍攝時間戳？
多欄位追溯（裝置/序號）？
名稱長度限制處理？

Practice Exercise（練習題）基礎練習：照片亦保留原檔名（30 分鐘）進階練習：加入短雜湊避免過長（2 小時）專案練習：追溯資訊統一規格（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：保留原名成功程式碼品質（30%）：模板清晰效能優化（20%）：無關創新性（10%）：追溯設計

Case #17: RAW（CRW）與 JPG 分層存放，對應不同處理流程

Problem Statement（問題陳述）

業務場景：RAW 檔適合後製調整，JPG 用於即時瀏覽。兩者混放不利於後續處理與備份策略。技術挑戰：自動將 CRW 放置於獨立的 general.targetPattern 所指目錄。影響範圍：處理流程清晰度、儲存成本。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

RAW 與 JPG 混放難以篩選。
需要不同備份策略。
後製軟體目錄需求不同。深層原因：
- 架構層面：未分層設計。
- 技術層面：分流規則未建立。
- 流程層面：後製與瀏覽混雜。

Solution Design（解決方案設計）

解決策略：以 general.targetPattern 定義 RAW 目錄，使 RAW 與 JPG 自動分層，對應不同後續工具與備份規則。

實施步驟：

設定 general
- 實作細節：配置 RAW 目標路徑。
- 所需資源：App.config
- 預估時間：0.2 小時
測試與驗證
- 實作細節：匯入含 CRW 的記憶卡。
- 所需資源：RAW 測試集
- 預估時間：0.5 小時

關鍵程式碼/設定：

<add key="general.targetPattern" value="c:\photos\{0:yyyy-MMdd} [{1}]\{3}" />

實際案例：作者以 general.targetPattern 存放 *.crw。實作環境：Windows、.NET 2.0。實測數據：改善前：RAW/JPG 混雜。改善後：分層清楚。改善幅度：質化。

Learning Points（學習要點）核心知識點：

RAW 與 JPG 的用途差異
分層存放策略
設定驅動分流

技能要求：必備技能：設定檔進階技能：備份分級策略

延伸思考：

RAW+JPG 成對管理？
RAW 轉 DNG 的管線？
磁碟與備份分層（快/冷資料）？

Practice Exercise（練習題）基礎練習：為 RAW 加上子目錄 RAW（30 分鐘）進階練習：成對移動 RAW+JPG（2 小時）專案練習：建立 RAW 後製與輸出管線（8 小時）

Assessment Criteria（評估標準）功能完整性（40%）：CRW 正確落位程式碼品質（30%）：設定清晰效能優化（20%）：無關創新性（10%）：流程規劃

案例分類

按難度分類
- 入門級（適合初學者）：Case 1, 2, 3, 4, 8, 13, 15, 16, 17
- 中級（需要一定基礎）：Case 5, 6, 7, 9, 10, 11, 12, 14
- 高級（需要深厚經驗）：（本篇側重工具落地，無高階分散式或安全議題）
按技術領域分類
- 架構設計類：Case 7, 11, 14
- 效能優化類：Case 15（遞迴完整性與效率角度）
- 整合開發類：Case 2, 5, 6, 8, 9, 10, 16, 17
- 除錯診斷類：Case 4, 13, 15
- 安全防護類：Case 13（覆蓋風險控制）
按學習目標分類
- 概念理解型：Case 7, 11, 14
- 技能練習型：Case 1, 2, 3, 4, 8, 15, 16, 17
- 問題解決型：Case 5, 6, 9, 10, 13
- 創新應用型：Case 12（自動轉正示意）

案例關聯圖（學習路徑建議）

先學：Case 1（基礎批次歸檔）、Case 15（遞迴），建立命令列處理基礎。
再學：Case 2（影片分流）、Case 3（清理 .THM）、Case 4（日期覆寫），完善批次工具實務。
進階：Case 7（模板化）、Case 11（arguments 映射）、Case 9（多格式分流）、Case 10（default.title），理解設定驅動架構。
關鍵提升：Case 5（正確日期來源）、Case 6（相機型號避免衝突）、Case 13（覆蓋風險控制）。
遷移與擴充：Case 14（批次→.NET 工具），建立可擴充平台。
進一步應用：Case 16（追溯命名）、Case 17（RAW 分層）。
可選擴展：Case 12（自動轉正，需額外影像處理知識）、Case 8（CLI 工具易用化與整合）。

依賴關係：

Case 7/11 依賴 Case 14 的 .NET 工具基礎。
Case 5/6/9/10 依賴模板與映射（Case 7/11）。
Case 12 依賴 EXIF 能力（Case 14）。

完整學習路徑建議： Case 1 → Case 15 → Case 2 → Case 3 → Case 4 → Case 7 → Case 11 → Case 9 → Case 10 → Case 5 → Case 6 → Case 13 → Case 14 → Case 16 → Case 17 →（選修）Case 12 → Case 8（將工具整合入個人工作流與排程）。

Canon Digital Camera 相機獨享 - 記憶卡歸檔工具

Case #1: 批次檔一鍵自動歸檔至日期+主題目錄

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 影片與照片分離歸檔，建立影音處理通道

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 自動刪除 .THM 影片縮圖，清潔輸出目錄

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: 過午夜日期誤判—以參數覆寫日期

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 精準日期歸檔—改用檔案/EXIF 日期

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 多台相機檔名衝突—以相機型號納入命名

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: 模板化命名規則—以 targetPattern 統一標準

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 避免安裝大型相簿軟體—命令列工具實作

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 多格式檔案三向分流（JPG/CRW/AVI）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 預設主題標題 default.title 防呆

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: 以 arguments 映射欄位順序，提升擴充性

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: 直拍自動轉正（EXIF Orientation，示意實作）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 避免覆蓋與安全移動—move /-Y 與去重命名

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 從批次檔遷移至 .NET 工具，突破 EXIF 與彈性限制

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 遞迴掃描 DCIM 子資料夾，避免漏檔

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: 影片命名保留原始檔名以利追溯

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #17: RAW（CRW）與 JPG 分層存放，對應不同處理流程

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory