Posted on

当ASP.NET发生Viewstate MAC的验证失败(machineKey)

问题是这样的，当 ASP.NET 因为网页还没全部下载完成时，使用者就按下网页中的任意一个PostBack 的按钮或链接时，就会发生「Viewstate MAC 的验证失败」的错误讯息！

这问题实在很难除错(DEBUG)，我想很多人连发生的原因都不知道，主要的发生原因有两种：

1. 当网站采用 Web-farm 架构时，也就是一个网站采用负载平衡的架构，用多台 Web 主机同时提供服务时。

因为 ASP.NET 预设会将 Viewstate 编码加密，验证数据的加密类型是 SHA1，验证加密数据的密钥(Key)预设是「自动产生」，所以每一台Web主机所产生的Key都不一样，所以你采用多台主机同时提供服务时，就可能会遇到从第一台Web主机读到的内容，做 PostBack 时可能会 PostBack 到第二台主机，但第二台主机看不懂第一台主机编码过的 Viewstate，而导致「Viewstate MAC 的验证失败」的例外发生！

这时你需要统一每一台主机的 machineKey 才能让每一台的编码加密的内容可以被正确验证！建议您去 The Code Project 网站看这份文件：ASP.NET machineKey Generator 上面有完整说明！

2. 因为网页还没全部下载完成，导致页面的状态不完整时就对服务器发出 PostBack 要求，因为 ViewState 不完整，而导致 Viewstate 验证失败。

这个问题只能将修改网站的 web.config 设定将 Viewstate 全部关闭才不会发生错误！如下：

<pages enableEventValidation="false" viewStateEncryptionMode ="Never" enableViewStateMac="false"/>
Posted on

对List取交集、联集及差集

前言

最近在项目中，刚好遇到这个需求，需要比对两个List，进行一些交集等操作，在以前我们可能需要写很多行来完成这些动作，但现在我们只需要藉由LinQ就能轻松达到我们的目的啰！

实际演练

※本文使用int为例，若为使用自定义之DataModel，需实现IEquatable接口才能使用

1. 取交集 (A和B都有)

List A : { 1 , 2 , 3 , 5 , 9 }
List B : { 4 , 3 , 9 }

var intersectedList = list1.Intersect(list2);

结果 : { 3 , 9 }

判断A和B是否有交集

bool isIntersected = list1.Intersect(list2).Count() > 0

2. 取差集 (A有，B没有)

List A : { 1 , 2 , 3 , 5 , 9 }
List B : { 4 , 3 , 9 }

var expectedList = list1.Except(list2);

结果 : { 1 , 2 , 5 }

判断A和B是否有差集

bool isExpected = list1.Expect(list2).Count() > 0

3. 取联集 (包含A和B)

List A : { 1 , 2 , 3 , 5 , 9 }
List B : { 4 , 3 , 9 }

var result = A.union(B)

结果 : { 1 , 2 , 3 , 5 ,9 , 4 }

Posted on

RBAC基于角色的访问控制

基于角色的访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC有许多部件，这使得RBAC的管理多面化。尤其是，我们要分割这些问题来讨论：用户与角色的指派；角色与权限的指派；为定义角色的继承进行的角色与角色的指派。这些活动都要求把用户和权限联系起来。然而在很多情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责。银行应用中，把借款、存款操作权限指派给出纳角色，把批准贷款操作权限指派给经理角色。而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。更一般来说，角色与角色的关系体现了更广泛的策略。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。 Continue reading “RBAC基于角色的访问控制”

Posted on

MVVM模式

MVVM概述

MVVM是Model-View-ViewModel的简写。
微软的WPF带来了新的技术体验，如Sliverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性揉合进去，以应对客户日益复杂的需求变化。

MVVM 功能图

mvvm

实例解析

