為什麼檔名千萬別留白？來自鍵盤「空白鍵」的隱形殺手

 平常在電腦裡存檔案時，會不會習慣這樣命名：

• 2026 出國旅遊 行程表.docx
• 大專案 最終版 真的最後版.psd

在檔名裡加個「空白鍵」，讓字和字之間有呼吸的空間，看起來清爽又好讀，對吧？

但電腦底層的系統、工程師的眼裡，這個小小的「空白字元」，其實是一個隨時會引爆的炸彈！

😱 慘劇一：對 Linux/Mac 來說，空白鍵等於「下一道指令」

如果你用過 Mac 的終端機（Terminal）或 Linux 系統，你可能知道要跟電腦溝通，必須用「打字」下指令。

偏偏在電腦的邏輯裡，很多時候「空白鍵」的意思就是：「好，我前一個字講完了，接下來是下一個指令。」

💡 這會發生什麼慘劇呢？

假設你拍了一張照片叫 my photo.jpg，你下指令跟電腦說：「幫我刪除 my photo.jpg」。

電腦接收到空白鍵時，可能會自動解讀成：

「去刪除一個叫 my 的檔案」

「再去刪除一個叫 photo.jpg 的檔案」

結果就是，原本想刪的照片沒刪掉，反而不小心誤刪了其他無辜的檔案！

🤨 慘劇二：Windows 的「找不到檔案」鬼故事

雖然 Windows 系統對空白鍵比較溫柔，但它也有來自微軟的脾氣。

Windows 非常討厭檔名頭尾有空白，編寫檔名時一旦不小心多按到了空白鍵，系統就會開始「看得到、吃不到」，變成開不了也刪不掉的「幽靈檔案」。

🌐 慘劇三：雲端與網頁的「%20」亂碼大亂鬥

當把檔案上傳到 Google Drive、Dropbox，或是要把檔案傳到雲端時，網頁的網址（URL）規定「絕對不能有空白」。所以上傳了一個叫 my resume.pdf的檔案，雲端系統為了遷就網頁，會強制把空白鍵轉換成編碼。

於是，網址就會變成這樣：https://example.com/my%20resume.pdf

多出來的 %20 不僅看起來像亂碼，更可怕的是，某些舊的郵件系統或公司內部系統，根本看不懂這個「%20」，直接把你的檔案判定為「404 Not Found」的幽靈檔案，讓這個檔案就這麼憑空消失！

💡 總結：如何優雅地幫檔案命名？

既然空白鍵這麼容易翻車，那改掉敲空白鍵的習慣，用以下這兩種方法代替，就能保你一生平安（至少在還需要敲鍵盤的餘生...）：

用「底線」或「連字號」取代：

⭕ 好習慣：project_report_v1.docx（工程師最愛）

⭕ 好習慣：project-report-v1.docx（網頁讀取最順暢）

養成這個命名小習慣，不僅能讓你的檔案在 Windows、Mac、手機還是雲端之間傳傳去去都不噴錯，還能順便拯救你身邊每一個看到空白檔名就會血壓飆高的工程師朋友喔！

簡單使用 Openssl 測試指定加密

Photo by Markus Winkler on Unsplash

有時候更換憑證，要測試指定的加密法連線運作是否正常，其中最簡單的方法，便是使用 Openssl 所提供的連線工具即可。

Client 參數 

•  -msg：用16進位顯示所有協議數據包含 handshake 
• -cipher：指定 cipher連線 
• -showcerts：顯示 chain 
• -curves：指定要用的橢圓算法，client hello的extension中的 elliptic_curves 
• -sigalgs：指定交換 key要用的簽名方式，client hello的 extension 中的 signature_algorithms 
• -debug 列印出所有是訊息 

基本 Client連線指令：openssl s_client -connect [IP]:[port]

Server 參數 

•  -accept 聽的port 
• -key 使用的KEY 
• -cert 使用的憑證

基本 Server連線指令：openssl s_server -accept [port] -key server.key -cert server.pem

你可能還想要知道：

• OpenSSL 實用指令
• 使用 openssl 工具與函式庫
• 【茶包射手日記】網站憑證無效案例分析

解決蒜皮小茶包

Photo by Sigmund on Unsplash

看了暗黑執行緒解決了一個蒜皮小茶包，他的心得整理如下：

1. 沒取得不在場證明前，每個都是嫌犯，隨便放人，你可能一輩子破不了案。
2. 射茶包時謹記「剃刀原理」：先朝「耍笨」方向查，常有驚喜。
3. 沒看到證據都不算數，什麼都有可能，誰都不能相信。(我辦案有句機車名言：你願意用生命擔保問題不是出在這裡面？XD)
4. 別人成功你失敗，有可能是用的方法不同，留意此一差異可能左右偵辦方向。

連結到這個禮拜與客戶端處理連線的情境，覺得第二點應該要放在第一個思考，畢竟，有太多的『自以為是』，這個盲點會造就太多的理所當然而忽略了小細節。

