参数校验的几种方式
 如果默认的字段类型和选项不能满足需求，需要再补充校验行为，可以使用以下三种方法：
 
通过字段中的validators 选项进行校验
 validate_<field_name>方法：对<field_name>字段进行验证
 validate方法：对多个字段进行比较校验
 
一、通过 validators选项校验
 
在序列化器字段中添加validators选项参数进行校验，例如：
 
def validate_name(value):
    # 校验部门名称
    if not re.match('^[\u4e00-\u9fa5]+$', value):
        raise ValidationError('部门名称只能为中文')
    return value

class DepartmentSerializer(serializers.Serializer):
    id = serializers.IntegerField(read_only=True, label='ID')

    name = serializers.CharField(max_length=20, label='部门名称',
                                 required=True, allow_null=True, validators=[validate_name])
 
二、validate_：对<field_name>字段进行验证
 
注意：若校验失败，则 raise ValidationError异常
 
class DepartmentSerializer(serializers.Serializer):
    """部门数据序列化器"""
    ...
    def validate_name(self, value):
        # 校验部门名称
        if not re.match('^[\u4e00-\u9fa5]+$', value):
            raise ValidationError('部门名称只能为中文')
        return value
 
测试
 
>>> from users.models import *
>>> from users.serializers import *
>>> s = DepartmentSerializer(data={'name':'研-发部', 'create_date':'2018-1-1'})
>>> s.is_valid()
False
>>> s.errors
{'name': [ErrorDetail(string='部门名称只能为中文或英文字母', code='invalid')]}
 
三、validate：同时对多个字段进行比较验证
 
用户注册，校验两次输入的密码是否一致
 
# 模型： users/models.py
 class User(models.Model):
     password = models.CharField(max_length=30)

 # 序列化器： users/serializer.py
 class UserSerializer(serializers.Serializer):

     password = serializers.CharField(max_length=30, write_only=True)
     password2 = serializers.CharField(max_length=30, write_only=True)

     def validate(self, attrs):
         # 校验两次输入的密码是否正确
         password = attrs['password']
         password2 = attrs['password2']
         if password != password2:
             raise serializers.ValidationError('两次输入的密码不一样')
         return attrs
 
测试
 
 >>> from users.models import *
 >>> from users.serializers import *
 >>> s = UserSerializer(data={'password':'12345', 'password2': '12345x'})
 >>> s.is_valid()
 False
 >>> s = UserSerializer(data={'password':'12345', 'password2': '12345'})
 >>> s.is_valid()
 True

SpringMVC集成Hibernate Validator进行注解式的参数校验
 
                                                        ——让代码更少、更加专注于业务逻辑
 
1 问题背景：
 
参数验证是一个常见的问题，例如验证用户输入的密码是否为空、邮箱是否合法等。但是无论是前端还是后台，都需对用户输入进行验证，以此来保证系统数据的正确性。对于web来说，有些人可能理所当然的想在前端验证就行了，但这样是非常错误的做法，前台的验证一般是通过Javascript，js代码是可以被禁用和篡改的，所以相对后台检验而言，安全性会低一些。前端代码对于用户来说是透明的，稍微有点技术的人就可以绕过这个验证，直接提交数据到后台。无论是前端网页提交的接口，还是提供给外部的接口，参数验证随处可见，也是必不可少的。总之，一切用户的输入都是不可信的。
 
基于这样的常识，在后端的代码开发中，参数校验是一个永远也绕不开的话题。然而编写参数校验代码的过程是一个技术含量不高，及其耗时，繁琐的过程。比如极大多数的参数校验代码就是：判断一下用户名是否已经存在、用户名长度是否满足要求、用户填写的邮箱是否合法。年龄参数是不是一个整数等等。为了减少重复代码的开发，许多有技术积淀的公司，一般都会提供一套或多套特有的参数校验工具类。以此减少代码量。这种做法在项目中非常普遍，有了这些工具类库，程序员在编写业务代码的过程中，工作效率可以大大提升。
 
