本期內容
Kalan 的話：上個禮拜的電子報由於從 google domain 搬遷至 cloudflare 時設定有誤，造成原本的電子郵件地址 weekly@kalan.dev 無法使用，而是從 kalan11@buttondown.email 寄出，抱歉造成讀者困擾。
日本投資制度 - NISA 介紹
NISA 全名叫做 Nippon Individual Savings Account，非常日本式的英文命名。這個 NISA 帳戶可以讓你在一定額度內，購買金融商品時獲得的利益免課稅。
在日本一般證券戶的投資收益所得稅高達 20%，跟台灣比起來差很多。在台灣股票的收益所得是沒有課稅的，只有證券交易所得稅跟手續費而已。我剛開始和日本同事們分享的時候他們都嚇到了。
有不少人為了節稅，都會使用 NISA 帳戶來投資。NISA 在 2024 年又更換成新制，因此在這邊只介紹新制的部分。
| つみたて投資枠 | 成長投資枠 | |
|---|---|---|
| 申請條件 | 在日本居住且年滿 18 歲以上 | 在日本居住且年滿 18 歲以上 |
| 內容 | 每年非課稅的投資額為 120 萬日幣，只能買投資信託並用來做長期投資。（需要政府認定核可的投資信託才能買） | 每年非課稅投資額為 240 萬日幣，可以投資股票與信託。 |
| 總額 | 兩個加起來 1800 萬 | 兩個加起來 1800 萬 |
這邊要注意的是，つみたて投資枠跟成長投資枠是可以同時使用的，你可以一邊用つみたて投資枠做長期投資，也可以用成長投資枠去買股票。
如果決定要在日本久待，根據個人需求可以考慮在日本辦 NISA 帳戶，否則一般證券戶白白被扣 20% 也很不划算，匯率有波動的風險再加上日幣一直跌，可以考慮用日幣投資日本市場。
我使用過的證券戶不多，目前是用 SBI 證券，算是老牌也一直是日本裡排行前幾名的證券，雖然 UI 要花一點熟悉就是了。
日本銀行的存款利率非常低，大約在 0.002% 左右，把錢存在銀行裡可以說光是通膨就會把存款逐漸吃掉，拿來 NISA 投資雖然有風險，但如果是做つみたて投資，基金都是政府認證過的話，至少可以大致保證獲利、虧損不會跟大盤差太多，所以我目前的想法是就算真的虧錢了，那也是代表整個景氣都不好。
另外一件事我覺得蠻值得考慮的是將日幣換成美金，只是現在已經是相對高點進場時間可能太晚，不過靠匯差來獲利至少會比把錢放在銀行被通膨吃掉好一些。
最後還是老話一句，投資有賺有賠，不過 NISA 先申請起來放著也不會怎樣，如果哪天急著想入場也方便，推薦給同樣在日本工作的大家。
萬能的させていただく
在日文裡，只要是在比較正式的場合當中，「〜させていただく」可以說是一定會聽到的句型。在日文敬語可以分成兩大種類，「尊敬語」與「謙讓語」。一般用來修飾自己的動作時，都會使用「謙讓語」。
不過這樣講其實也有點不正確，例如說請看一下（資料或報告之類的）「目を通していただきますようお願いします」，明明看資料的是對方，為什麼還是會用謙讓語？
「目を通していただく」雖然是指對方的動作，但從要求的那一方出發來看，可能這份資料他想要請上司檢查，這樣他才可以繼續做報告，有請求、受到恩惠的含義在，因此也會用謙讓語來表示。
回到主線，那麼「させていただく」怎麼有個使役變化又有個謙讓語いただく呢？
我們先來看幾個很常見的句子，像是「確認させていただきます（請讓我確認）」、「休ませていただきます（請讓我請假）」等等，明明做確認的人跟要請假的人都是自己，為什麼還要特地加個使役動詞跟いただく？
這算是上一期裡頭提到的 negative politeness 加強版。日文的敬語系統相當靈活，每個動詞只要搭配合適的變化都可以當作謙讓語使用，而「させていただく」透過使役動詞的使用能夠讓聽者感受到對方對自己的顧慮。
就以「確認させていただきます」來看好了，這句話常見的場景是在銀行或市役所把資料填好了拿給櫃檯，確認餐點時偶爾也會聽到對方說「確認させていただきます」。
這個句型有點隱含著對方許可了自己做這件事，自身對對方的許可表達恩惠、感謝之意，因此儘管做動作的是自己，還是會使用謙讓語。
有時候看到同事們請假都會用這個句型，久而久之竟然自己也會自然而然開始講「～させていただく」了 😂，這應該就是環境的威力吧。
從 google domain 搬家到 Cloudflare 技術專區
去年 google domain 宣布停止服務，除了感嘆 Google 又關閉了一個服務外，也不禁煩惱到底下一個 DNS 管理要用哪個服務才好。原本第一時間打算搬到 cloudflare，但發現他們似乎不支援 .dev 的網域，因此只能暫時用把 domain server 搬遷到 cloudflare DNS 的方式，然而 domain name 本身還是買在 google domain。
不過 cloudflare 腳步也很快，大概過了幾個禮拜過後就宣布支援 .dev 網域，也就完全確定了可以搬家了。
話說回來，為什麼電子報平台明明就沒有你的網域擁有權，卻還是可以用你的 domain 寄信？
從技術上來講，我們可以隨意偽造任何一個 domain 當作寄件者，不過如果沒有經過適當的設定，那麽在 email 到電子信箱之前就會先被郵件伺服器判別為垃圾郵件或可疑郵件。當然，在 UI 上如果沒有提示寄件者偽造地址，也是有可能上當，因此以後看到雖然寄件人的地址正確，但信件內容卻怪怪的時候，不妨再次確認一下寄件人地址是否是經過授權的。
要讓電子報平台正確使用你的 domain 寄信，需要設定下面這兩個紀錄：
- SPF(sender policy framework)：為了避免有人偽造你的網域信送郵件，當郵件伺服器收到來自你的網域的郵件時，會透過 SPF 來檢查寄送人的 ip 位址是否被授權使用這個 domain
- DKIM(Domain Keys Identified Mail)：這個紀錄通常會包含一組 rsa 金鑰，除了用來授權郵件伺服器用你的網域發信之外，還能確保郵件內的內容沒有被第三方修改
這兩個設定都是透過在 DNS Record 上加入 TXT record 給郵件伺服器檢查與使用，讓電子報平台就算沒有擁有你的網域也可以用你的網域發信，而不會被當作垃圾郵件。這次搬家時剛好忽略了 SPF 與 DKIM 的設定，buttondown 也沒有跳通知說設定不對，而是直接用原本的 domain 發信，導致上禮拜的寄件者是我在 buttondown 的帳號。