WPF的数据绑定与Presentation Model相结合是非常好的做法,使得开发人员可以将View和逻辑分离出来,但这种数据绑定技术非常简单实用，也是WPF所特有的，所以我们又称之为Model-View-ViewModel(MVVM)。这种模式跟经典的MVP（Model-View-Presenter）模式很相似，除了你需要一个为View量身定制的model，这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性，并由一个 ViewModel 的视图的绑定属性，并可获得二者之间的松散耦合，所以需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。
在视图（View）部分，通常也就是一个Aspx页面。在以前设计模式中由于没有清晰的职责划分，UI 层经常成为逻辑层的全能代理，而后者实际上属于应用程序的其他层。MVP 里的M 其实和MVC里的M是一个，都是封装了核心数据、逻辑和功能的计算关系的模型，而V是视图（窗体），P就是封装了窗体中的所有操作、响应用户的输入输出、事件等，与MVC里的C差不多，区别是MVC是系统级架构的，而MVP是用在某个特定页面上的，也就是说MVP的灵活性要远远大于MVC，实现起来也极为简单。
我们再从IView这个interface层来解析，它可以帮助我们把各类UI与逻辑层解耦，同时可以从UI层进入自动化测试（Unit/Automatic Test）并提供了入口，在以前可以由WinForm/Web Form/MFC等编写的UI是通过事件Windows消息与IView层沟通的。WPF与IView层的沟通，最佳的手段是使用Binding，当然，也可以使用事件；Presenter层要实现IView，多态机制可以保证运行时UI层显示恰当的数据。比如Binding，在程序中，你可能看到Binding的Source是某个interface类型的变量，实际上，这个interface变量引用着的对象才是真正的数据源。
MVC模式大家都已经非常熟悉了，在这里我就不赘述，这些模式也是依次进化而形成MVC—>MVP—>MVVM。有一句话说的好：当物体受到接力的时候，凡是有界面的地方就是最容易被撕下来的地方。因此，IView作为公共视图接口约束（契约）的一层意思；View则能传达解耦的一层意思。

设计模式

因为WPF技术出现，从而使MVP设计模式有所改进，MVVM 模式便是使用的是数据绑定基础架构。它们可以轻松构建UI的必要元素。
可以参考The Composite Application Guidance for WPF(prism)
View绑定到ViewModel，然后执行一些命令在向它请求一个动作。而反过来，ViewModel跟Model通讯，告诉它更新来响应UI。这样便使得为应用构建UI非常的容易。往一个应用程序上贴一个界面越容易，外观设计师就越容易使用Blend来创建一个漂亮的界面。同时，当UI和功能越来越松耦合的时候，功能的可测试性就越来越强。
在MVP模式中，为了让UI层能够从逻辑层上分离下来，设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员，都要尊重这个契约、按照它进行设计和开发。这样，理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。借鉴MVP的IView层，养成习惯。View Model听起来比Presenter要贴切得多；会把一些跟事件、命令相关的东西放在MVC的’C’,或者是MVVM的’Vm’

MVVM优点

MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大有点：

  1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
  2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
  3.  独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
  4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

MVVM控件

使用MVVM来开发用户控件[1]。由于用户控件在大部分情况下不涉及到数据的持久化，所以如果将M纯粹理解为DomainModel的话，使用MVVM模式来进行自定义控件开发实际上可以省略掉M，变成了VVM。

Posted on

浅谈javascript继承的设计思想

我一直很难理解Javascript语言的继承机制。

它没有”子类”和”父类”的概念，也没有”类”（class）和”实例”（instance）的区分，全靠一种很奇特的”原型链”（prototype chain）模式，来实现继承。

我花了很多时间，学习这个部分，还做了很多笔记。但是都属于强行记忆，无法从根本上理解。

直到昨天，我读到法国程序员Vjeux的解释，才恍然大悟，完全明白了Javascript为什么这样设计。

下面，我尝试用自己的语言，来解释它的设计思想。彻底说明白prototype对象到底是怎么回事。其实根本就没那么复杂，真相非常简单。

Continue reading “浅谈javascript继承的设计思想”

Posted on

新手PM会遇到的五个疑问

