Death Note

　　注：本文系作者原创，但可随意转载。

***************************************************************************************

　　使用规则：

1. 名字被写入到『Death Note』中的『BUG』会死亡。
2. 写名字的时候，如果不在笔记中记录该『BUG』的详细特征，则无效。因此，同名同姓的『BUG』不会一次全部被杀。
3. 写完名字后如果在『人间界』单位的 40秒 内写下死因的话，会依其发生。
4. 不写死因的『BUG』全部默认为遭到『程序员』以『键盘』击杀。
5. 写下死因的同时，更会有 6分40秒 的时间可以记入死亡的详细情况。
6. 『Death Note』从落入『人间界』的那一刻起就是属于『程序员』的东西。
7. 『Death Note』的持有者可以识别『Death Note』的宿主『死神』的音貌。
8. 使用过『Death Note』的『程序员』，既不能升入『天堂』，亦不能堕入『地狱』。

****************************************************************************************

名称：| IE11 与 Chrome v31 在文件上传控件上的差异|

==============================================================================

特征：

　　ASP.NET MVC 5.O， Web项目中，需要客户上传EXCEL文件，存到WEB服务器的临时目录，处理后进行删除。

　　

// ………………
if (Request.Files.Count != 0)
            {
                var file = Request.Files[0];
                if (file != null && file.ContentLength > 0)
                {
                    var filename = file.FileName;
                    if (filename.Contains("\\"))
                        filename = filename.Split('\\').Last();
                    string filePath = Server.MapPath("~/App_Data/Temp/" + filename);

// ………………

　　此处，客户点击“上传”按钮后，后台获取文件名。首先获取文件对象file, 然后使用其属性FileName, 此处假定客户上传文件的本地路径是 "C:\\MyDocuments\\Test.excel", 那么在Chrome v31的环境下调试，FileName属性值是Test.excel, 而IE11下， FileName属性的值为 "C://MyDocuments//Test.excel"。 因此，在上面这段代码中，我对FileName做了处理 ,如果其包含"\\"，则对其使用Split方法，将其分成字符串数组并取最后一个。

　　同时，还有另外一个值得一提的是，在ASP.NET MVC下，同一个View中可能包含了其他PartialView，在进行一些操作时，可能会进行Ajax请求Get一些PartialView，但IE11下，貌似只要是Ajax的Get请求全部被缓存了起来，即使重新发起Ajax请求，页面也不会被刷新，这样一来使Ajax的Get方法失去了意义。我认为其缓存的目的是为了提高用户浏览体验及速度，但此处应该是一个失误。在Chrome下不存在此问题。不过我并未在广泛的机器环境下测试，不知道其他人是否也有同样的问题。

================================================================

名称: | 浮点数的不精确性 |

================================================================

特征：

　　看书的时候发现了一个有趣的问题，过去一直都不晓得。

　　

for ( double i = 0; i != 1.0; i += 0.1)
{
    Console.WriteLine(i);
    // 同 C++ 中的 cout<<i<<endl;
}

　　问题就是以上4行代码的输出。

　  如果没有看书并且亲自测试的话，我会认为是从 0开始，步长0.1， 输出11次，到 1.0结束。

　　但实际上，这4段代码，会一直从0输出到正无穷。

　　原因就是，这段代码最终会转为二进制代码进行计算，而二进制代码不能精确的表示0.1，只能精确的表示2的N次幂, 比如0.5。因此如果上述代码的步长改为0.5, 则会依次输出0, 0.5, 1.0。

=================================================================

名称: | 奇妙的delete操作 |

================================================================

特征：

　　

　　如图，在C++中，初始化一个指向NULL的指针，那么他指向地址00000000。

　　动态分配内存给该指针，无论是什么类型的指针，指针使用完毕后，进行delete操作。

　　释放内存后，指针并没有重新指向00000000，而是指向了00008123，此时p!=nullptr, if(p)==true。

　　如果打印输出*p的值，程序则会出现异常停止工作。

此时，应该将p重新指向nullptr。否则，将使用p将试图进入一个已经释放掉的内存产生异常。

=================================================================

名称: | Asp.Net Web API delete操作 |

================================================================

特征：

　　以前一直使用Asp.Net MVC但没有使用过Web API, 之前看了angularjs, knockoutjs这些前端MV*框架，感觉非常方便，所以最近的新项目中决定借机使用Asp.Net Web API 2.0 + knockoutjs。

　　在尝试使用的过程中，GET, POST方法都十分顺畅。但唯独delete操作，一直被提示 error 405 method not allowed。

　　这个问题我调试了整整一天多。期间各种BING, GOOGLE, BAIDU，大多数说的问题是iis的配置问题，需调整web.config等。

　　后来我新建一个最小项目实现了delete操作。但将二者的web.config配置成一样的，还是不能解决原项目的问题。

　　一个BUG一天都解决不了，网上又找不到答案，周围有大神但即便是大神没有经历过这些细节也很难帮你分析出问题所在，简直想砸电脑有木有！

　　最后，在机缘巧合之下，终于发现。原来是AJAX写法出了问题 0.0。下面上代码：

　　

 self.deleteProduct = function(product){
     $.ajax({
         url: "/api/product",
         data: { id: product.id }
         type: "delete",
         success: function(){
             // ....此处省略若干逻辑
         },
         error: function(){
             // ....
         }
     });
 }

错误代码

　　

 self.deleteProduct = function(product){
     $.ajax({
         url: "/api/product/" + product.id,
         type: "delete",
         success: function(){
             // ....此处省略若干逻辑
         },
         error: function(){
             // ....
         }
     });
 }

正确代码

　　呵呵，这两种写法的区别就是，一个直接把需要传递的参数写进URL里作为URL的一部分，另一个则在data属性中传递，则是作为表单数据的一部分。

　　原谅我这一生放荡不羁js不精通，这里具体原因就不解释了，估计先记录下这个蛋疼的问题，有机会再深入研究。

　　

=================================================================

名称: | MVC表单之坑 |

================================================================

特征：

　　坑啊！已经被这个问题坑了估计有三次了吧！不得不记录之！

　　案例：

　　　　假设某网站首页有个登录表单，顶部导航条有个登录按钮，点开弹出模态对话框，异步加载一个登录表单PartialView，也可以进行登录。登录无非就是账号，密码。

　　　　那么在首页我们会写一个form, 然后继续写 @Html.TextBoxFor( m=> m.UserName)  ....  @Html.PasswordFor( m => m.Password) 之类的。

　　　　在写另一个模态对话框的时候，打开另一个cshtml文件，其中也有一个表单，也要写 @Html.TextBoxFor( m => m.UserName) ... @Html.PasswordFor( m => m.Password) 之类的。

　　　　马蛋。 这种语法写出来的<input id="UserName" ...> <input id="Password"> ，无论是在首页View中还是在模态对话框PartialView中，只要属性名不变，他们ID就是一样的。如果你在首页调用这个模态对话框，那么就会有两个一模一样的input标签，会导致表单提交UserName这个input标签的时候总是提交html全文终最靠前的那一个。这里就需要给他们分别赋值不同的ID.。比如这么写，@Html.TextBoxFor( m => m.UserName, new { id = "index_UserName" })

和@Html.TextBoxFor( m => m.UserName, new { id = "login_UserName" }) 之类的。

　　　　这里经常会被疏忽，然后程序又可以正常的运行。不注意的话就会产生BUG -。- 简直蛋碎=、=

　　　　

=================================================================