然而，即便聪明如上述做法，我们的业务逻辑中依然还是可以见到大量的参数校验逻辑，倘若项目架构的不够合理，这些与参数校验逻辑有关的代码量会更多，真是XXX的裹脚布，又臭又长。大量繁杂的参数校验代码混杂在业务逻辑中，一来降低了代码的可读性；二是让人对业务本身的理解难度加大，很多刚加入公司的人往往是通过读码来理解业务的，公司的一些业务培训一般只能讲个大概，然而在阅读代码的过程中稍有不慎便会被这些“额外”的代码扰乱思路，对于新手，那更是异常噩梦，倘若老员工辞职了，撒手抛给新来的，这样的项目能不能维护下去都是个问题了。
 
2 Hibernate Validator介绍：
 
不过对于java开发者来说，解决上述难题越来越容易了。随着大量的Bean Validation 框架的问世，和主流框架对这些校验框架的集成和支持。 我们是非常容易的能将业务逻辑和参数校验代码相分离的，其实说是分离还不够恰当，这里即将要介绍的hibernate Validator可以以注解的方式对参数进行校验，业务逻辑中的极大多数参数校验代码都可以省去，可以使代码更简洁，更加专注于业务逻辑。hibernate Validator是 Bean Validation 的参考实现，Hibernate Validator 提供了 JSR 303 规范中所有内置 constraint 的实现，除此之外还有一些附加的 constraint。为了满足特定的需求，用户还可以自实现更多的constraint以便满足特定的需求。
 
3 集成 Hibernate Validator前后代码对比：
 
为了能一目了然的看到集成Hibernate Validator的好处，我们来比较一下下述代码。假设我们有这样一个方法， 该方法是从某个SSM（Spring MVC + Spring + Mybatis）项目的controller层摘录下来的。该方法的目的是查询所有名字叫某某的男性或女性同胞。名字参数name不能为空值，性别参数gender必须为“F”或“M”，分别代表女性或男性。注意，这里的示例代码将参数校验逻辑放在了controller层，校验通过后再进入service层。可能有的项目会将参数校验挪到service层，当然这不是重点。这个查询方法的代码如下：
 
@RequestMapping(value = "/all", method = RequestMethod.GET)
@ResponseBody
public List<String> getAllPeople(String name, String gender) {

        if (StringUtils.isEmpty(name)) {
            throw new BusinessException(FALL, "用户名不能为空");
        }
        if (gender == null || (!gender.equals("F") && !gender.equals("M"))) {
            throw new BusinessException(FALL, "性别不合法");
        }

        return cityService.getAllCitys(name, gender);
}
 
上述查询方法是在没有集成Hibernate Validator的项目中，参数校验的一般方式，为了辅助完成参数校验，我们还不得不封装了一个工具类StringUtils用于判断字符串是否为空。如果参数异常，则抛出业务异常，该异常会交给框架的异常处理机制进行处理。我们可以看到，仅仅两个简单的参数就不得不写上多行代码来完成要求。然而，当我们将上述SSM项目与Hibernate Validator集成之后，参数校验可以在方法签名中完成，方法体内无需写任何与参数校验相关的代码逻辑。如果参数校验不通过，同样也会抛出异常，该异常同样会交给框架的异常处理机制进行处理。
 
@RequestMapping(value = "/all", method = RequestMethod.GET)
@ResponseBody
public List<String> getAllPeople(
            @NotBlank(message = "用户名不能为空" ) String name,
            @Gender(message = "性别不合法") String gender) {

        return cityService.getAllCitys(name, gender);
}
 
通过上述代码的比较，可以很明显的看到，后者代码简洁了很多，在参数数量很多，业务复杂的的方法中，代码量的差异会更加明显，同样的，代码的可读性也会有了天壤之别。
 
4. Spring MVC集成Hibernate Validator步骤：
 
4.1 如果项目中使用Maven，就需要在pom.xml中添加如下一段，Hibernate需要Java EL表达式，因此需要添加EL的依赖项。
 
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-validator</artifactId>
   <version>5.3.4.Final</version>
</dependency>
<dependency>
   <groupId>javax.el</groupId>
   <artifactId>javax.el-api</artifactId>
   <version>2.2.4</version>
</dependency>
<dependency>
   <groupId>org.glassfish.web</groupId>
   <artifactId>javax.el</artifactId>
   <version>2.2.4</version>
</dependency>
 
4.2 在springmvc的配置文件（此处使用默认名：spring-mvc.xml）中添加如下配置开启校验功能
 
    <mvc:annotation-driven validator="validator" />
<!--    bean级别的校验 方法中的参数bean必须添加@Valid注解，后面紧跟着BindingResult result参数-->
    <bean id="validator"
        class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean">
        <property name="providerClass" value="org.hibernate.validator.HibernateValidator" />
    </bean>
<!--    方法级别的校验  要校验的方法所在类必须添加@Validated注解-->
    <bean
        class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor">
        <!-- 可以引用自己的 validator 配置，在本文中（下面）可以找到 validator 的参考配置，如果不指定则系统使用默认的 -->
        <property name="validator" ref="validator" />
    </bean>
 
4.3 在校验的方法所在类上添加@Validated注解可以开启方法级别的校验，第3节代码对比的列子中，参数校验注解直接添加在方法签名上的方法参数前面，这就是所谓的方法级别的校验。所谓bean级别的校验，就是方法的参数是一个Java Bean，校验的注解则添加到Java Bean的相应属性上。目前，在使用Spring MVC的项目中，bean级别的校验必须给bean参数添加@Valid注解。但在使用Jersey（一个REST FULL的标准实现框架）替代Spring MVC的项目中，则没有此要求。所以代码还会更方便。
 
5 Hibernate Validator 中内置的 constraint简介
 
       注解                作用
 
@Valid 被注释的元素是一个对象，需要检查此对象的所有字段值 
 @Null 被注释的元素必须为 null 
 @NotNull 被注释的元素必须不为 null 
 @AssertTrue 被注释的元素必须为 true 
 @AssertFalse 被注释的元素必须为 false 
 @Min(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 
 @Max(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值 
 @DecimalMin(value) 被注释的元素必须是一个数字，其值必须大于等于指定的最小值 
 @DecimalMax(value) 被注释的元素必须是一个数字，其值必须小于等于指定的最大值 
 @Size(max, min) 被注释的元素的大小必须在指定的范围内 
 @Digits (integer, fraction) 被注释的元素必须是一个数字，其值必须在可接受的范围内 
 @Past 被注释的元素必须是一个过去的日期 
 @Future 被注释的元素必须是一个将来的日期 
 @Pattern(value) 被注释的元素必须符合指定的正则表达式
 
6 自定义校验注解示例
 
6.1 在第3节中，我们使用到了@Gender注解表示男女的性别，这其实不是Hibernate Validator自带的，而是一个自定义的注解。由于HV中的标准注解可能满足不了某些校验场景，因此自定义校验注解是有必要的。之所以写本文，目的是推荐公司的项目也也可以尝试使用这个优秀的bean validation框架，所以自定义注解的实现细节此处不进一步讲述，只是给出两个已经实现的列子，一个是之前使用到的注解@Gender，用于校验用户的性别。另一个注解是@PhoneNumber, 用于限制上传的参数必须是手机号。
 
6.2 @Gender注解类代码如下：
 
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = Gender.Validator.class)
@SuppressWarnings("javadoc")
public @interface Gender
{

    String message() default "invalid gender";
    boolean allowBlank() default false;

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default{};

    public class Validator implements ConstraintValidator<Gender, String>
    {
        boolean allowBlank;

        @Override
        public void initialize(Gender gender)
        {
            allowBlank = gender.allowBlank();
        }


        @Override
        public boolean isValid(String arg0, ConstraintValidatorContext arg1)
        {
            if (arg0 == null)
            {
                return allowBlank;
            }
            return arg0.equalsIgnoreCase("M") || arg0.equalsIgnoreCase("F");
        }
    }
}
 
6.2 @PhoneNumber注解如下：
 
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = PhoneNumber.Validator.class)
@SuppressWarnings("javadoc")
public @interface PhoneNumber {