文章主要针对新手PM在参加PM培训之后遇到的一些疑问，包括项目失控、PM如何建立威信、团队问题、跨团队合作、PM要不要对技术方案负责等疑问进行一一解答，希望对新手PM和准备踏进PM界的朋友有所帮助。

只有不断的学习，才能不断的进步！

一. 项目失控怎么办？

产生这种情况说明项目管理已经存在大的问题了。要做到的是提前预知，避免这种情况的出现。

万一出现了，首先要深入了解原因。多问自己问题，是人的原因吗？因为开发是新人？负面情绪引发懈怠？还是沟通不畅？ 再看如何解决。

1.项目内搞定：

项目内可以搞定吗？回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上。这是要注意关键路径的变化。如果没法解决，项目外解决。

2.项目外搞定：

项目外也就是看项目管理三角形，在资源、时间、范围上找解决方法。

二. PM如何建立威信？

其实PM需要建立的不是威信，而是信任。这里提到一个非常有趣的概念，Johari Windows。乔哈里之窗能够用来展现、提高个人与组织的自我意识，也可以用来改变整个组织的动态信息沟通系统。

乔哈里之窗把人的内心世界比作一个四格的窗口：

The Open Arena：开放区，自己和他人都知道的领域。

The Hidden Facade：隐藏区，自己知道别人不知道的领域。

The Blind Spot：盲区，别人知道但自己不知道的领域。

The Closed Area：封闭区，双方都不了解的领域。

真正有效的沟通，只能在公开区内进行。因为在此区域内，双方交流的主题是共知的，沟通效果是会令双方满意的。实际沟通中，很多情况下信息不对等，处于封闭区，导致沟通无效。要使得沟通更有效，需要增强信息的真实度、透明度，进而扩大开放区。扩大开放区的方式可以经由自我坦诚，或经由反馈。

三. 遇到能力强但固执的项目成员怎么办？

1. 识别出其固执的原因。

2. 和其身边的朋友多沟通，对其个性和行事风格等更多了解。

3. 使其承担责任，成为某个课题的owner，自我价值实现。

4. 多搞团建，和团队融合。

5. 不能被团队认可，请出项目组。

四. 跨团队的资源如何协调？

1. 要清楚的认识到，我们不是去要资源，而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么，得到认可，把事情变成大家的事情，而不是变成对立。

2. 要有结果，要及时反馈。

五. PM要对技术方案负责吗？

PM对技术方案影响越少越好，要认清PM的职责，是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物，他们去负责。

这里又涉及到PM正确的心态应该是怎样的：

一、善假于力，融会贯通。对人，要知人善任，了解团队，了解成员的长处短处。对事，项目管理各个环节都要融汇进去。

二、正向关注，助人自助。对人，给人机会，也要慎重淘汰。对事，接受挑战，积极正向。

Posted on

.Net下的开源持续集成

谈到持续集成，不如先谈谈集成。软件开发中的集成，通俗地讲就是把各个相关部分的东西组合起来，形成一个可用的软件。比如一个软件项目由几个小组来负责完成，每个小组负责其中一部分功能的实现，比较典型的是在现在的网络游戏开发中，通常有负责引擎的小组，负责游戏逻辑的小组，负责美工的小组，这些小组开发出的东西必须结合在一起才能形成一个可用的游戏；而每个小组内部的每个成员，他们每天在写着不同部分的代码，这些开发人员必须将各自的成果组合起来，才能完成他们共同的目标。从这个意义上讲，从每天每个开发者的日常开发，到各个软件模块的组合拼接，软件集成无所不在，一个完整可用的软件，就是通过不断地集成每个开发人员的代码而形成的。

每个开发过软件的人都能体会到，软件开发绝非一帆风顺，每个人开发出来的代码绝对不会魔术般的自己组合在一起，当新的功能加入到原有软件中的时候，往往不小心破坏了原有的功能，引入了一些bug，当老的bug被修复的时候，又往往会导致其他bug的产生，更糟糕的是，这些bug往往在当时并不能及时被发现。当小组成员们完成了自己所负责的模块，等到最后来一起集成的时候，他们可能已经做好了修复集成问题的心理准备。所有的这一切，都是每个开发人员的切肤之痛。那么，问题到底出在哪了？

