IPv4 位址是一個 32 位元二進位數字，以點分十進位形式 a.b.c.d 將其隱藏在明眼可見之處，其中從 0 到 4294967295 的每個值都對應到四個介於 0 到 255 之間的八位元組的唯一組合。將該二進位 IP 轉換為十進位整數，意味著使用公式 a×256³ + b×256² + c×256 + d 將四個八位元組由左至右以 256 為基底打包，再將四個項加總成單一無符號 32 位元結果。反向操作則透過以 256 為基底的反覆精確除法與餘數，依序剝離一個八位元組來還原。兩種計算皆使用 JavaScript 精確安全整數範圍內的一般整數運算，因此從 0 到 4294967295 的每個 IPv4 值都能表示，而不會產生浮點數捨入誤差。您讀到的數字與作業系統 IP 通訊協定堆疊內部使用的值完全相同，只是以更易於人類閱讀的數字呈現，而非八組四位元。
32 位元 IP 位址的結構解析
IPv4 位址寬度為 32 位元，就是這樣。熟悉的點分十進位形式只是一種顯示慣例：將這 32 位元切為四個 8 位元區塊，將每個區塊以十進位表示，並在區塊之間加上句點。RFC 791 這份網際網路通訊協定規範將位址定義為 32 位元數量，並未指定任何特定的書面表示方式，這也是為何今日多種文字形式並存。
每個 8 位元區塊稱為八位元組，可容納從 0 到 255 的任何整數。第一個八位元組佔據最高有效位元（MSB）的八個位元，第四個八位元組佔據最低有效位元（LSB）的八個位元。以二進位讀取位址的網路設備直接使用此排序；閱讀十進位位址的人類，則在四個八位元組翻譯完成後使用相同的排序。除了這個固定位置之外，並沒有「高位元組」或「低位元組」之分，單獨的任何八位元組本身也沒有隱含的意義。位址是一個數字，不是四個。
舉例而言，192.168.1.1 是單一無符號整數 3232235777 的人類可讀形式。無論您以句點書寫位址，或以單一巨大整數書寫，您指向的都是線上相同的 32 位元。連接這兩種形式的算術就是直接的基底轉換，而這正是 IP 轉十進位轉換器雙向執行的作業。
轉換背後的算術
轉換公式將點分形式視為四個以 256 為基底的數位並加以組合：
a × 256³ + b × 256² + c × 256 + d
權重為 256 的冪次：256³ 為 16,777,216，256² 為 65,536，256¹ 為 256，256⁰ 為 1。將每個八位元組乘以其位置權重並將四個乘積相加，即得到完整的無符號 32 位元整數。
逐步走過一個眾所周知的位址。以 192.168.1.1 為例：
- 192 × 16,777,216 = 3,221,225,472
- 168 × 65,536 = 11,010,048
- 1 × 256 = 256
- 1 × 1 = 1
總和：3,221,225,472 + 11,010,048 + 256 + 1 = 3,232,235,777。
反向操作為反向運算。以 256 反覆精確除法並取餘數，從最低有效位元端開始一次剝離一個八位元組。將 3,232,235,777 除以 256：商為 12,625,921，餘數為 1，這就是第四個八位元組。將 12,625,921 除以 256：商為 49,320，餘數為 1。將 49,320 除以 256：商為 192，餘數為 168。將 192 除以 256：商為 0，餘數為 192。從最後一個到第一個依序讀取餘數，即可重新得到 192.168.1.1。兩種路徑皆僅使用精確整數運算，因此不會產生捨入或浮點數損失。
| 位置 | 八位元組 | 256 進位權重 | 位元範圍（MSB 在前） |
|---|---|---|---|
| 1（最高有效位元） | a | 16,777,216 | 位元 24–31 |
| 2 | b | 65,536 | 位元 16–23 |
| 3 | c | 256 | 位元 8–15 |
| 4（最低有效位元） | d | 1 | 位元 0–7 |
這些權重是精確的 2 的冪次且永不變動，這正是轉換為完全確定性的原因。IP 轉十進位轉換器在您選擇 IPv4 轉十進位時套用相同的權重，並在您選擇十進位轉 IPv4 時反轉除法鏈。
如何使用 IP 轉十進位轉換器進行轉換
這個工具免去了手動進行算術的需要。介面刻意設計為嚴格，以確保結果與符合標準的 IP 通訊協定堆疊所計算的結果一致。
- 選擇轉換方向：當您從像 192.168.1.1 這樣的點分位址開始時，選擇 IPv4 轉十進位；當您從像 3232235777 這樣的整數開始時，選擇 十進位轉 IPv4。
- 以該方向所要求的嚴格形式輸入恰好一個值：IPv4 為以句點分隔的四個十進位八位元組，十進位則為從 0 到 4294967295 的單一無符號整數。請勿包含空格、前綴、正負號、/CIDR 後綴或前導零。
- 進行轉換並將顯示的精確結果與您預期的值進行比對。該工具顯示的是無符號整數，而非有符號 32 位元詮釋，因此首位八位元組較高的位址仍會保持為正數。
- 複製結果並確認目的地將其儲存為無符號 32 位元資料或更寬的安全型別。任何更窄且被視為有符號的型別，可能會將 2,147,483,647 以上的值顯示為負數。
八個經外部檢查的案例涵蓋兩個端點、回環（loopback）、文件區塊、私用空間、多點傳送範圍的值，以及最大位址，並為每個測試案例提供反向斷言。無效輸入涵蓋缺少的八位元組、溢位、負號、分數、空格與模糊的前導零。這些檢查皆不會發出網路請求、執行 DNS 查詢或存取外部登錄檔，所有作業都在您的瀏覽器中完成。
為何嚴格的輸入規則至關重要
該工具會拒絕看似幾乎有效，但歷來在作業系統與程式語言之間解析不一致的輸入。最常見的陷阱是前導零。192.168.001.1 看起來無害，但若干 C 系列標準函式庫會將以 0 開頭的字串視為八進位，在這種情況下 001 會是整數 1，而 010 會是十進位整數 8。透過直接拒絕輸入而非猜測，轉換器可避免當同一字串被送至兩個不同的下游解析器時發生無聲的資料損毀。
其他被拒絕的形式還包括十六進位標記法（如 0xC0.168.1.1）、省略八位元組的簡寫（如 192.168.1）、有符號整數（如 -1）、分數值，以及 CIDR 後綴（如 /24）。後綴會被拒絕而非默默忽略，因為轉換前綴需要該工具並未執行的範圍與廣播計算。若需進行此作業，子網路計算機 是合適的搭配工具：它接收 IP 與 CIDR 前綴，並在不離開瀏覽器的情況下回傳網路、廣播、主機範圍與遮罩細節。
跨語言安全儲存結果
當首位八位元組為 128 或更高時，十進位值會超過 2,147,483,647。這個界線很重要，因為許多環境將 32 位元有符號整數作為其最寬的原生型別，所以像 3232235777 這樣完全有效的無符號值，若欄位、欄或變數被宣告為有符號，便可能迴繞為負數。在將轉換結果大量載入資料庫或管線之前，請確認目的地使用的是無符號 32 位元型別、64 位元整數、經驗證的十進位字串，或 Bignum 風格的安全整數。
資料庫排序同樣取決於欄位型別。文字十進位預設按字典順序排序，這代表 10 會排在 9 之前；點分位址作為純字串也不會依其數值網路順序排序，因為八位元組邊界並未受到尊重。將值儲存為寬型無符號整數可使範圍查詢與 ORDER BY 行為以數值方式運作，這通常是人們最初求助於整數形式時所期望的。當可稽核性很重要時，請保留原始點分輸入，並記錄所選的表示方式，以便未來的讀者能瞭解該欄位是網路順序整數還是文字標籤。
十進位形式得以發揮所長之處
資料庫、試算表、防火牆匯出與測試案例，皆能受益於將位址視為單一可排序的整數。從商業設備匯出的防火牆規則通常將位址儲存為 32 位元欄位，因為這是最精簡的形式，也因為範圍比較可化為單純的數值比較。二進位通訊協定備註所指的也是同一個欄位。以網路排序或分組，會變成單一欄位的 ORDER BY，而非帶有笨拙填補的四欄位運算式。
十進位形式本身並不帶有任何網路意義。私用、回環、多點傳送、文件、保留與公開位址皆以相同的算術進行轉換。十進位值並不能證明某個位址可路由、安全、已分配，或適用於任何存取控制規則。當分類很重要時，請另行套用當前的位址登錄與網路政策。
轉換器不處理的部分
範圍刻意保持精簡。CIDR 前綴、子網路範圍、遮罩、連接埠、主機名稱與 IPv6 位址皆超出該工具所接受的範圍。若需進行網路邊界、主機數量或萬用字元遮罩的計算，請使用子網路計算機。對於像 ::ffff:c0a8:0101 這樣的 RFC 4291 IPv4 對映 IPv6 表示形式，請使用專用的 IPv4 轉 IPv6 轉換器；轉換整數並不會產生 IPv6 連線，也無法取代該工具。若要在自己的程式碼中進行通訊協定層級的解析，Python 的 ipaddress.IPv4Address 模組以及 RFC 791 中定義的位址格式，是在應用程式中內嵌此轉換時的權威參考。
當您在生產環境遷移中確實需要大量轉換時，請將樣本與目的地語言中維護良好的 IP 位址函式庫進行比對，並在提交其餘部分之前驗證資料庫型別界線。每次遷移進行八次抽樣檢查，通常足以在端序、符號與位元寬度錯誤到達生產環境之前將其攔截。
相關閱讀：如何在 Android 上將 IPv4 位址轉換為 IPv6。
相關閱讀：如何從 IP 與遮罩計算子網路位元。