如果再一次處理新主機切換的問題，透過暗黑執行緒的思維，我想會是這樣考慮問題點：

1. 能做的事情提前做好安排與驗證，不要認為理所當然就不做！
2. 「剃刀原理」：先朝「耍笨」方向查，從最基礎的設定開始確定。
3. 沒看到證據都不算數，什麼都有可能，誰都不能相信！
4. 別人成功但自己失敗，有可能是用的方法與過程不同，這就是眉角！

「專業」就是連麻瓜都聽得懂的話術

 『麻瓜（英語：Muggle），在J·K·羅琳的《哈利波特》系列小說及電影中是泛指沒有任何魔法能力的人，也不是出生於魔法家庭的人。麻瓜也可以被描述為體內沒有任何魔法血統的人。』

Photo by Vitolda Klein on Unsplash

「你不是工程師，我很難跟你解釋這個」

「這個東西很難跟你解釋...」

「這個東西不好說，因為會用到一堆有的沒的技術，例如 X、Y、Z...技術...」

其實，正所謂『術業有專攻』，每個人所擅長的領域都不一樣，究竟要如何解釋一個原理給其他同事（朋友）聽呢？每個人的素養基礎都不同，拿手的絕活也各有千秋，若要讓人清楚的了解，我想，譬喻是一個好方式，但是要是雙方都了解的舉例。

試想，今天講一句話，就有兩三個聽不懂的術語冒出來，我想，對方也會不斷地頭上冒出三條線，想當然耳的，在溝通上就會非常吃力。

因此，在溝通上，要先假設對方在不理解的前提下，盡可能不使用技術術語，而是改用譬喻的方式來描述，或是用情境來表達，這樣才會比較容易讓對方了解其關係性。

例如是網頁標籤的解釋，如果是大家所常用的 Word編輯器來對應，比如大標題之於 h1、列表之於 li這樣的說明方式，就能讓人稍微理解網頁標籤的應用。

或者是，網路傳輸協定的問題，透過黑貓貨運過程或是公路車禍的描述來呈現，也比較容易讓人了解到底傳輸問題在哪裡。

簡單來說，如果要解釋原理時，就是透過兩者都知道的東西或是現實生活的共通點（比如：銀行付款、籃球規則、咖啡廳的動線、紅綠燈切換、悠遊卡付費...）來進行譬喻。

如果是你，喜歡用哪種方式來跟別人說呢？

• 花80%時間溝通， 讓對的人有對的資訊
• 讓人舒服的 8 個職場溝通技巧，成熟大人都該記下
• 會做人就是要會溝通！立馬上手4個溝通技巧【Tim溝通日記】

關於被越界這件事

不知道大家有沒有遇過「被越界」呢？「被越界」是什麼樣的狀況呢？

自己還沒有界線的概念時，「被越界」的時候，只會隱隱覺得不對勁、不舒服，卻不知道是怎麼一回事。

Photo by Pedro Gabriel Miziara on Unsplash

在學時期或是出社會後，冷不防都會遇到類似的情境。記得大學修通識課時，在期末最後要考試前，不太熟卻一起修課的同學，在期末考試那週，自然而然地伸手要我一學期的筆記，隱約記得當時讓我覺得不舒服，但卻又無法拒絕的給出去。

出社會後，爾爾也是會遇到見面凹人的同事，可能是「順道」要我幫忙買飲料、買便當，甚至是代購！但不懂得界線概念的我，又不知道如何拒絕他人，總是搞得自己不痛快。

認識到「界線」這概念後，才了解到，原來要不要幫忙是「自己的決定」！別人若想強迫我幫忙，其實是逾越了界線，不是他人來決定的，所以自己如果不方便幫忙，其實不用特別給拒絕的理由，也不需為此有愧疚感！

但說起來很簡單，做起來還是有違和感。對於從小就不懂得拒絕，已經習慣於幫忙的我，對於自己能做得到的事，要面對面說出拒絕還是非常有難度...。

總之，現在是不斷地提醒自己，不要「不好意思拒絕」，也要記得替「自己的幫忙」付出對應的代價就是！

被越界的話，你可能還想要：

• 關係界限：畫出心理的線，感受自己，不讓別人侵門踏戶
• 內心戲常常驚濤駭浪？不明確的心理界線，最難過的還是自己——《不願放手的父母，過度涉入的你》
• 【諮商實戰錄】性格觀察01：「太有界線」與「太沒界線」的性格表現分類（2020.6改）
• 你的界線，決定你的力量

如何開始未知的爬碼（Codes）人生

來自 PTT shter (飛梭之影)的經驗談，但不論是哪一種語言或系統，接手不熟悉專案時的基本起手式約都是：找系統「啟動點」、功能「呼叫點」、下手去「嘗試改」、用業務來「猜測邏輯」，最重要的，已經運行良好的系統，可千萬不要因為自以為是而改壞了！

Photo by Sigmund on Unsplash