    String message() default "invalid phone number";

    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    public class Validator implements ConstraintValidator<PhoneNumber, String> {

        @Override
        public void initialize(PhoneNumber arg0)
        {

        }

        @Override
        public boolean isValid(String arg0, ConstraintValidatorContext arg1)
        {
            return StringUtil.isPhoneNumber(arg0);
        }}
}
 
@PhoneNumber注解中用到的工具类StringUtil的isPhoneNumber方法如下：
 
public final String PHONE ="^((13[0-9])|(14[5,7])|(15[^4,\\D])|(17[0,5-8])|(18[0-9]))\\d{8}$";
public static boolean isPhoneNumber(String phone)
    {
        if (StringUtil.isNullOrEmpty(phone))
        {
            return false;
        }
        return match(RegExp.PHONE, phone);
    }
 
7 简单总结
 
本文主要介绍了hibernate Validator这一优秀的Bean Validation框架。并介绍了Spring MVC中集成这个参数校验框如何将业务逻辑与参数校验逻辑相分离，从而保持代码的精简和优雅。易读和易维护。本人之前所在公司的多个项目采用了这种方式，使得项目代码无比清爽。本人也愿意分享自己积累的一点微薄知识，如果将本文涉及的技术与上一篇篇经验案列讲到的内容联合使用，更会使项目增色不少，但愿在后续的项目中，本人能见证这一成熟技术的应用。

 
文章目录
 
简介
在字符串标准化之后进行校验
注意不可信字符串的格式化
小心使用Runtime.exec()
正则表达式的匹配

 
简介
 
为了保证java程序的安全，任何外部用户的输入我们都认为是可能有恶意攻击意图，我们需要对所有的用户输入都进行一定程度的校验。
 
本文将带领大家探讨一下用户输入校验的一些场景。一起来看看吧。
 
在字符串标准化之后进行校验
 
通常我们在进行字符串校验的时候需要对一些特殊字符进行过滤，过滤之后再进行字符串的校验。
 
我们知道在java中字符是基于Unicode进行编码的。但是在Unicode中，同一个字符可能有不同的表示形式。所以我们需要对字符进行标准化。
 
java中有一个专门的类Normalizer来负责处理，字符标准化的问题。
 
我们看下面一个例子：
 
    public void testNormalizer(){
        System.out.println(Normalizer.normalize("\u00C1", Normalizer.Form.NFKC));
        System.out.println(Normalizer.normalize("\u0041\u0301", Normalizer.Form.NFKC));
    }
 
输出结果：
 
Á
Á
 
我们可以看到，虽然两者的Unicode不一样，但是最终表示的字符是一样的。所以我们在进行字符验证的时候，一定要先进行normalize处理。
 
考虑下面的例子：
 
    public void falseNormalize(){
        String s = "\uFE64" + "script" + "\uFE65";
        Pattern pattern = Pattern.compile("[<>]"); // 检查是否有尖括号
        Matcher matcher = pattern.matcher(s);
        if (matcher.find()) {
            throw new IllegalStateException();
        }
        s = Normalizer.normalize(s, Normalizer.Form.NFKC);
    }
 
其中\uFE64表示的是<,而\uFE65表示的是>,程序的本意是判断输入的字符串是否包含了尖括号，但是因为直接传入的是unicode字符，所以直接compile是检测不到的。
 
我们需要对代码进行下面的改动：
 
    public void trueNormalize(){
        String s = "\uFE64" + "script" + "\uFE65";
        s = Normalizer.normalize(s, Normalizer.Form.NFKC);
        Pattern pattern = Pattern.compile("[<>]"); // 检查是否有尖括号
        Matcher matcher = pattern.matcher(s);
        if (matcher.find()) {
            throw new IllegalStateException();
        }
    }
 
先进行normalize操作，然后再进行字符验证。
 