让我们不妨换一种思维，让我们不要停留在如何地去修复bug和集成过程中产生的问题，我们渴望的理想状况是，每当我们开发出新的代码并将他们加入原系统中的时候，如果我们能够被及时告知我们是否破坏了原有系统的功能，那么我就能够及时的作出反应，修复这些部分。如果这个过程的粒度足够的细、足够地频繁，我们就能期望每次新功能引入的时候所引起的破坏足够小，并且修复起来足够简单，如果每个开发人员都能够享受到如此的方便并且保证新加入的功能不会影响原有的功能，我们的整个软件过程就能够以一个稳步可靠的步伐，持续增量的向前行进，而不是不断地加入新的代码，然后等到后来bug被人发现的时候被动地去修复它。我想稳步可靠、持续增量的软件过程，是我们每个开发者心目中的理想过程。从开发者的角度来看，毕竟谁也不想经历那种当发现自己的修改破坏的原有的功能的时候的恼火的感受。

持续集成通俗地说就是持续地、频繁地进行集成，每当有新的修改加入的时候，修改的作者能够被及时地告知他的修改是否在引入新的功能的同时保证原有功能的完整。如果整个软件开发团队在一开始就采用这种方式，我们的软件就能被稳步可靠的构建起来。

你也许会有疑问：“你说的只是一种理想状况罢了，谁都希望自己在加入新的代码的时候得知自己的代码是否破坏了原有的功能，但是怎么能够做到这一点，谁有能力来及时地告诉我们哪里有问题？持续集成这个想法不错，但怎么样能够做到持续集成？”我想这些问题是非常好也是关键的问题，持续集成究竟是否可行，如果可行，又该如何执行？我们这里不妨来整理一下，看看究竟什么是持续集成的难点。持续集成的难点主要在于，在新的功能加入的时候，如何来判断整个系统功能仍然完整；出错或者成功，谁来告诉我，如何告诉我；当大家一起协作的时候，如何保证每个人都能够准确地被告知而不会发生混乱。让我们来一个个地分析这些问题。

首先，确保真个系统功能完整性的手段就是测试，如果我们对所有的功能都有完整的测试，那么当新的功能引入的时候，如果某些原有的测试失败，就说明新的修改破坏了原有的功能，而失败的测试就能准确地告诉我们新的修改破坏了哪些原有的功能。其次，持续集成工具将告诉我们集成是否成功，持续集成工具通过运行整个系统中的测试，根据测试的结果来通知开发者，哪些测试失败导致的集成失败。每个软件项目通常会使用版本控制工具例如SVN、CVS，每当有开发者将新的修改加入到系统的代码库中时，持续集成工具会check out出代码库中的最新版本，使用自动化的构建工具例如Ant、Rake等，自动地编译项目中的代码、部署整个应用、准备测试所需的环境和数据、运行所有的测试包括单元测试、功能测试、集成测试等，在整个过程结束后将结果报告出来，持续集成工具会指出任何一个过程中出现的错误，并且准确地报告给开发者。在多人协作的情况下，版本控制工具确保了每个开发者的修改被正确有序地保存，当每个开发者想要提交自己的修改的之前，必须首先确保上一个人所提交的修改被成功集成，才能提交自己的代码，当确保自己的代码被正确集成之后，自己的工作才算完成，否则，就必须修复错误，再次提交，如此反复，直到被成功集成。

开源社区已经为我们提供了非常优秀的持续集成工具，CruiseControl、CruiseControl .Net已成为广泛使用而且非常成熟的持续集成工具，而持续集成所需要的自动化构建工具和版本管理工具如Ant、NAnt、SVN也已经是非常成熟。在下面，我尝试在我的使用经验的感受的基础上，挑选一些比较成熟或者很有潜力的工具，结合自己的使用经验，给大家做一些介绍。 Continue reading “.Net下的开源持续集成”

Posted on

Windows7 & 8 “用户文件夹”更改位置(更改Users目录位置)

Windows 7和Windows 8的用户文件夹默认所在位置是系统盘(通常是C盘)下的“\Users”目录之内。该文件夹中储存着所有的用户生成文件，比如你保存在“桌面”上的文件(实际上是保存在C:\Users\YourUserName\Desktop目录之中)，再比如你保存在“我的文档”里的文件(实际上是保存在C:\Users\UserName\Documents目录之中)。

而随着Windows里安装的软件越来越多，就会有越来越多的“用户生成文件”被保存在“用户文件夹”里。在资源管理器的地址栏里输入“%AppData%”之后回车，就可以看到有多少软件把用户生成数据保存在那里。

用户文件夹处于系统盘的坏处在于，如若系统盘一旦坏掉，就可能连带用户文件一并丢失;其次，由于(随着使用不断生成的)用户文件处于系统盘，也没办法时常备份“干净的系统盘”。

如果能把用户文件夹挪到另外一块儿硬盘上(或者另外一个硬盘分区上)，那么系统维护就会容易得多。平时生成的文件(大多数人放在“桌面”、“我的文档”里的文件最多)，都被保存在系统盘(或分区)之外;于是随时都可以在不必担心用户文件丢失的情况下重新安装系统(或恢复系统备份)。

注意，以下假设你想把用户文件夹设置在D盘，假定D盘是NTFS分区。

在安装Windows7或者8的过程中，要求输入用户名及密码的时候，先不如输入任何信息，按“Shift+F10”呼出DOS窗口，输入以下命令：

robocopy “C:\Users” “D:\Users” /E /COPYALL /XJ

rmdir “C:\Users” /S /Q

mklink /J “C:\Users” “D:\Users”

而后关闭DOS窗口，按部就班继续安装直至完成。

如此安装的Windows7，所有“用户特殊文件夹”(User Special Folder)的内容都已经被设置在D盘(非系统盘)上。

如果想要移动已安装好的Windows7或者8中的用户文件夹，那么就要按以下步骤操作(稍微麻烦一点，并且过程中可能会出现无法拷贝文件的情况)：

  1. 关闭所有应用程序;
  2. 按一下“Windows”键，输入“compmgmt.msc”之后按“Enter”，呼出“计算机管理器”;
  3. 鼠标点击“Administrator”，选择属性，而后在随后的对话框中去掉“帐户已禁用”之前的勾，而后关闭“计算机管理器”;
  4. 注销当前用户(注意，不是“切换用户”)，而后以“Administrator”登录
  5. 打开命令行窗口，输入以下命令：robocopy “C:\Users” “D:\Users” /E /COPYALL /XJ /XD “C:\Users\Administrator”
  6. 注销Administrator，重新用你的用户名登录Windows7，而后到“计算机管理器”里禁用Administrator;
  7. 以管理员身份打开一个DOS窗口，输入以下命令：

rmdir “C:\Users” /S /Q

mklink /J “C:\Users” “D:\Users”

搞定。

Posted on

T-SQL中的格式转换，CAST和CONVERT

在 SQL Server 2012 中将表达式由一种数据类型转换为另一种数据类型。

语法

CAST ( expression AS data_type [ ( length ) ] )
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )

参数

expression

任何有效的表达式。

data_type

目标数据类型。这包括 xml、bigint 和 sql_variant。不能使用别名数据类型。

length

指定目标数据类型长度的可选整数。默认值为 30。

style

指定 CONVERT 函数如何转换 expression 的整数表达式。如果样式为 NULL，则返回 NULL。该范围是由 data_type 确定的。有关详细信息，请参阅“备注”部分。

返回类型

返回转换为 data_type 的 expression。

备注

Date 和 Time 样式

如果 expression 为 date 或 time 数据类型，则 style 可以为下表中显示的值之一。其他值作为 0 进行处理。SQL Server 使用科威特算法来支持阿拉伯样式的日期格式。

