這次的主題想做出自動下戴redmine 的csv檔案，因為要通知有需求上版的RD, 確認每個需求是否都已經merage到release，根據以往都需要返覆的確認redmine的每個分支的merge 狀態，再貼在teams的頻道上，有點繁瑣，所以想直接下戴csv，透過工具幫我整理好每個人的merage 狀態，直接output 內文在 teams，就方便許多了，於是我使用gemini AI ，不花一毛錢，只用免費的方案就可以使用的方式，所以需求越明確就可以成功用AI 自動產生程式碼，以下是我的範例和我的提示喔~
node -v npm install -g @google/gemini-cli |
選擇登入方式。我們推薦**「使用 Google 登入」** ，該方式**每分鐘最多可免費要求 60 次**，**每天最多可免費請求 1,000 次**。選擇該方式並按**Enter 鍵**。
我的需求如下 1 程式語言為c# 2 可以從redmine 直接下戴csv 3 我可以直接給從瀏覽器取得 _redmine_session 幫我生成c#.exe的範例程式碼 |
我想建立一僤自動發佈到teams 的草稿的自動化工具， 用c# 程式語言 參數1: 版號的日期 ，例如 20251112 參數2: redmine的db單號 ，例如 https://redmine.etzone.net/issues/48618 後續就能自動將內容範例如下: 標題: 20251112 上版 內文: 20251112 上版 1. 將此次需要上版的 Code 併入 [release_1029]；請確認版本與 release 版本，還在待測試 => 請追相關人員。 2. 修改 DB 的 Redmine： https://redmine.etzone.net/issues/48618，請再把 SQL 放入。(11/12 週三上午會寄出) 3. 預計明日上午 (10/28) 佈版至 stage，故請在之前完成 merge。 之後會自動讀取相對路徑下的一份 csv 的檔案， 欄位如下: 專案 蹤標籤 主旨 被分派者 版本 Release版本 是否有 Code Review Merge into Release Code Reviewer 1 將它讀入後， 可以依照欄位【Merge into Release】， 請協助確認是否需安排上版或調整版次，謝謝！ 我發佈到teams的方式，只有透過teams 的 link的方式 ，建立teams 的草稿，最後由我確認後才送出。 |
但問題來了~ 讀 csv 檔案，不是UTF-8 格式，所以輸出的文章 就一直呈現亂碼的樣式，所以我又下的一個promp
為何會有亂碼? 該如何解決，因為csv 檔案來源是正常的UTF-8 |
它回的回覆如下:
原因: • 你看到的 FFFD 是 Unicode Replacement Character，代表以 UTF-8 解碼時遇到非法位元組序列。 • 檔案實際編碼並非 UTF-8 (多半是 Big5/CP950 或 UTF-16)，Excel 會依系統語系自動套用而正常。 • 被誤解碼後再傳給 CsvHelper，所有中文字成 FFFD，表頭對不到 → 讀不到資料，看起來像「亂碼」。 解法: 1. 先抓原始位元組，不直接假設 UTF-8。 2. 嘗試多種候選編碼 (UTF8 / UTF-16 LE / UTF-16 BE / CP950(Big5) / GB18030) 解碼。 3. 評估哪個解碼結果最少 FFFD 並含目標中文表頭 (專案, 主旨等)。 4. 用選出的編碼再交給 CsvHelper 解析。 使用方式: 1. 保留 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)（已存在）。 2. 重新執行程式；Console 會列出各編碼測試結果並選出最可能的。 3. 若仍顯示亂碼，檢查下載到的是否為 HTML (需登入 cookie)。可在 DownloadCsv 裡加判斷 <html。 若確定 Redmine 伺服器可設定輸出為 UTF-8，建議: • 確認伺服器設定 (Redmine production.rb) config.encoding = 'utf-8'. • 或在匯出 URL 加 ?encoding=utf-8 (若版本支援)。 接下來先測試上述自動偵測是否選出 CP950/Big5 並顯示正確中文。 |
目前已正常顯示了，請問csv 這份檔案到底是什麼編碼? 最後是作了什麼調整才能顯示正常 請說明 |
它回覆如下
說明: 1. 原始檔非 UTF-8；根據正常顯示後程式輸出 (選用編碼: xxx) 可知實際是被偵測為 Big5/CP950 (若顯示 webName=cp950) 或另一候選 (UTF-16/GB18030)。你可再跑一次查看 Console 的「選用編碼:」行以確定，該行就是檔案真正被採用的編碼。大多在繁體中文 Windows 環境下 Redmine 匯出的 CSV 會是 CP950(Big5)。 2. 之前強制用 UTF-8 讀取，遇到非 UTF-8 多位元組序列 → 產生 Unicode 替代字元 FFFD 造成「亂碼」與表頭比對失敗。 3. 調整內容: • 加入 Encoding.RegisterProvider(CodePagesEncodingProvider.Instance) 支援 Big5/GB18030 等非預設編碼。 • 以 DetectBestEncoding 讀入原始位元組，嘗試多個候選 (UTF8、UTF-16 LE/BE、CP950、GB18030) 計算表頭命中與替代字元數量選出最適編碼。 • 移除固定 UTF-8 假設，改用偵測結果建立 StreamReader。 • Normalize 表頭 (去 BOM) 並 ClassMap 同時接受 “#” 與 “\uFEFF#”。 • 顯示各編碼測試結果與最終選用編碼，便於確認。 如何再次確認: 執行程式 → 查看 Console 第一個 “編碼測試 …” 列出分數，最後 “選用編碼: cp950 (Chinese (Traditional) Windows)” 或其他；那就是 CSV 真正的編碼。 |
產出的小工具如下:
