恶心的0.5四舍五入问题

四舍五入是财务类应用中常见的需求，按中国人的财务习惯，遇到0.5统一向上进位，但是c#与java中默认的却不是这样。

见c#代码：

1         static void Main(string[] args)
2         {
3             Decimal d = 301353.05M;
4             Console.WriteLine(d);//301353.05
5             Console.WriteLine(Math.Round(d, 1));//301353.0
6             Console.WriteLine(Math.Round(d, 1, MidpointRounding.AwayFromZero));//301353.1
7 
8             Console.ReadKey();
9         }

默认情况下，如果要舍弃的位置上，正好值是5，系统会看前一位是奇数还是偶数，如果是偶数，则丢弃最后1位，即上面代码行5，输出的结果为 301353.0，这不符合国人的习惯，所以要人为指定第3个参数"MidpointRounding.AwayFromZero"

java中也提出了类似的做法，但是有“缺陷”

1     @Test
2     public void testScale(){
3         double d = 301353.05;
4         BigDecimal decimal = new BigDecimal(d);
5         System.out.println(decimal);//301353.0499999999883584678173065185546875
6         System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.0
7     }

类似的，在设置精度时，可以指定一个额外的参数RoundingMode.HALF_UP，表示如果要舍弃的这一位正好是5，则向上进位，代码看似没有问题，但是输出值却是301353.0

原因在于BigDecimal在计算机内部的存储值为"301353.0499999999883584678173065185546875"，即小数点第2位是4，上面的代码要求精度到1位，所以代码执行时，只看第2个小数位，其值为4，没有到HALF的标准，因此直接扔掉

改进方法：

1     @Test
2     public void testScale(){
3         double d = 301353.05 + 0.0000000001;
4         BigDecimal decimal = new BigDecimal(d);
5         System.out.println(decimal);//301353.0500000001047737896442413330078125
6         System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.1
7     }

在满足财务精度的前提下，将要处理的数字加1个微小的偏移量，这样计算机内部存储时，值变成301353.0500000001047737896442413330078125，这样小数位第2位变成了5，满足了HALF_UP的条件。

当然，这是权宜之计，如果大家有更好的通用方法，欢迎指正。