不带世纪数位 (yy) (1) 带世纪数位 (yyyy) 标准 输入/输出 (3)
– 0 或 100（1、2） 默认 mon dd yyyy hh:miAM（或 PM）
1 101 美国 mm/dd/yyyy
2 102 ANSI yy.mm.dd
3 103 英国/法国 dd/mm/yyyy
4 104 德语 dd.mm.yy
5 105 意大利语 dd-mm-yy
6 106 (1) – dd mon yy
7 107 (1) – Mon dd, yy
8 108 – hh:mi:ss
– 9 或 109（1、2） 默认格式 + 毫秒 mon dd yyyy hh:mi:ss:mmmAM（或 PM）
10 110 美国 mm-dd-yy
11 111 日本 yy/mm/dd
12 112 ISO yymmdd

yyyymmdd
– 13 或 113（1、2） 欧洲默认格式 + 毫秒 dd mon yyyy hh:mi:ss:mmm(24h)
14 114 – hh:mi:ss:mmm(24h)
– 20 或 120 (2) ODBC 规范 yyyy-mm-dd hh:mi:ss(24h)
– 21 或 121 (2) ODBC 规范（带毫秒） yyyy-mm-dd hh:mi:ss.mmm(24h)
– 126 (4) ISO8601 yyyy-mm-ddThh:mi:ss.mmm（无空格）
– 127(6, 7) 带时区 Z 的 ISO8601。 yyyy-mm-ddThh:mi:ss.mmmZ

（无空格）
– 130 (1,2) 回历 (5) dd mon yyyy hh:mi:ss:mmmAM
– 131 (2) 回历 (5) dd/mm/yy hh:mi:ss:mmmAM

1 这些样式值返回不确定的结果。包括所有 (yy)（不带世纪数位）样式和一部分 (yyyy)（带世纪数位）样式。

2 默认值（style0 或 100、9 或 109、13 或 113、20 或 120 以及 21 或 121）始终返回世纪数位 (yyyy)。

3 转换为 datetime 时输入；转换为字符数据时输出。

4 为用于 XML 而设计。对于从 datetime 或 smalldatetime 到字符数据的转换，其输出格式如上一个表所述。

5 回历是有多种变体的日历系统。SQL Server 使用科威特算法。

重要提示
默认情况下，SQL Server 基于截止年份 2049 年来解释两位数的年份。换言之，就是将两位数的年份 49 解释为 2049，将两位数的年份 50 解释为 1950。许多客户端应用程序（如基于自动化对象的应用程序）都使用截止年份 2030 年。SQL Server 提供了 two digit year cutoff 配置选项以更改 SQL Server 使用的截止年份，从而进行一致的日期处理。建议您指定四位数年份。

6 仅支持从字符数据转换为 datetime 或 smalldatetime。仅表示日期或时间成分的字符数据转换为 datetime 或 smalldatetime 数据类型时，未指定的时间成分设置为 00:00:00.000，未指定的日期成分设置为 1900-01-01。

7 使用可选的时间区域指示符 (Z) 更便于将具有时区信息的 XML datetime 值映射到没有时区的 SQL Server datetime 值。Z 是时区 UTC-0 的指示符。其他时区则以 + 或 – 方向的 HH:MM 偏移量来指示。例如：2006-12-12T23:45:12-08:00。

从 smalldatetime 转换为字符数据时，包含秒或毫秒的样式将在这些位置上显示零。使用相应的 char 或 varchar 数据类型长度从 datetime 或 smalldatetime 值转换时，可截断不需要的日期部分。

从样式包含时间的字符数据转换为 datetimeoffset 时，将在结果末尾追加时区偏移量。

float 和 real 样式

如果 expression 为 float 或 real，则 style 可以为下表中显示的值之一。其他值作为 0 进行处理。

值 输出
0（默认值） 最多包含 6 位。根据需要使用科学记数法。
1 始终为 8 位值。始终使用科学记数法。
2 始终为 16 位值。始终使用科学记数法。
126, 128, 129 为了保持向后兼容而包括在内，在以后的版本中可能不推荐使用。

