为什么BigInteger.ToString("x")在signed.MaxValue(不包括)和unsigned.MaxValue(不包括)之间的值前加0?

问题描述

示例(奇怪行为旁边的星号):

Examples (asterisks next to odd behavior):

    [Fact]
    public void BigInteger_ToString_behavior_is_odd()
    {
        writeHex(new BigInteger(short.MaxValue)); // 7fff
        writeHex(new BigInteger(short.MaxValue) + 1); // 08000 **
        writeHex(new BigInteger(ushort.MaxValue)); // 0ffff **
        writeHex(new BigInteger(ushort.MaxValue) + 1); // 10000

        writeHex(new BigInteger(int.MaxValue)); // 7fffffff
        writeHex(new BigInteger(int.MaxValue) + 1); // 080000000 **
        writeHex(new BigInteger(uint.MaxValue)); // 0ffffffff **
        writeHex(new BigInteger(uint.MaxValue) + 1); // 100000000

        writeHex(new BigInteger(long.MaxValue)); // 7fffffffffffffff
        writeHex(new BigInteger(long.MaxValue) + 1); // 08000000000000000 **
        writeHex(new BigInteger(ulong.MaxValue)); // 0ffffffffffffffff **
        writeHex(new BigInteger(ulong.MaxValue) + 1); // 10000000000000000
    }

    private static void writeHex(BigInteger value)
    {
        Console.WriteLine(value.ToString("x"));
    }

• 这有原因吗?
• 我如何删除这个多余的零?我可以只检查字符串的开头是否为零，如果是的话，将其删除?有什么需要考虑的极端情况吗?

推荐答案

在没有前导零的情况下，该数字可能看起来像是与二进制补码中相同位数的负数.放置前导零可确保未设置高位，因此不可能将其解释为负数.

Without a leading zero, the number may appear as though it is a negative number of the same number of bits in two's complement. Putting a leading zero ensures that the high bit isn't set, so it can't possibly be interpreted as a negative number.

继续操作并删除第一个字符(如果为零)，除非它是字符串中的唯一字符.

Go ahead and remove the first character, if it's a zero, unless it's the only character in the string.

这篇关于为什么BigInteger.ToString("x")在signed.MaxValue(不包括)和unsigned.MaxValue(不包括)之间的值前加0?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！