在 JavaScript 的幾個資料型別中，Number 是非常常用的一個，而且有些小地方需要特別注意，不然很容易寫出有 bug 的程式碼。
這篇會帶大家看一些案例，有些是假想的情境，也有些是我自己碰過的問題，在每個案例繼續往下講解之前，大家也可以試著把自己帶入情境，想想看自己知不知道問題的成因，又該如何避免。
在 JavaScript 的幾個資料型別中，Number 是非常常用的一個，而且有些小地方需要特別注意，不然很容易寫出有 bug 的程式碼。
這篇會帶大家看一些案例，有些是假想的情境，也有些是我自己碰過的問題，在每個案例繼續往下講解之前，大家也可以試著把自己帶入情境，想想看自己知不知道問題的成因，又該如何避免。
JavaScript 裡面一共有幾個資料型別？又分別是哪些？
要談型別之前，我們應該要先知道 JavaScript 中一共有幾種型別，並且對每一種型別都有最基本的理解。在文章開始之前，你也可以自己先數數看，再來跟我對答案，看是不是正確的。
由於 JavaScript 是會進化的，這篇的型別會以本文寫作時最新的 ECMAScript 2021 為準，底下如果有提到「spec」，指的都是 ECMAScript 2021 language specification。
我認為在理解 JavaScript 這個程式語言的時候，還需要認識到「執行環境（runtime）」這件事情，你心中的架構圖才會完整。有許多人並沒有意識到這一環，導致對於 JavaScript 或是一些技術的理解有認知上的差異；因此這一篇，就讓我們好好來談談執行環境。
附註：除了 runtime 叫做執行環境以外，execution environment 也叫做執行環境，但這兩個是完全不同的東西。為了避免歧義，底下會盡量用原文 runtime 這個詞。
另外，runtime 有許多意思，這邊的 runtime 比較像是 runtime environment 的意思。
如果你不知道什麼是 CTF，可以參考我之前寫過的：該如何入門 CTF 中的 Web 題？，裡面有簡單介紹一下什麼是 CTF，以及一些基本的題型。
去年的 DiceCTF 2021 我有認真玩了一下，最後解出 6 題 web 題，心得都在這邊：DiceCTF 2021 - Summary。今年的 DiceCTF 我有看了一下，直接被電爆，難度完全是不同等級。
這次的 Web 題一共有 10 題，1 題水題 365 隊解開，另一題比較簡單一點 75 隊解開，其他 8 題都只有 5 隊以內解開，其中還有一題沒人解開。
身為一個喜歡 web 以及 JS 相關冷知識的人，這是一個很好的學習機會，透過賽後放出的 writeup 來學習各種技巧。底下不會有所有 web 題的筆記，只會有我關注的題目。
談完了 JavaScript 的歷史以及包袱以後，我們來談談 JavaScript 本身。
不知道大家有沒有想過一個問題，當你看到一本 JavaScript 書籍或是教學文章的時候，你要怎麼知道作者沒有寫錯？要怎麼知道書裡講的知識是正確的？就如同標題所說，會不會你以前知道的 JavaScript 知識其實是錯的？
因為作者常寫技術文章，所以就相信他嗎？還是說看到 MDN 上面也是這樣寫，因此就信了？又或是大家都這樣講，所以鐵定沒錯？
有些問題是沒有標準答案的，例如說電車難題，不同的流派都會有各自認可的答案，並沒有說哪個就一定是對的。
但幸好程式語言的世界比較單純，當我們提到 JavaScript 的知識時，有兩個地方可以讓你驗證這個知識是否正確，第一個叫做 ECMAScript 規格，第二個大家可以先想想，我們待會再提。
Same site 跟 same origin 雖然看起來有點像，但其實差別不小，而這個差別也會影響到瀏覽器如何看待這兩個網站的關係還有給予的權限。
這篇文章將會談到：
事不宜遲，就讓我們開始吧！
（開始之前先回答一個疑問。是的，標題的靈感來自於忍者哈特利）
2022-01-20：修改「細究 same site」段落，補充 scheme 相關歷史，感謝 @littlegoodjack
我認為想要真正認識 JavaScript 的話，要從歷史開始。為什麼？因為從它的歷史，可以知道為什麼某些部分是這樣子設計，為什麼會有這些看似奇怪的行為。雖然有些古早的知識可能沒什麼實際用途，但對我來說是很有趣的。
學習它的歷史，並不是死背它出現的年代或是當初花了幾天開發設計，而是要去理解它出現的脈絡，去理解為什麼需要它，又為什麼它是這樣子被設計的。
想了解 JavaScript 的歷史，我最推薦的是這個資源：JavaScript: The First 20 Years，因為 JavaScript 之父 Brendan Eich 也是作者之一，想看中譯版的話在這邊：JavaScript 二十年。
這本書紀錄了從 1995 年到 2015 年，一共二十年的 JavaScript 歷史，如果有時間的話我強烈建議你把它全部看完，會對 JavaScript 有不同的體會（還會知道很多冷知識）。
底下我會挑一些我覺得比較重要的東西來寫，資料來源沒有特別講的話，都是來自於上面提到的那本書，所以若是覺得似曾相似是正常的。
由於我跟 JavaScript 差不多時候出生，因此這些早期的歷史我並沒有親身體會過，若是寫得好像我有親身參與的話，全都是想像而已。
這篇技術含量比較少一點，來跟大家分享一下寫這系列文的過程以及寫完之後的一些感想。
如果你還沒看這系列文的話，傳送門如下：
在前面幾篇裡面，我們知道 CORS protocol 基本上就是為了安全性所產生的協定，而除了 CORS 以外，其實還有一系列跟跨來源有關的東西，例如說：
是不是光看到這一系列很類似的名詞就已經頭昏眼花了？對，我也是。在整理這些資料的過程中，發現跨來源相關的安全性問題比我想像中還來得複雜，不過花點時間整理之後發現還是有脈絡可循，因此這篇會以我覺得應該比較好理解的脈絡，去講解為什麼會有這些東西出現。
除了上面這些 COXX 的各種東西，還有其他我想提的跨來源相關安全性問題，也會在這篇一併提到。
在繼續下去之前先提醒一下大家，這篇在講的是「跨來源的安全性問題」，而不單單只是「CORS 的安全性問題」。CORS protocol 所保護的東西跟內容在之前都介紹過了，這篇要談的其實已經有點偏離大標題「CORS」完全手冊，因為這跟 CORS 協定關係不大，而是把層次再往上拉高，談談「跨來源」這件事情。
所以在看底下的東西的時候，不要把它跟 CORS 搞混了。除了待會要講的第一個東西，其他的跟 CORS 關係都不大。
當你獲得了一個知識之後，要怎樣才能知道那是正確的還是錯誤的？在程式的領域中這其實是一個相對簡單的問題，只要去確認規範是怎麼寫的就可以了（如果有規範的話）。
舉例來說，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 相關的規範，證明我前面幾篇沒有在唬爛你，講得都是有所根據的。因為規格還滿長的，所以底下就是我挑幾個我認為的重點講而已，想要理解所有的規格內容，還是需要自己去看才行。