注意不可信字符串的格式化
 
我们经常会使用到格式化来对字符串进行格式化，在格式化的时候如果格式化字符串里面带有用户输入信息，那么我们就要注意了。
 
看下面的例子：
 
    public void wrongFormat(){
        Calendar c = new GregorianCalendar(2020, GregorianCalendar.JULY, 27);
        String input=" %1$tm";
        System.out.format(input + " 时间不匹配，应该是某个月的第 %1$terd 天", c);
    }
 
粗看一下没什么问题，但是我们的input中包含了格式化信息，最后输出结果：
 
 07 时间不匹配，应该是某个月的第 27rd 天
 
变相的，我们获取到了系统内部的信息，在某些情况下面，可能会暴露系统的内部逻辑。
 
上面的例子我们应该将input也作为一个参数，如下所示：
 
    public void rightFormat(){
        Calendar c = new GregorianCalendar(2020, GregorianCalendar.JULY, 27);
        String input=" %1$tm";
        System.out.format("%s 时间不匹配，应该是某个月的第 %terd 天",input, c);
    }
 
输出结果：
 
 %1$tm 时间不匹配，应该是某个月的第 27rd 天
 
小心使用Runtime.exec()
 
我们知道Runtime.exec()使用来调用系统命令的，如果有恶意的用户调用了“rm -rf /”,一切的一切都完蛋了。
 
所以，我们在调用Runtime.exec()的时候，一定要小心注意检测用户的输入。
 
看下面的一个例子：
 
    public void wrongExec() throws IOException {
        String dir = System.getProperty("dir");
        Runtime rt = Runtime.getRuntime();
        Process proc = rt.exec(new String[] {"sh", "-c", "ls " + dir});
    }
 
上面的例子中，我们从系统属性中读取dir，然后执行了系统的ls命令来查看dir中的内容。
 
如果有恶意用户给dir赋值成：
 
/usr & rm -rf /
 
那么系统实际上执行的命令就是：
 
sh -c 'ls /usr & rm -rf /'
 
从而导致恶意的删除。
 
解决上面的问题也有几个方法，第一个方法就是对输入做个校验，比如我们只运行dir包含特定的字符：
 
    public void correctExec1() throws IOException {
        String dir = System.getProperty("dir");
        if (!Pattern.matches("[0-9A-Za-z@.]+", dir)) {
            // Handle error
        }
        Runtime rt = Runtime.getRuntime();
        Process proc = rt.exec(new String[] {"sh", "-c", "ls " + dir});
    }
 
第二种方法就是使用switch语句，限定特定的输入：
 
    public void correctExec2(){
        String dir = System.getProperty("dir");
        switch (dir){
            case "/usr":
                System.out.println("/usr");
                break;
            case "/local":
                System.out.println("/local");
                break;
            default:
                break;
        }
    }
 
还有一种就是不使用Runtime.exec()方法，而是使用java自带的方法。
 
正则表达式的匹配
 
在正则表达式的构建过程中，如果使用用户自定义输入，同样的也需要进行输入校验。
 
考虑下面的正则表达式：
 
(.*? +public\[\d+\] +.*<SEARCHTEXT>.*)
 
上面的表达式本意是想在public[1234]这样的日志信息中，搜索用户的输入。
 
但是用户实际上可以输入下面的信息：
 
