進位轉換

大多數轉換器在 2^53 以上都是錯的，而且不聲不響

這就是這一頁存在的理由，值得了解，因為那個錯誤是看不出來的。

JavaScript 的數字是 64 位元浮點數，能精確表示的整數只到 9,007,199,254,740,991——也就是 2^53 − 1。超過之後，parseInt 和 toString(radix) 還是會回給你一個答案，只是低位數字是錯的。

0xFFFFFFFFFFFFFFFF 應該是 18446744073709551615。用一般數字做的轉換器會回 18446744073709552000。

而那正是開發者手上會有的輸入：64 位元雜湊值、Twitter 或 Discord 的 snowflake ID、暫存器 內容、檔案位移量。這裡全部使用 BigInt，所以不管多大都是精確的。

前綴與分隔符號都吃

手上是什麼就貼什麼。0xDEAD_BEEF、0b1010 1010、0o755 和 1,234,567 都可以——前綴 會在符合你選的基數時被去掉，底線、空白和逗號一律忽略。

不屬於該基數的數字會被指名拒絕，而不是跳過。把 1g 裡的 g 默默丟掉然後回報 1， 正是一個轉換器對打錯的字給出自信錯誤答案的方式。

二補數，以及「有號位元組」的問題

「0xFF 當成有號位元組是多少？」是一個真實的問題，而只會處理數值大小的轉換器答不出來。

同樣的位元，在不同寬度、以及有號與無號之下，代表不同的數。0xFF 無號是 255，當成 8 位元 有號數則是 −1；0xFFFF 是 65535 還是 −1，取決於你是不是以 16 位元在讀它。

每一種寬度只有在數值放得進去時才會顯示。如果一個數字裝不進一個位元組，就不會給你 8 位元 的讀法，因為根本沒有。

16 以上的基數

2 到 36 的任何基數都可以，用 0-9 接著 a-z。基數 36 是人類還打得出來的最密集形式，這 也是短 ID 和短網址服務常用它的原因。

沒有任何上傳

在這個頁面裡轉換。