IEEE 754 是二進位浮點數標準，它定義了像 3.141592653589793 這樣的數值如何以 1 個符號位元、一個偏置指數和一個分數欄位的方式排列，依據 IEEE 754-2019，binary32 使用 1+8+23 個位元，binary64 則使用 1+11+52 個位元。當您在瀏器中將十進位數轉換為 IEEE 754 時，JavaScript 引擎首先會將您的輸入解析為 64 位元雙精度浮點數，然後透過 DataView API 以大端序位元組順序寫入這些位元，再讀回儲存的數字，這才是實際出現在記憶體中的數值，而不是您輸入的數字。IEEE 754 浮點數轉換器 公開了完全相同的處理流程，讓您可以同時查看 binary32 或 binary64 的符號、指數、分數、分類、二進位位元以及十六進位交換格式。所有運算都在本機執行，因此沒有任何輸入或輸出會離開網頁，顯示的十六進位數值與瀏覽器將交給二進位檔案或網路協定的位元組完全一致。這使得該工具可用於除錯數值不符的報告、根據規格驗證酬載，以及了解捨入、有號零和特殊值如何在位元層級編碼。
IEEE 754 如何在您的瀏覽器中儲存數字
兩種格式都將一個 32 位元或 64 位元的字組拆分為符號、指數和分數（有時稱為有效數字或尾數）。符號位元為 0 表示正值，為 1 表示負值。指數欄位以固定偏置儲存，以便比較硬體能將其視為無符號整數，而分數欄位則儲存常規數字隱含前導 1 之後的位元。每個欄位的寬度是這兩種格式之間唯一的結構性差異，而這一個差異會進一步影響您在轉換器中看到的精確度、範圍和十六進位位數。
| 欄位 | binary32（單精度） | binary64（雙精度） |
|---|---|---|
| 總位元數 | 32 | 64 |
| 符號位元 | 1（第 31 位元） | 1（第 63 位元） |
| 指數位元 | 8（第 30 到 23 位元） | 11（第 62 到 52 位元） |
| 分數位元 | 23（第 22 到 0 位元） | 52（第 51 到 0 位元） |
| 指數偏置 | 127 | 1023 |
| 顯示的十六進位位數 | 8 | 16 |
| 位元組順序 | 大端序，最高有效位元優先 | 大端序，最高有效位元優先 |
binary32 的偏置 127 和 binary64 的偏置 1023 正是將儲存的指數轉換為無偏置數值的原因。對於常規數字，轉換器會顯示指數減去偏置；對於次常規數，無偏置指數為 1 減去偏置。無限大和 NaN 完全跳過該運算，因為它們是特殊值而非有限數，轉換器會回報其分類，而不是計算一個具有誤導性的指數。
將十進位數轉換為 IEEE 754 binary32 或 binary64
選擇符合目標消費端的編碼方向和精度。binary32 常見於 GPU 渲染器、嵌入式韌體和較舊的檔案格式；binary64 則是 JavaScript Number 值的預設、大多數語言中的 IEEE 754 雙精度浮點數，以及 64 位元網路酬載的標準交換格式。
- 在轉換器中選擇十進位轉位元或位元/十六進位轉十進位，然後選擇 binary32 或 binary64。
- 使用一般的十進位記法輸入一個十進位數值，可包含選擇性的前置符號、小數點和指數，或使用 Infinity、-Infinity 或 NaN 符記。
- 進行轉換並檢查儲存的值，以及符號位元、指數欄位、分數欄位、分類、完整二進位模式和十六進位表示法。
- 複製不含 0x 前綴的十六進位數字，並根據將接收這些位元組的語言、檔案格式、網路協定或硬體規格確認位元組順序和精度。
如需更深入的手動符號與指數運算說明，十進位數轉 IEEE 754 格式指南 以紙筆步驟展示了相同的轉換過程。
將位元與十六進位模式解碼回十進位數
當酬載以原始位元組形式來自二進位記錄、感測器讀數、儲存的檔案或遠端端點，且您需要確認它代表的數值時，反向操作就顯得重要。轉換器接受 binary32 的正好 32 個二進位數字、binary64 的正好 64 個二進位數字、正好 8 個十六進位數字或正好 16 個十六進位數字，十六進位形式可加上選擇性的 0x 前綴。任何超出這些寬度的輸入都會被拒絕，這樣可保持位元模式的明確性，並防止部分欄位的解碼。
接受的位元會被寫入 ArrayBuffer，然後透過 DataView 讀回為對應的浮點數，因此顯示的符號、指數和分數欄位完全反映您輸入的位元組。JavaScript 仍會將每個 NaN 值呈現為單一的 NaN 值，因此兩個具有不同分數位元的 NaN 酬載在數值輸出上無法區分，即使這兩個位元模式在轉換器中都仍然可見。正零和負零遵循相同的規則：它們儲存的位元不同，但一般比較會將它們視為相等，這就是為什麼像倒數這類運算會產生不同結果的原因。
為什麼 binary32 會改變您輸入的值
JavaScript 沒有 binary32 型別。它只有單一的 Number 型別，也就是 binary64，因此轉換器會先將您的輸入解析為雙精度浮點數，然後在您選擇 binary32 時將其捨入為最接近的可表示單精度值。轉換器中的儲存值一行反映了該收窄後的結果，也就是像渲染器或固定大小檔案欄位這樣的單精度消費端實際會讀取的值。該位元模式是該收窄值的 binary32 編碼，而不是原始十進位拼字的重新編碼。
這對於任何沒有精確二進位表示法的十進位數都很重要。許多常見的分數，包括 0.1，都需要無限的二進位展開，並會捨入為最接近的可表示雙精度浮點數。較大的整數在遠未達到 2 的 53 次方之前，就會在 binary64 中失去單位精確度，而 binary32 會更早失去精確度。當某個領域需要精確的金錢、識別碼或任意精度時，IEEE 754 交換格式是錯誤的工具，而應該使用十進位或大整數函式庫。轉換器將捨入過程顯示出來而不是隱藏起來，這正是將儲存值與輸入進行比較的意義所在。
零、次常規、無限大與 NaN 分類
指數欄位和分數欄位共同決定一個位元模式如何被解讀，在不同的欄位模式下，相同的位元可能表示常規數、次常規數、有號零、無限大或 NaN。分類規則是機械式的：指數全為零且分數為零時為有號零，指數全為零且分數非零時為次常規，指數非零且低於全 1 模式時為常規，指數全為 1 且分數為零時為無限大，指數全為 1 且分數非零時為 NaN。
| 指數欄位 | 分數欄位 | 分類 | 無偏置指數 |
|---|---|---|---|
| 全為零 | 全為零 | 有號零 | 非有限 |
| 全為零 | 非零 | 次常規 | 1 − 偏置 |
| 全為 1 | 全為零 | 無限大 | 特殊值 |
| 全為 1 | 非零 | NaN | 特殊值 |
| 其他任意值 | 任意 | 常規 | 指數 − 偏置 |
次常規數透過使用前導零而非隱含的前導一，填補了零與最小常規數量級之間的空白，這會犧牲精確度，但能向下延伸範圍。轉換器會將其顯示為無偏置指數為 1 減去偏置，使您能夠在相同的尺度上直接與常規數進行比較。
根據消費端驗證十六進位與位元組順序
十六進位輸出是交叉檢查最有用的產物，因為它在複製貼上過程中能完整保留，並直接對應到位元組。顯示畫面以最高有效位元組優先的順序，顯示 binary32 的正好 8 個十六進位數字和 binary64 的正好 16 個十六進位數字，這正是轉換器內部以大端序 DataView 寫入所產生的順序。如果您要餵入的消費端是小端序，或期望將 32 位元和 64 位元字組拆分為獨立的高位元和低位元，您仍然需要在將值放入檔案或封包之前重新排列位元組。
標準本身僅定義值，並未定義線路上哪個位元組優先。位元組順序屬於與消費端之間的合約，因此安全的流程是轉換、複製十六進位，然後根據將讀取這些位元組的語言、檔案格式、網路協定或硬體規格進行比對。IEEE 754-2019 標準以及 ECMAScript Number 型別規格 分別記錄了該格式和 JavaScript 的收窄行為，每當數值不符的報告出現在您的工作佇列時，這兩份文件都值得加入書籤。
一個快速的冒煙測試是將 1.0 轉換為 binary64 再轉回來，然後將 0.1 轉換為 binary64 並仔細讀取儲存值：1.0 能精確往返，而 0.1 則揭示了單一位元捨入，這解釋了程式碼審查中大多數的浮點數意外。加入 -0.0 可確認負零在解碼時其符號位元被設定，但在一般算術下仍與 0.0 比較為相等。這三個測試案例通常足以驗證轉換路徑的其餘部分是否正確連接，然後您再開始比較實際酬載。
相關閱讀：如何將十進位 IP 位址轉換為十六進位。