在 SQL Server 中尋找忘記的欄位位置
前言幾百張表的資料庫，欄位名稱記不住放在哪張表——一張張展開 SSMS 物件總管根本沒有效率。這篇整理幾種用系統視圖直接查的方式，從基礎模糊搜尋到跨資料庫都有，下次忘了直接拿來用。 基本搜尋方法最直接的做法是透過 sys.tables 和 sys.columns 這兩個系統視圖 JOIN 起來查： 1234567891011SELECT t.name AS TableName, c.name AS ColumnNameFROM sys.tables tINNER JOIN sys.columns c ON t.object_id = c.object_idWHERE c.name LIKE '%YourColumnName%'ORDER BY TableName, ColumnName; 使用說明 將 YourColumnName 替換成你要搜尋的欄位名稱 % 符號代表萬用字元，可以做模糊搜尋 查詢結果會顯示所有符合的資料表名稱及欄位名稱 進階搜尋技巧只知道欄位名稱還不夠，通常還要確認型別、長度、能不能為空。加...
使用 IndexedDB 快取大量資料
起因是撰寫的油猴腳本使用 localStorage 存資料，到某一天發現資料怎麼存不進去了，排查才發現資料超過 5MB 了，然後就開始找有沒有其他更好的存資料方式，最後發現了瀏覽器資料庫 API——IndexedDB。 什麼是 IndexedDB?IndexedDB 是一個低階的 API，用於在瀏覽器中儲存大量結構化資料。它讓你可以在使用者端存放遠超 localStorage 的資料量（實際上限依磁碟配額決定），而且所有操作都是非同步的，不會卡住主執行緒。與 localStorage 不同，IndexedDB 可以處理更複雜的資料結構，也支援索引搜尋。 為什麼要用 IndexedDB? 儲存大量資料：相較於 localStorage 的 5MB 限制，IndexedDB 的上限由磁碟配額決定，通常是可用空間的數十趴，幾乎不會遇到瓶頸。 支援複雜資料結構：可以直接儲存和查詢 JavaScript 物件，不需要手動 JSON 序列化。 非同步操作：不會阻塞主執行緒，頁面不會因為資料操作而卡頓。 支援交易（Transactions）：確保一批操作全部成功或全部回滾，不會出現資料寫到一半...
處理程序與執行緒:從日常生活理解多執行緒
處理程序（Process）和執行緒（Thread）是作業系統的核心概念，也是理解並行程式設計的起點。用一個生活比喻來拆解兩者的差異，往往比讀定義清楚得多。 處理程序 vs 執行緒：一個家庭的故事想像有一個家庭經營著一間小餐廳。在這個比喻中： 整個餐廳就像一個處理程序 家庭成員則是執行緒 處理程序（餐廳） 擁有自己的資源：廚房設備、座位區、食材等 有獨立的記憶體空間：存放菜單、庫存清單等資訊 啟動和關閉成本較高：開店和打烊需要較多時間和精力 執行緒（家庭成員） 共享餐廳的資源 可以快速切換任務：爸爸可以從煮菜轉去招呼客人 建立和銷毀成本較低：家庭成員可以快速加入工作或休息 多執行緒：實際跑起來是什麼樣子這個家庭實際跑起來的樣子： 並行處理： 媽媽在廚房煮菜 爸爸在前台招呼客人 哥哥負責送餐 妹妹處理結帳 資源共享：所有人共用廚房的爐子、冰箱，不需要每個人準備一套。 動態調度：前台突然湧入大批客人時，爸爸可以直接喊哥哥過來幫忙——對應執行緒在同一份共享記憶體上協作，切換成本遠低於重新開一間分店（另起一個處理程序）。 多執行緒的優缺點優點 提高系統吞吐量 改善反應...
IIS中COOKIE的安全設置
本文介紹 IIS（Internet Information Services）中兩個關鍵的 Cookie 安全設定：httpOnlyCookies 和 requireSSL，說明各自的作用與 web.config 寫法。 問題背景最近，專案在進行弱點掃描時發現了一個與 ASP.NET_SessionId 有關的弱點。掃描結果顯示，這個重要的 Session ID 缺少必要的安全 Flag。因此，我決定仔細研究 IIS 中 Cookie 的安全設定，特別是 httpOnlyCookies 和 requireSSL 這兩個選項。 httpOnlyCookies什麼是 httpOnlyCookies?httpOnlyCookies 是一個安全特性，用於防止客戶端腳本存取受保護的 cookie。當啟用此選項時，cookie 只能透過 HTTP(S) 協議傳輸，而不能被客戶端腳本（如 JavaScript）存取。 為什麼重要?啟用 httpOnlyCookies 可以顯著降低跨站腳本（XSS）攻擊的風險。攻擊者即使成功注入惡意腳本，也無法直接讀取或操作受保護的 cookie，從而保護了敏感...
JavaScript字串搜索方法比較：indexOf vs includes vs filter
在 JavaScript 中，我們經常需要檢查一個字串是否包含某個特定的字元或子字串。本文比較三種常用方法：indexOf()、includes() 和 filter()，涵蓋語法、可讀性、相容性與效能差異。 1. indexOf() 方法indexOf() 是最古老且支援度最廣的方法之一。 語法1string.indexOf(searchValue[, fromIndex]) 用法123const str = "Hello, World!";const hasO = str.indexOf('o') !== -1; // trueconst hasZ = str.indexOf('z') !== -1; // false 優點 相容性好，支援舊版瀏覽器 可以指定開始搜尋的位置 缺點 返回值不是布林型，需要與 -1 比較 程式碼可讀性較差 2. includes() 方法includes() 是 ES6 引入的方法，專門用於檢查字串是否包含特定子字串。 語法1string.includes(searchStrin...
win-acme： Windows上的自動化SSL/TLS證書管理工具
win-acme: Windows 上的自動化 SSL/TLS 憑證管理工具Windows 伺服器管理員手動維護 SSL/TLS 憑證有兩個常見問題：憑證到期忘了續、每次都要重走申請流程。win-acme 把這兩件事自動化。 什麼是 win-acme？win-acme（Windows ACME Simple Client）是專為 Windows 設計的開源 ACME 客戶端，可從 Let's Encrypt 等相容 ACME 協定的憑證授權機構自動取得、安裝與更新 SSL/TLS 憑證。 專案網址：https://github.com/win-acme/win-acme/releases 主要功能： Windows 整合：原生支援 IIS、Exchange、RDP 等 Windows 服務 多種驗證方式：支援 HTTP-01 驗證（透過 IIS 或本地檔案系統）和 DNS-01 驗證（含萬用字元憑證） 插件系統：可擴充自訂驗證與安裝方式 自動續期：安裝完成後，win-acme 會在 Windows 工作排程器（Task Scheduler）建立排程工作，名稱為 win-...
網站圖片路徑大崩潰？一次搞懂網站部署時的圖片路徑問題
問題情境專案部署到 IIS 的虛擬目錄，URL 結構如下： 本機：http://localhost:56961/Project/ 正式環境：https://www.project.com.tw/Project/ HTML 裡的圖片路徑寫 ./Content/images/image.png，本機跑得好好的，上正式就全破圖。 實際原因：./ 是相對路徑，參考點是「解析該路徑的檔案位置」，不是 HTML 頁面。若圖片路徑寫在外部 .css 檔（例如放在 /Project/styles/main.css），瀏覽器會以 CSS 檔的目錄為基準，把 ./Content/images/image.png 解析成 /Project/styles/Content/images/image.png，而非你預期的 /Project/Content/images/image.png。 換部署位置（從本機 localhost 換到子目錄或反向代理後方）時，CSS 檔的實際 URL 路徑可能跟著變，就會踩到這個問題。 三種解法方案一：硬寫絕對路徑1background: url("/Proj...
GO語言學習路徑
Go 是 Google 於 2009 年釋出的靜態強型別語言，編譯速度快、垃圾回收輕量、內建並發原語。定位是系統程式設計與後端服務，不是「靜態語言的安全性加上動態語言的高效性」——它本質上就是靜態語言，只是刻意把複雜度壓低。 先備知識Go 不適合作為第一門語言。建議先有任何一門語言的基礎，理解變數、迴圈、函式的概念。若尚未有程式基礎，先補 Python 或 JavaScript。 安裝環境前往 go.dev/dl 下載對應平台的安裝包。安裝完成後執行： 1go version 確認輸出版本號即安裝成功。 關於 GOPATH 與 Go Modules：Go 1.11 引入 Modules，1.16 起預設啟用。現代專案用 go mod init 初始化模組，原始碼放在任何目錄都行，不再需要把程式碼塞進 $GOPATH/src。$GOPATH 仍然存在，但現在只作為模組快取（$GOPATH/pkg/mod）和已安裝工具（$GOPATH/bin）的存放位置，不需手動設定。 新建一個最小模組： 12mkdir myapp && cd myappgo mod init g...
.NET Core 中的中間件（Middleware）
.NET Core 中的中間件（Middleware）詳解什麼是中間件？在 .NET Core 應用程式中，中間件是一系列組件，它們形成了一個請求處理管道。每個中間件都可以: 處理傳入的 HTTP 請求 處理傳出的 HTTP 回應 呼叫管道中的下一個中間件 在管道中的下一個中間件完成處理後執行某些操作 中間件的概念類似於一條組裝線，每個工人（中間件）都對產品（請求/回應）進行某些操作。 中間件的工作原理中間件在 .NET Core 應用程式中按照特定的順序執行。這個順序很重要，因為它決定了哪個中間件先處理請求，以及回應如何被處理。 工作流程如下： 當應用程式接收到 HTTP 請求時，請求進入中間件管道。 每個中間件組件可以: 執行一些操作 將請求傳遞給下一個中間件 或者短路請求（不再傳遞給後續中間件） 一旦請求到達管道的末端，它會開始返回。 回應會再次通過所有中間件，讓每個中間件有機會處理或修改回應。 這個過程可以用下面的示意圖來表示： 12Request → Middleware 1 → Middleware 2 → Middleware 3 → Applicati...
經典排序演算法指南：快速、選擇、氣泡與插入排序
排序演算法完整指南四種排序演算法的核心差異就是複雜度與穩定性的取捨，這也是面試最常考的切入點。以下逐一拆解快速排序、選擇排序、氣泡排序、插入排序的工作原理與 JavaScript 實作。 排序演算法視覺化 快速排序 pivot 選擇排序 氣泡排序 ...