money 和 smallmoney 样式

如果 expression 为 money 或 smallmoney，则 style 可以为下表中显示的值之一。其他值作为 0 进行处理。

值 输出
0（默认值） 小数点左侧每三位数字之间不以逗号分隔，小数点右侧取两位数，例如 4235.98。
1 小数点左侧每三位数字之间以逗号分隔，小数点右侧取两位数，例如 3,510.92。
2 小数点左侧每三位数字之间不以逗号分隔，小数点右侧取四位数，例如 4235.9819。
126 转换为 char(n) 或 varchar(n) 时，等同于样式 2

xml 样式

如果 expression 为 xml，则 style 可以为下表中显示的值之一。其他值作为 0 进行处理。

值 输出
0（默认值） 使用默认的分析行为，即放弃无用的空格，且不允许使用内部 DTD 子集。

注意
转换为 xml 数据类型时，SQL Server 的无用空格处理方式不同于 XML 1.0。有关详细信息，请参阅创建 XML 数据的实例。
1 保留无用空格。此样式设置将默认的 xml:space 处理方式设置为与指定了 xml:space=”preserve” 的行为相同。
2 启用有限的内部 DTD 子集处理。

如果启用，则服务器可使用内部 DTD 子集提供的以下信息来执行非验证分析操作。

  • 应用属性的默认值。
  • 解析并扩展内部实体引用。
  • 检查 DTD 内容模型以实现语法的正确性。

分析器将忽略外部 DTD 子集。此外，不评估 XML 声明来查看 standalone 属性是设置为 yes 还是 no，而是将 XML 实例当成一个独立文档进行分析。
3 保留无用空格，并启用有限的内部 DTD 子集处理。

二进制样式

如果 expression 为 binary(n)、varbinary(n)、char(n) 或 varchar(n)，则 style 可以为下表中显示的值之一。表中没有列出的样式值将返回错误。

值 输出
0（默认值） 将 ASCII 字符转换为二进制字节，或者将二进制字节转换为 ASCII 字符。每个字符或字节按照 1:1 进行转换。

如果 data_type 为二进制类型，则会在结果左侧添加字符 0x。
1, 2 如果 data_type 为二进制类型，则表达式必须为字符表达式。 expression 必须由数量为偶数的十六进制数字（0、1、2、3、4、5、6、7、8、9、A、B、C、D、E、F、a、b、c、d、e、f）组成。如果将 style 设置为 1，字符 0x 必须为表达式中的前两个字符。如果表达式中包含的字符数为奇数或者包含任何无效的字符，则会引发错误。

如果转换后的表达式长度大于 data_type 长度，则会在右侧截断结果。

如果固定长度 data_types 大于转换后的结果，则会在结果右侧添加零。

如果 data_type 为字符类型，则表达式必须为二进制表达式。每个二进制字符均转换为两个十六进制字符。如果转换后的表达式长度大于 data_type 长度，则会在右侧截断结果。

如果 data_type 为固定大小的字符类型，并且转换后的结果长度小于其 data_type 长度，则会在转换后的表达式右侧添加空格，以使十六进制数字的个数保持为偶数。

对于 style 1，将在转换后的结果左侧添加字符 0x。
Posted on

CPU精简指令集和复杂指令集的区别

经常看到计算机课程上介绍PowerPC是采用精简指令集的CPU，酷睿CPU是复杂指令集。那么到底精简指令集和复杂指令集有什么区别呢？

以下内容摘自百度百科：

