在上一篇 CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？裡面，我們理解了為什麼瀏覽器要有 same-origin policy，以及跨來源請求擋的其實是 response 而不是 request。在釐清了一些錯誤的觀念以及對 CORS 有基本的認知以後，就可以來講講怎麼樣解決 CORS 的問題。
先跟大家預告一下，這篇會提到的解決問題的方法並不完整。事實上，跨來源請求分成兩種，簡單請求跟非簡單請求，「跨來源請求擋的其實是 response 而不是 request」基本上只適用於簡單請求，而這一篇只會針對「簡單請求」，至於到底怎麼分簡單還是非簡單，以及非簡單的要如何處理，這些都會在下一篇提到。
想要解決基本的 CORS 錯誤，其實有滿多種方法，先來介紹幾個「治標不治本」的：
以下就會先針對這三個方法再進一步講解，講完以後我們會來講最後一個也是最正確的做法：「請後端加上 CORS header」。
三年前的時候寫了一篇文章：輕鬆理解 AJAX 與跨來源請求，提到了串接 API、AJAX、same-origin policy、JSONP 以及 CORS，當時把自己想講的都放進去了，但現在回頭看，好像有很多滿重要的部分沒有提到。
三年後，再次挑戰這個主題，並且試著表達地更完整。
會想寫這個系列是因為在程式相關的討論區上，CORS 是發問頻率很高的主題，無論是前端或是後端都有可能來問相關的問題。
所以我就想說：「好，那我來寫一個系列好了，我要試著把這個主題寫到每個碰到 CORS 問題的人都會來看這個系列，而且看完以後就知道該怎麼解決問題」，這算是我對這篇文章的目標，如果文章的品質沒辦法達成這個目標，我會持續改進。
這系列一共有六篇文章，分別是：
會從 same-origin policy 開始講起，接著講到為什麼跨來源存取資源會有錯誤，再來會講如何錯誤地以及正確地解決 CORS 相關的問題，而第三篇會詳細講解跨來源請求的詳細流程，像是 preflight request 之類的東西。
基礎的部分看前三篇就夠了，接下來會比較深一點。第四篇會帶你一起看 spec，證明前面幾篇不是我在虎爛的，而第五篇則是帶大家看看 CORB（Cross-Origin Read Blocking）、COEP（Cross-Origin Embedder Policy）或是 COOP（Cross-Origin-Opener-Policy）之類的跨來源相關規定，以及相關的安全性問題，最後一篇則是一些比較零散的主題以及心得感想。
當你獲得了一個知識之後，要怎樣才能知道那是正確的還是錯誤的？在程式的領域中這其實是一個相對簡單的問題，只要去確認規範是怎麼寫的就可以了（如果有規範的話）。
舉例來說，JavaScript 的各種語言特性在 ECMAScript Specification 裡面都找得到，為什麼 [] === [] 會是 false，為什麼 'b' + 'a' + + 'a' + 'a' 會是 baNaNa，這些在規範裡面都有，都會詳細說明是用怎樣的規則在做轉換。
而 Web 相關的領域除了 JS 以外，HTML 或是其他相關的規範幾乎都可以在 w3.org 或是 whatwg.org 裡面找到，資源相當豐富。
雖然說瀏覽器的實作有可能跟規範寫的不一樣（像是這篇），但 spec 已經是最完整而且最有權威性的一個地方了，因此來這邊找準沒錯。
如果搜尋 CORS 的 spec，可能會找到 RFC6454 - The Web Origin Concept 以及 W3C 的 Cross-Origin Resource Sharing，但這兩份都叫這一份叫做 Fetch 的文件給取代了。
當初我疑惑了一陣子想說是不是自己看錯，fetch 跟 CORS 有什麼關係？後來才知道原來這邊的 fetch 跟 Web API 那個 fetch 其實不同，這份規格是定義了所有跟「抓取資料（fetch）」有關的東西，就如同它的大綱所寫的：
The Fetch standard defines requests, responses, and the process that binds them: fetching.
這一篇就讓我們一起來看一下 CORS 相關的規範，證明我前面幾篇沒有在唬爛你，講得都是有所根據的。因為規格還滿長的，所以底下就是我挑幾個我認為的重點講而已，想要理解所有的規格內容，還是需要自己去看才行。
部落格需要顯示發佈時間，餐廳網站要顯示訂位時間，拍賣網站則是要顯示訂單的各種時間，無論你做什麼，都會碰到「顯示時間」這個很常見的需求。
這問題看似簡單，不就是顯示個時間嗎？但如果牽扯上「時區」的話，問題就會變得再更複雜一些。以時區來說，通常會有這幾個需求：
而這還只是顯示的部分而已，還有另外一個部分是與後端的溝通，這個我們可以待會再提，但總之呢，要正確處理時間跟時區並不是一件簡單的事。
在最近這一兩份工作剛好都有碰過相關的問題，因此對這一塊有點小小心得，就寫了這一篇來跟大家分享一下。
最近公司的同事修了一門資安相關的課，因為我本來就對資安滿有興趣的，所以就會跟同事討論一下，這也導致了我這兩週一直在研究相關的東西，都是一些以前聽過但沒有認真研究過的，例如說 LFI（Local File Inclusion）、REC（Remote code execution）、SSRF（Server-Side Request Forgery）或是各種 PHP 的神奇 filter，也能複習原本就已經相對熟悉的 SQL Injection 跟 XSS。
而 CTF 的題目裡面常常會出現需要繞過各種限制的狀況，而這就是考驗對於特定協定或者是程式語言的理解程度的時機了，要想想看怎麼在既有的限制之下，找出至少一種方法可以成功繞過那些限制。
原本這一週不知道要寫什麼，想寫上面提的那些東西但還沒想好怎麼整理，之前的 I Don’t know React 後續系列又還沒整理完，就想說那來跟大家做個跟「繞過限制」有關的趣味小挑戰好了，那就是標題所說的：
在 JavaScript 當中，你可以做到不用英文字母與數字，就成功執行 console.log(1) 嗎？
換句話說，就是程式碼裡面不能出現任何英文字母（a-zA-Z）與數字（0-9），除此之外（各種符號）都可以。執行程式碼之後，會執行 console.log(1)，然後在 console 印出 1。
如果你有想到以前聽過什麼有趣的服務或是 library 可以做到，先不要。在這之前可以自己先想一下，看有沒有辦法寫出來，然後再去查其他人的解決方法。
若是能從零到有全都自己寫出來，就代表你對 JS 這個程式語言以及各種自動轉型的熟悉程度應該是滿高的。
底下我就提供一下我自己針對這一題的一些想法以及解題過程，有雷，還沒解完不要往下捲動。
==防雷==
==防雷==
==防雷==
==防雷==
==防雷==
如果有先寫過其他 function 不是 first-class 的程式語言，在寫 JavaScript 的時候應該會經歷一些陣痛期，想說到底在做什麼——至少我是這樣的。
我當初發現可以把 function 當作參數到處傳遞的時候，對於比較複雜的 code 就要想很久，而 function 的其他行為也是讓我一頭霧水，例如說 function 居然也是 object，還有 this 到底是什麼鬼東西。
這一篇主要是想分享一些我覺得 function 比較有趣的地方。可是呢，直接開始講一大堆知識太無趣了，我希望能引起大家對這些知識的好奇程度，而想要引起好奇，最好的方法就是提供一個「你也會感興趣的問題」，你就會有動力繼續往下看了。
因此底下就以幾個小問題作為開場，雖然是問題的形式，但答不出來也完全沒有關係，如果你對這些問題的答案有興趣的話再往下看，沒興趣的話出口直走到底左轉。
話說這篇標題本來想取叫：「JavaScript function 知多少」或是「有趣的 JavaScript function」，但這種標題太無趣了，所以才想到這種輕小說式（？）的標題。
在我以前寫過的兩篇文章：我知道你懂 hoisting，可是你了解到多深？以及所有的函式都是閉包：談 JS 中的作用域與 Closure 裡面，都談到了 let 與 var 作用域的不同。
let 的作用域是 block，而 var 則是 fucntion，像這個就是經典案例：
for(var i=1; i<=10; i++) {
setTimeout(function() {
console.log(i)
})
}原本預期會依序輸出 1~10，沒想到卻輸出了 10 個 11。背後原因就是因為第三行那個 i 永遠都只有一個，就是 for 迴圈宣告的那個 var i，從頭到尾都是同一個變數。
而經典解法也很簡單，把 var 改成 let 就搞定了：
for(let i=1; i<=10; i++) {
setTimeout(function() {
console.log(i)
})
}搞定的原因是，可以把上面程式碼看作是下面這種形式：
{
let i=1
setTimeout(function() {
console.log(i)
})
}
{
let i=2
setTimeout(function() {
console.log(i)
})
}
...
{
let i=10
setTimeout(function() {
console.log(i)
})
}由於 let 的作用域是 block，所以在每一圈迴圈裡面，其實都是一個新的 i，因此迴圈跑 10 圈就有了 10 個不同的 i，最後當然是輸出 10 個不同的數字。
因此 var 跟 let 在這個範例最大的區別就在於變數的數量，前者只有 1 個，後者卻有了 10 個。
好，既然知道了 let 與 var 的差別以後，就可以來看看這篇最主要想討論的問題。
其實這問題是來自於 YDKJS（You Dont Know JS，中譯本翻做：你不知道的JavaScript） 的作者 @getify 在他的推特上所提出的：
question for JS engines devs…
is there an optimization in place for this kind of code?for (let i = 0; i < 10; i++) { // no closure }IOW, where the behavior of creating a new
iper iteration is not needed nor observable… does JS skip doing it?
若是沒有看得很懂，可以繼續看延伸的另外一則推：
here’s a variation on the question… will JS engines exhibit much performance difference between these two loops?
for (var i = 0; i < 100000000; i++) {
// do some stuff, but not closure
}
for (let i = 0; i < 100000000; i++) {
// do the same stuff (no closure)
}簡單來說呢，平常用 let 搭配迴圈的時候，不是如我們上面所說的，每一圈都會有一個新的i嗎？既然是這樣的話，那 var 與 let 應該就會有效能上的差異，因為 let 必須每一圈都 new 一個新的變數出來，所以 let 會比較慢。
那如果迴圈裡面並不需要每一圈都有新的 i，JS 引擎會做優化嗎？這個問題就是這樣，主要是想探討 JS 引擎會不會針對這種行為去做優化。
那要怎麼知道呢？要嘛你是 JS 引擎的開發者，要嘛你去看 JS 引擎的原始碼，但這兩種難度都有點太高。不過別擔心，還有第三種：看 JS bytecode。
在這兩三年之間，「刷題」似乎成為了一種風潮。本科系要去面試大公司的時候要刷題，非本科系出去面試也要刷題，好像只要沒有刷題就會落後他人，就會被公司刷掉。
其實我一直不是很喜歡「刷題」這個詞，主要是因為「刷」這個字。不知道大家對這個字的解讀是什麼，但我會認為有種「為了寫題目而寫題目」的感覺，就好像題海戰術那樣。雖然說題海戰術用得好的話成效滿顯著的，但總感覺很多人刷到最後會變成「看過的題目就會，沒看過的就一定不會」，如果是這樣子的話，那我覺得不是一件好事。
之前我有寫了一篇文章：當我們在學程式時，要學的到底是什麼？，稍微談了一下這件事情。
總之呢，比起刷題這個詞，我更喜歡用「程式解題」四個字來表達我想表達的意思。