JavaScript 中的強制類型轉換

時間 2019-11-06

原文原文鏈接

翻譯：瘋狂的技術宅
原文： https://www.valentinog.com/bl...

本文首發微信公衆號：前端先鋒
歡迎關注，天天都給你推送新鮮的前端技術文章javascript

JavaScript 原語

JavaScript 創建在一系列基本單元之上。你應該對其中的一些已經很熟悉了，好比字符串和數字：css

var greet = "Hello";
var year = 89;

字符串和數字是該語言所謂「原語」的一部分。完整清單是：前端

String
Number
Boolean
Null
Undefined
Object
Symbol (ES6中添加，此處不予介紹)

布爾值用來表示多是真或假的值。 null 是故意不去賦值，它一般被分配給一個變量，用於表示綁定完畢，稍後將填充有意義的內容。java

var maybe = null;

而後纔是 undefined，這意味着變量仍然沒有被附加上：python

var name;
console.log(name)
undefined

null 和 undefined 看起來很是類似，但它們是兩個大相徑庭的實體，不少開發人員仍然不肯定應該使用哪一個。git

若是要判斷 JavaScript 實例的類型，能夠用 typeof 運算符。讓咱們用字符串嘗試一下：程序員

typeof "alex"
> "string"

還有數字：github

typeof 9
> "number"

用於布爾值：面試

typeof false
> "boolean"

undefined：編程

typeof undefined
> "undefined"

還有 null：

typeof null
> "object"

結果使人驚訝！ null 看起來像一個對象，但實際上它是 JavaScript 中的一個歷史性錯誤，自語言誕生就躺在那裏了。 因爲這些問題，JavaScript 一直聲名狼借。但這僅僅是個開始。

陌生的事情

在 JavaScript 中，在兩種類型之間進行轉換時有一些奇怪的規則。讓我給你一些背景信息。先用 Python 舉一個例子。在 Python 中執行如下指令：

'hello' + 89

會給你一個明確的錯誤：

TypeError: can only concatenate str (**not** "int") to str

而在 JavaScript 中，只有天空纔是你的極限：

'hello' + 89

事實上給出：

"hello89"

若是咱們嘗試向字符串添加數組，看起來會更加奇怪：

'hello' + []

將會獲得

1. 'hello'

還有

1. 'hello' + [89]

會給你一個驚喜：

1. "hello89"

看起來這種轉換背後存在某種邏輯。它甚至適用於存在更多元素的 array ：

1. 'hello' + [89, 150.156, 'mike']

獲得：

1. "hello89,150.156,mike"

這兩行 JavaScript 足以讓 Java 程序員逃離。可是這種行爲在 JavaScript 中 100％是又意義的。所以這種隱式轉換，也稱爲強制類型轉換是很是值得探索的。

當一個數字變成一個字符串

一些編程語言有一個叫作類型轉換的概念，這意味着：若是我想把一個數字或實例轉換爲另外一種類型，那麼我必須使顯式轉換。它也適用於 JavaScript。請看如下示例：

var greet = "Hello";
var year = 89;

若是我想明確的進行轉換，能夠在代碼中代表意圖：

var greet = "Hello";
var year = 89;

var yearString = year.toString()

要麼這樣作：

var greet = "Hello";
var year = 89;

var yearString = String(year)

而後我能夠鏈接兩個變量：

greet + yearString;

可是在 JavaScript 中有一種被稱爲隱式轉換的微妙機制，由 JavaScript 引擎提供。該語言不會阻止咱們對數字和字符串進行加法操做：

'hello' + 89

會獲得：

"hello89"

可是這種轉換背後的邏輯是什麼？你可能會驚訝地發現 JavaScript 中的加法運算符 + 會自動將兩個操做數中的任何一個都轉換爲字符串，若是其中至少有一個是字符串的話！

你會發現更使人驚訝的是，這條規則在ECMAScript規範中一脈相承。第11.6.1節定義了加法運算符的行爲，我在這裏爲你作了總結：

若是 x 是 String 或 y 是String，則返回 ToString(x)，而後返回ToString(y)

這個花招只適用於數字嗎？並非。 數組和對象也會受到相同的轉換：