在计算机指令系统的优化发展过程中，出现过两个截然不同的优化方向：CISC技术和RISC技术。CISC是指复杂指令系统计算机(Complex Instruction Set Computer)；RISC是指精减指令系统计算机(Reduced Instruction Set Computer)。这里的计算机指令系统指的是计算机的最低层的机器指令，也就是CPU能够直接识别的指令。随着计算机系统的复杂，要求计算机指令系统的构造能使计算机的整体性能更快更稳定。最初，人们采用的优化方法是通过设置一些功能复杂的指令，把一些原来由软件实现的、常用的功能改用硬件的指令系统实现，以此来提高计算机的执行速度，这种计算机系统就被称为复杂指令系统计算机，即Complex Instruction Set Computer，简称CISC。另一种优化方法是在20世纪80年代才发展起来的，其基本思想是尽量简化计算机指令功能，只保留那些功能简单、能在一个节拍内执行完成的指令，而把较复杂的功能用一段子程序来实现，这种计算机系统就被称为精简指令系统计算机．即Reduced Instruction Set Computer，简称RISC。RISC技术的精华就是通过简化计算机指令功能，使指令的平均执行周期减少，从而提高计算机的工作主频，同时大量使用通用寄存器来提高子程序执行的速度。

通过上述内容大家基本可以知道，复杂指令集就是将更多功能步骤集成在了CPU中。例如烹饪西红柿鸡蛋的步骤包括：购买西红柿和鸡蛋，清洗食材，打鸡蛋，炒鸡蛋，放西红柿继续炒，放糖，放盐，炒熟之后盛盘上桌。这样已连续的步骤被集成在CPU内部。外部程序需要烹饪西红柿鸡蛋的时候只需要向CPU下达指令说：“烹饪西红柿鸡蛋”就可以了。复杂指令集就是将琐碎的步骤实现集成到了CPU内部，例如INTEL的SSE3等。

精简指令集就是在CPU中只有容器，调料等基本指令。需要人们在软件中写上如何协调这些指令的步骤，例如你需要向CPU下达指令说：买西红柿，清晰食材，打鸡蛋，炒鸡蛋，放西红柿继续炒，放糖，放盐，炒熟之后盛盘上桌。

由此可见当两个人比赛做饭的时候，复杂指令集的参赛者只需要不停的说“做饭做饭”就可以了。而精简指令集的参赛者需要不停的重复做饭的整个过程和步骤。如果精简指令集的参赛者嘴巴够快才能赶上复杂指令集的参赛者，但是这个“嘴巴”其实取决于内存和CPU之间的带宽是否足够。当然精简指令集也同样存在优越性，复杂指令集要通过不断增加指令的复杂程度和指令的数量来提高性能所以才会越做越大越做越耗电，而精简指令集相比较无疑体积更小更加省电。

上面只是举了一个较为偏激的例子而已，你可以认为是针对于嵌入式精简指令集和普通酷睿（X86）架构的一个比较，这个是不对等和不公平的。IBM PowerPC可是堪比至强性能的呢，这是怎么回事呢？IBM在70年代末期提出复杂指令集存在很多缺点：1，随着应用需求，复杂指令集不可能无止境的增加指令。2，实际程序运行过程中80%的指令，只占一个处理器指令系统的20%，被频繁使用的指令只是一些取、存和加这些最简单的指令。3，CPU厂商不同，复杂指令集也不同，程序的可移植性会非常差，即便可以运行效率也会相差较大（所以我常说服务器要用INTEL处理器，因为更多的程序以调用INTEL指令集为依据）。针对复杂指令集的弊端才提出了精简指令集。

IBM PowerPC无疑拥有更强劲的处理性能与更大的内存带宽，但是其精简指令集的CPU决定了只能在某个特定应用领域才能完胜至强。因为PowerPC本身硬件设计和软件设计更具备针对性。例如并发控制、数据存取。

总结：精简指令集也好，复杂指令集也罢都是CPU运行功能和实现应用的方法而已。在特定领域和行业选择不同指令集CPU才是王道。手机和火星登陆车里边永远无法放进去X86，个人家用电脑日趋强劲的多应用多功能化也永远不要奢望使用IBM PowerPC。

有人说精简指令集架构平台下对于程序员的要求会更高呢？其实未必。在写程序时精简指令集和复杂指令集开发代码上并没有特别大的差异，真正转换成特定CPU指令架构底层语言是依靠编译器实现的。也就是你的代码技能在精简指令集用，也能在复杂指令集用，主要取决于你的编译器编译出的汇编语言适用于何种架构。