將 shter (飛梭之影)的步驟整理如下，供日後埋下技術債的自己參考：

1. 掌握啟動前的入口：大部分程式語言都會有一個從作業系統下命令開始執行的進入點，可能會載入 config、環境變數、命令參數這些東西，要先清楚這些東西的配置意義是什麼
2. 掌握啟動後的入口：如果是 Server或常駐程式，在執行階段就會有監聽行為。可能來自於 http API、socket、message hook、Redis subscribe ....要嘗試找到這些呼叫點的function，嘗試塞 log或 print出來，追蹤一些上下游關係，然後學習用工具打約定好的通訊格式測試，像 postman或去 redis丟 pub
3. 嘗試動動手腳：掌握入口後，就知道哪邊會像大腦發出命令，而要讓程式將命令傳達到該去的地方。所以要先假定一個起點跟終點，比如 rabbitMQ 收到訊息經過邏輯運算會將結果存進 redis某個 key值，那就去追 function的資料流向以及中途被包裝成什麼樣的資料結構，最後又轉成什麼樣的字串存 redis
4. 起身連續動作：獨立的資料處理都掌握的差不多後，接著就要看系統 state machine跟 life cycle結構的運作模型，自己去新增一些狀態、設計一些複雜的腳本看看程式運作的結果跟預期是否相同。配合前面三點，自己去修改 config丟不同參數、開發一個測試的入口，然後呼叫已知的 function卻在邏輯中判斷命令夾帶自定義的 config參數並達成某些狀態條件時要引導至自己另外寫的 function寫 log，這樣就有辦法介入原有程式並增加新功能
5. 外部工具先學有用到的部分：例如 redis 寫資料有很多命令，set, hset, rpush ..每個的用法和適合的場景不同，照理說科班教育會讓你全部學懂避免誤用才去實作。但你接手別人程式面對陌生工具時，其實是要反過來根據程式的資料結構去搞清楚這個指令的用法。先別浪費時間知道他們存在 redis 內有何差別，現階段要看的只是在程式內從介面定義讀回來的資料長什麼樣子。除非個人很有興趣（而且時間多），否則訓練自己在 code內看到對 redis 呼叫的指令能快速從文件中找到用法說明更重要
6. 一知半解下的行車紀錄：到這階段差不多你就可以開發新需求，但會有很長一段時間你覺得自己是在一知半解下做出新功能的。很多時候是從 try error發現一條可以正確執行完的路就走了，然後不知道狀態或資料變了會產生 side effect。別慌！在你不懂的地方加註解，給個編號，然後在自己的文件中寫上編號並紀錄起來。當 side effect 發生時，你有機會從文件中判斷可能與哪幾條有關，去 code搜尋註解所在檔案有助縮小判斷的範圍
7. 不要改壞勝過不要怕改壞：有些人會說就是要放膽去改不要怕壞！從零開發是如此，因為那是自己寫的，掌握度高，又沒有曾經穩定運作的印象，壞就壞了再修就好。但今天是在很多東西沒摸熟不懂的情況下，接一個已架構好的系統，維持運作穩定才不會給自己找麻煩，老闆對你的新人印象才會好。一堆需求進來，先挑自己有把握的，並告訴 PM想先上但你會花超過預期時間的東西。大多專案管理者會同意先完成一個不起眼的功能，完勝引人注目卻花超久時間還搞不定的需求。在穩定中累積經驗也累積自信，再慢慢往可能改壞的功能開發
8. 換輪胎：過一陣子可能突然發現好多新功能自己其實重複造了輪子，只是當初看不出來某個 function 跟你寫的目的相同。研究對方寫法，你會柳暗花明又一村；這時候你的思考邏輯會漸漸與原作者同化，突然開竅了，看懂很多東西了，這才是你可以開始不要怕改壞準備對模組重構或大展身手的階段。

看完你可能還會想要：

• 第一次前端接案打王(被王打)的心得
• 當你想外包寫個程式，要如何保護自己？

一分鐘快速掌握 Markdown

Markdown 已是非常普遍用來撰寫程式文件的語言，是一種輕量級標記式語言，重點讓編寫的可讀性提高。

Markdown的初衷是要讓使用者可以專注在文字內容，而不需要分心於格式轉換，當掌握好 Markdown的基本語法後，可以完全使用鍵盤上的所有按鈕來完成文章，甚至連滑鼠左右鍵都不需要觸碰。目前也有很多網站使用 Markdown來撰寫說明文件或是在論壇上發表文章與發送訊息，例如：GitHub、WordPress、Slack、FB Messenger等等。

在速度就是王道的網路世界，務必與 Markdown共生，跟著我一起提高文章的產出速度吧！

你可能還有興趣：

• Markdown文件
• Markdown 參考
• 卡斯伯的 Blog：十分鐘快速掌握 Markdown
• Markdown 基礎語法
• Markdown - 易編易讀，優雅的寫文吧！
• 撰寫 Hexo 文章 - Markdown 語法大全
• GitHub Basic writing and formatting syntax