.*)|(.*
 
最终导致正则表达式变成下面的样子：
 
(.*? +public\[\d+\] +.*.*)|(.*.*)
 
从而导致匹配所有的日志信息。
 
解决方法也有两个，一个是使用白名单，判断用户的输入。一个是使用Pattern.quote()来对恶意字符进行转义。
 
本文的代码：
 
learn-java-base-9-to-20/tree/master/security
 
 
 
本文已收录于 http://www.flydean.com/java-security-code-line-input/
 
 
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！
 
 
欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！
 

我们知道数据在传输过程中，可能会存在数据出错的情况。为了保证数据传输的正确性，因此会采取一些方法来判断数据是否正确，或者在数据出错的时候及时发现进行改正。常用的几种数据校验方式有奇偶校验、CRC校验、LRC校验、格雷码校验、和校验、异或校验等。
 
一、奇偶校验
 
1. 定义
 
根据被传输的一组二进制代码中“1”的个数是奇数或偶数来进行校验。
 
使用：通常专门设置一个奇偶校验位，存放代码中“1”的个数为奇数还是偶数。若用奇校验，则奇偶校验位为奇数，表示数据正确。若用偶校验，则奇偶校验位为偶数，表示数据正确。
 
 
2. 应用
 
eg.  数据位为 10001100 （1）  -> 最后一位为校验位
 
此时若约定好为奇校验，那么数据表示为正确的，若为偶校验，那么数据传输出错了。
 
二、CRC校验（循环冗余校验码）
 
1. 定义
 
CRC校验是数据通信领域中最常用的一种查错校验码，其特征是信息字段和校验字段的长度可以任意选定。循环冗余检查（CRC）是一种数据传输检错功能，对数据进行多项式计算，并将得到的结果附在帧的后面，接收设备也执行类似的算法，以保证数据传输的正确性和完整性。
 
 
2. 计算过程： 
 a> 设置CRC寄存器，并给其赋值FFFF(hex)。 
 b> 将数据的第一个8-bit字符与16位CRC寄存器的低8位进行异或，并把结果存入CRC寄存器。 
 c> CRC寄存器向右移一位，MSB补零，移出并检查LSB。 
 d> 如果LSB为0，重复第三步；若LSB为1，CRC寄存器与多项式码相异或。
 
e> 重复第3与第4步直到8次移位全部完成。此时一个8-bit数据处理完毕。
 
f> 重复第2至第5步直到所有数据全部处理完成。
 
g> 最终CRC寄存器的内容即为CRC值。
 
常用的CRC循环冗余校验标准多项式如下：   CRC(16位) = X16+X15+X2+1   CRC(CCITT) = X16+X12 +X5+1 
 CRC(32位) = X32+X26+X23+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1 
 以CRC(16位)多项式为例，其对应校验二进制位列为1 1000 0000 0000 0101。 
 
 
3. 应用：在发送端根据要传送的k位二进制码序列，以一定的规则产生一个校验用的r位监督码(CRC码)，附在原始信息后边，构成一个新的二进制码序列数共k+r位，然后发送出去。在接收端，根据信息码和CRC码之间所遵循的规则进行检验，以确定传送中是否出错。
 
 
三、LRC校验
 
1. 定义：LRC校验用于ModBus协定的ASCII模式，这各校验比较简单，通讯速率较慢，它在ASCII协议中使用，检测了消息域中除开始的冒号及结束的回车换行号外的内容。它仅仅是把每一个需要传输的数据字节迭加后取反加1即可。
 
2. 应用
 
eg. 5个字节：01H+03H+21H+02H+00H+02H = 29H，然后取2的补码=D7H。
 
 
四、格雷码校验
 
1. 定义
 
格雷码是一种无权码，也是一种循环码。是指任意两组相邻的代码之间只有一位不同，其余为都相同。
 
如：5的二进制为0101    6的二进制为0110
 
        5的格雷码为0111    6的二进制为0101
 
五、校验和
 
1. 定义
 
校验一组数据项的和是否正确。通常是以十六进制为数制表示的形式。如果校验和的数值超过十六进制的FF，也就是255。
 
 
2. 应用
 
eg. 数据01020304的校验和为a。
 
六、异或校验
 
1. 定义
 
BCC校验其实是奇偶校验的一种，但也是经常使用并且效率较高的一种。所谓BCC校验法，就是在发送前和发送后分别把BCC以前包括ETX字符的所有字符按位异或后，按要求变换(增加或去除一个固定的值)后所得到的字符进行比较。相等即认为通信无错误，不相等则认为通信出错。
 
七、MD5校验
 
1. 定义
 
MD5的实际应用是对一段Message(字节串)产生fingerprint(指纹)，可以防止被篡改。