IPv4 地址在 IPv6 結構內部的表示方式，是在前面加上 80 個零位元，然後是 16 個一位元（寫成 FFFF），再接上原本的 32 位元 IPv4 值，產生 RFC 4291 所定義的 IPv4-mapped 形式。這個單一的 128 位元值，就是當你需要把 IPv4 對等端以 IPv6 文字撰寫時，複製並貼到程式碼、設定檔、記錄檔或文件中使用的內容。在 Android 上執行此操作，代表要開啟一個瀏覽器型的轉換工具，輸入以點分十進位表示的地址，並選擇與目的平台相符的輸出格式。IPv4 to IPv6 Converter 會在你的行動瀏覽器中於本機執行，並產生同一組位元的三種等價撰寫方式：混合點分十進位、壓縮十六進位，以及完整展開形式。這個對應純粹是文字上的表示方式——它不會讓裝置具備原生 IPv6 連線能力、不會配置可路由的 IPv6 地址，也不會在通訊協定之間轉譯封包。當 IPv6 socket、API 或設定解析器期望把 IPv4 對等端以 IPv4-mapped IPv6 地址形式撰寫時，就會使用這種格式。

how to change ipv4 to ipv6 on android
how to change ipv4 to ipv6 on android

RFC 4291 IPv4-Mapped 格式詳解

RFC 4291 第 2.5.5.2 節定義了 IPv4-mapped IPv6 地址，是一個固定的 128 位元模式：80 個零位元，然後是 16 個一位元，再接上原本的 32 位元 IPv4 地址。16 個一位元以十六進位數字 FFFF 表示。IPv4 的八位元組會被視為低序的 32 位元（採用網路位元組順序），因此四個八位元組 192.0.2.1 會組合成 16 位元的十六進位字 c000 與 0201，整個 128 位元地址則變成 0000:0000:0000:0000:0000:ffff:c000:0201。每個 IPv4 地址都恰好有唯一一個 IPv4-mapped IPv6 表示方式，而每個有效的 IPv4-mapped IPv6 地址也只會回解到唯一一個 IPv4 地址。在轉換過程中，路由、前綴配置或位址空間本身都不會改變。

這種形式存在的實際理由，是因為 IPv6 大小的資料結構可以在外層程式碼使用 128 位元族系的情況下，承載一個 IPv4 對等端。Linux、BSD、Windows 與 Android 上的 Socket API，常常會在 IPv6 sockaddr 中，透過回傳 IPv4-mapped 地址來呈現一個 IPv4 連線。偏好 IPv6 文字的記錄行、白名單與分析管線，會使用 mapped 形式來寫出一致的 128 位元字串。每當目的平台使用 Python 的 ipaddress.IPv6Address.ipv4_mapped、C 語言的 IN6_IS_ADDR_V4MAPPED 巨集、Java 的 Inet6Address（當 IPv6 socket 接受 IPv4 對等端時），或 Go 的 net.IP.To4 fallback 時，能夠完整往返保存的值就是這個 mapped 形式。

三種輸出格式比較

轉換工具會輸出三種等價的文字形式。每一種都承載同樣的 128 個位元，這對於比較已解析的地址（而非比較原始字串）來說非常關鍵。

表示法192.0.2.1 的範例適用情境
混合點分十進位::ffff:192.0.2.1人可讀的記錄檔、設定檔與文件，讀者能辨識其中的 IPv4 部分
壓縮十六進位::ffff:c000:201用於程式碼、JSON 與偏好標準化 IPv6 文字的 API 的精簡形式
完整展開十六進位0000:0000:0000:0000:0000:ffff:c000:0201寬度固定的欄位、十六進位傾印與稽核紀錄，每個 16 位元群組都必須可見

全程皆使用小寫十六進位。這三種形式的差異只在於同一組位元的撰寫方式；理解 IPv6 文字的解析器，會把每一種都解析回同一個地址。這就是為什麼轉換工具會為每種形式提供獨立的複製控制項：目的平台決定了哪種撰寫方式可以安全地貼上，貼錯形式是常見的隱性標準化錯誤來源。

如何在 Android 上將 IPv4 地址轉換為 IPv6

  1. 在 Android 裝置上開啟行動瀏覽器，並前往 IPv4 to IPv6 Converter 頁面。該頁面在本機執行，不進行任何網路查詢，也不儲存任何資料。
  2. 在輸入欄位中輸入嚴格的點分十進位 IPv4 地址。必須剛好四個介於 0 到 255 的十進位八位元組，不能有空格、沒有前後空白字元、沒有前導零、不是十六進位、沒有 CIDR 後綴，也不能是主機名稱。例如，請輸入 192.0.2.1，而不是 192.00.2.1，也不是 192.0.2.1/32。
  3. 閱讀轉換工具產生的三行輸出：混合表示法 ::ffff:192.0.2.1、壓縮十六進位 ::ffff:c000:201，以及完整展開 0000:0000:0000:0000:0000:ffff:c000:0201。每一列承載的 128 個位元都相同。
  4. 選擇與目的平台相符的撰寫方式。當接收端接受結尾為點分十進位時，使用混合形式。對於標準化風格的 IPv6 文字，使用壓縮形式。當需要固定寬度的欄位或明確的 16 位元群組時，使用展開形式。
  5. 點選所選輸出旁的複製控制項，並把值貼到目的地。然後請平台在用於正式環境的設定、政策或比較之前，先解析並標準化該值。標準化是指讓目的端的函式庫將地址往返轉換為其標準化文字後，再與白名單或黑名單進行比對。
  6. 請對目的端執行測試，而不僅僅對轉換工具執行測試。某些框架會默默地把混合形式改寫為另一種等價的撰寫方式，而單純的字串前綴檢查並不足以用於授權。