'hello' + [89, 150.156, 'mike']

會獲得：

"hello89,150.156,mike"

那麼下面的代碼會獲得怎樣的結果：

'hello' + { name: "Jacopo" }

要找到答案，你能夠經過將對象轉換爲字符串來進行快速測試：

String({ name: "Jacopo" })

將會獲得：

"[object Object]"

因此我有一種感受：

1. 'hello' + { name: "Jacopo" }

會獲得：

1. "hello[object Object]"

打住！這又是什麼？

JavaScript 中 [object Object] 的含義是什麼？

「[object Object]」是最多見的 JavaScript 「怪癖」之一。

幾乎每一個 JavaScript 實例都有一個名爲 toString() 的方法，有些方法是由 Object.prototype.toString 提供的。
某些類型（如數組）實現了 toString() 的自定義版本，以便在調用方法時將值轉換爲字符串。例如 Array.prototype.toString 會覆蓋 Object.toString()（也稱爲 method shadowing）。

可是當你在普通的 JavaScript 對象上調用 toString() 時，引擎會給出「[object Object]」，由於 Object.toString() 的默認行爲是由實體類型（在這種狀況下爲Object）返回字符串 object 。

如今讓咱們把注意力集中在 JavaScript 比較運算符上，它們與算術運算符同樣奇怪。

等於仍是不等於？

JavaScript 中有兩個主要的比較運算符。

第一個咱們稱之爲「弱比較」。這是抽象比較運算符（雙等號）：==。

另外一個是「強比較」，能夠經過三等號進行識別：=== 也稱爲嚴格比較運算符。它們二者的行爲方式徹底不一樣。

來看一些例子。首先，若是咱們將兩個字符串與兩個運算符進行比較，咱們獲得相同的結果

"hello" == "hello"
> true

"hello" === "hello"
> true

看上去一切都還好。

如今嘗試比較兩種不一樣的類型，數字和字符串。首先是「強比較」：

1. "1" === 1
2. false

這說得通！字符串「1」與數字1是不一樣的。可是「弱比較」會發生什麼？

1. "1" == 1
2. true

竟然是true！它沒有任何意義，除非這種行爲與咱們以前看到的隱式轉換有關。

若是適用相同的規則怎麼辦？沒錯！ ECMAScript spec 再次罷工。結果抽象比較運算符在比較它們以前在類型之間進行自動轉換。這是規範的摘要：

比較 x == y 執行以下：
若是 x 是 String 且 y 是Number，則返回比較結果 ToNumber(x)== y

規範說：若是第一個操做數是一個字符串，第二個操做數是一個數字，那麼將第一個操做數轉換爲數字。有趣。

JavaScript 規範充滿了這個瘋狂的規則，我強烈鼓勵你們對它深刻挖掘。

在此期間除非你有充分的理由不然在 JavaScript 代碼中避免使用抽象比較運算符。你之後會感謝本身的。

那麼「強勢比較」怎麼樣？規範中的說嚴格相等比較在把值與三等 === 進行比較以前沒有進行自動轉換。在代碼中使用嚴格相等比較能夠避免愚蠢的 bug。

總結

JavaScript 中有七個構建塊，即 String，Number，Boolean，Null，Undefined，Object 和 Symbol。這些類型被稱爲基元。

JavaScript 開發人員可使用算術和比較運算符來操做這些類型。可是咱們要特別注意加法運算符 + 和抽象比較運算符 ==，它本質上傾向於在類型之間進行轉換。

JavaScript 中的隱式轉換稱爲強制類型轉換，並在 ECMAScript 規範中定義。不管何時你的代碼都要使用嚴格的比較運算符 === 而不是 ==。

做爲最佳實踐，當你打算在兩種類型之間進行轉換時，請務必明確操做。JavaScript 有一堆內置對象，它們反映了原始類型：String，Number，Boolean。這些內置類型可用於在不一樣類型之間進行顯式轉換。

本文首發微信公衆號：前端先鋒

歡迎掃描二維碼關注公衆號，天天都給你推送新鮮的前端技術文章

歡迎繼續閱讀本專欄其它高贊文章：

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。