跳到主要內容

Bandizip 可以正確的顯示壓縮檔內的檔名的壓縮軟體

常常下載中日韓等地的資源時，常常會遇到解壓縮後無法正確顯示檔名或是亂碼問題...


常見的解壓縮軟體 WinZip、7-Zip 和 WinRAR都無法正確的把檔名"解"出來時，這時候您可以試試看Bandizip!


可以正確的顯示壓縮檔內的檔名

標籤：

留言

張貼留言

這個網誌中的熱門文章

如何使用relive.cc 搭配Strava 製作單車軌跡動畫

先完成前置工作 首先要先有 Strava 的帳號，如果沒有請先去註冊 用你的智慧型手機下載StravaAPP  (Android版本連結)  | ( iOS 版本連結 ) 到 relive.cc 跟Strava的帳號做綁定
7 則留言
閱讀完整內容

我對0X協議的理解

交易所分為中心化跟去中心化 中心化交易所： 在交易所本身的資料庫中增減使用者資產欄位。 中心化交易所擁有了存放大量加密貨幣的私鑰，中心化交易容易吸引駭客的攻擊 交易速度快、體驗好 一般去中心化交易所： 在區塊鏈上直接交換，加密貨幣會直接發回使用者的錢包，或是保存在區塊鏈上的智能合約。 每一個操作，都是在區塊鏈上進行的，包括發起訂單，取消訂單，存幣和取幣， 每筆交易，掛單，取消，真正交易都需要gas 和時間去廣播，導致了交易效率下降。 0X協議對去中心化的改進： 通過把交易訂單在鏈下讓中繼者（relayer）撮合處理，然後在區塊鏈上進行結算確認。 提升交易速度的同時，又能保證安全性。 參考資料： https://www.inside.com.tw/article/11962-exchanges-on-blockchain https://www.jianshu.com/p/5c1685cbf767 https://dewone.zendesk.com/hc/zh-cn/articles/115004443674
張貼留言
閱讀完整內容

面試反思與架構演進指南

面試反思與架構演進指南 從「資料庫驅動」到「DDD 模組化單體」：面試反思與架構演進指南 在技術面試中，有一個看似陷阱、實則極具含金量的經典問題： 「如果讓你重新設計以前做過的系統，你最想修改什麼？」 初級工程師往往害怕承認過去程式碼的不足；而資深工程師（Senior Engineer）則懂得將這個問題轉化為展現「痛點感知能力」 、 「領域驅動設計（DDD）」 與 「架構演進思考」的最佳舞台。 本文將拆解如何將過去典型的「資料庫驅動（DB-Driven）」反模式，重新設計為現代化、低耦合的「模組化單體（Modular Monolith）」，並提供一份可以直接應用於面試與實務重構的完整架構指南。 一、 陷阱：DB-Driven 架構的技術債 在專案初期或 MVP（最小可行性產品）階段，以資料庫 Schema 為核心進行開發是非常常見的做法： [使用者請求] ➔ [Controller] ➔ [Service / ORM] ➔ [MySQL / PostgreSQL (強外鍵關聯 & 複雜 JOIN)] 這種架構在業務簡單時開發極快，但隨著業務規模擴張，會迅速帶來三大災難： 資料庫成為全域變數 ：所有業務邏輯都圍繞著 SQL 表格。修改 products 表的一個欄位，可能會意外破壞 orders 或 inventory 的查詢。 強外鍵（Foreign Key）導致併發瓶頸 ：高併發場景下，跨表外鍵會在寫入時觸發共享鎖（Shared Lock），導致連線池爆滿甚至死鎖（Deadlock）。 歷史資料被破壞 ：過度追求資料庫正規化（3NF）。當商品改名或調價時，如果歷史訂單採用 SQL JOIN 查詢，會導致歷史財務報表錯亂。 二、 思維轉變：DDD 與界限上下文（Bounded Context） 要擺脫「牽一髮而動全身」的泥淖，核心在於切斷跨領域的物理耦合，導入 Bounded Context (BC) 概念。 1. 斷開跨 BC 的資料庫外鍵，改用「ID-Only」與「快照（Snapshot）」 在模組化單體中，跨領域之間 不設資料庫外鍵、不用 SQL JOIN ，僅傳遞純 ID 與下單當下的業務快照。 ❌ 反模式：ORM 強關聯與 SQL JOIN G...
張貼留言
閱讀完整內容