轉換工具強制執行的嚴格輸入規則

可接受的輸入遵循與 Python 現代版 ipaddress 函式庫相同的嚴格規則。剛好四個十進位八位元組，每個介於 0 到 255，沒有前後空白字元、沒有正負號、沒有簡寫、不是十六進位表示法、沒有 CIDR 後綴，也沒有前導零。192.00.2.1 會被拒絕，因為第二個八位元組中的前導零在某些平台上會被解讀為舊式的八進位表示。192.0.2 會被拒絕，因為三個八位元組並不是完整的 IPv4 地址。192.0.2.1/32 會被拒絕，因為 CIDR 後綴屬於子網路遮罩，而不是主機地址。轉換工具不會解析主機名稱，因為 DNS 解析會帶來網路依賴性，且結果可能隨時間變動；請貼上你打算表示的數字地址，並在需要區分私有、回送、多點傳送、文件用途或全域可達範圍的政策時，另外對其範圍進行分類。

拒絕前導零是最重要的規則。若使用者貼上 192.00.2.1，而轉換工具默默地把它接受為 192.0.2.1，就會失去八進位模糊性的防護，同樣的數字在仍遵循八進位的平台上會被解讀為不同意義。內建八組測試案例涵蓋零、單一值、私有、回送、文件用途與 IPv4 最大值等情境，測試會驗證三種輸出形式以及無效的邊界條件。取用轉換工具輸出的應用程式碼，在依賴該值之前應執行相同的檢查，而目的端的解析器應作為地址是否可被接受的最終判定者。

Mapped 與 NAT64、6to4 及原生 IPv6 的比較

IPv4-mapped 形式經常與幾種過渡機制混淆，這些機制雖然前綴字母相同，但操作意義不同。為特定任務選錯機制，是設定錯誤的常見來源。

機制前綴或模式作用
IPv4-mapped IPv6（RFC 4291）::ffff:0:0/96在 IPv6 大小的結構中表示一個 IPv4 對等端。不涉及路由，也不進行轉譯。
已棄用的 IPv4-compatible（RFC 4291）::/96 並設定低 32 位元已由 RFC 4291 棄用。請勿用於新的部署。
6to4（RFC 3056）2002::/16自動通道，將 IPv6 包裝在 IPv4 之中以進行過渡。前綴不同，路由也不同。
NAT64（RFC 6146）預設為 64:ff9b::/96轉譯器，讓僅支援 IPv6 的用戶端能夠連線到僅支援 IPv4 的目的地。前綴不同，並涉及封包轉譯。
原生 IPv6 配置由提供者配置的 /48 或 /64來自 ISP 或內部配置器的可路由 IPv6 位址空間。轉換工具不會產生此類位址。

轉換工具刻意只輸出 mapped 地址，以避免一個通用的 Convert 按鈕默默地選擇某種部署機制。如果目的是子網路規劃、原生 IPv6 配置，或是在 Android 裝置或其背後的網路上設定轉譯服務，請使用專為該獨立任務設計的標準與工具，而非把 mapped 表示方式誤當成連線能力。

在 Android 程式碼與設定中使用結果

當裝置處於雙協定疊架狀態時，Android socket 通常具備 IPv6 能力。在裝置上繫結至 IPv6 通配位址的 Java ServerSocket 可以同時接受 IPv6 與 IPv4 對等端；IPv4 對等端會透過 Inet6Address 以 IPv4-mapped IPv6 地址的形式回報。同樣地，在雙協定疊架的監聽端上使用 network = "tcp" 進行 Go 的 net.Listen，可以接受 IPv4 連線並透過 net.IP.To4 解析它。在這兩種情況下，對於 IPv4 對等端，應用程式碼所看見的都是 mapped 形式，而轉換工具的存在，就是為了從已知的 IPv4 地址產生該精確的文字，以便用於文件、測試案例或靜態設定。

當轉換工具的輸出被貼到設定檔時，請在套用政策之前使用有維護的函式庫來解析該值。在白名單、黑名單、速率限制與地理位置規則中，應將 mapped 形式視為與原本的 IPv4 地址語意等價。對 ::ffff: 進行字串前綴檢查並不足以辨識 mapped 地址；請解析該地址，並詢問函式庫低 32 位元是否為有意義的 IPv4 對等端。當相等性很重要時，請比較已解析的地址或經標準化的正規形式，而非原始文字，因為系統可能會把同一組位元標準化為另一種等價的撰寫方式。

在正式環境的程式碼中，請將轉換工具的輸出與目的平台的 IP 位址函式庫進行交叉比對，並記錄該平台是否確實期望使用 mapped 地址。如果下游的接收端反而期望使用一般的 IPv6 地址、IPv6 子網路或 NAT64 前綴，那麼 IPv4-mapped 形式就是錯誤的值，轉換工具也不會產生正確的結果。Python 的 IPv6Address.ipv4_mapped 文件 展示了當你需要以程式方式建構相同的值（而非從頁面複製）時，在程式碼中進行的等價操作。

如果你正在權衡各種選項，如何逐步計算 IPv6 子網路遮罩對此有詳細說明。

如果你正在權衡各種選項，如何將 IPv4 轉換為 32 位元整數以便儲存對此有詳細說明。