解析xml时如何防范dtd xsd访问外网

做Java的同窗估量都碰过相似的缺点，就是突然有一天启动运用的时分通知你由于没获取到dtd或xsd文件运用启动失败，而通常这个时分你才会发现原来自己运用的启动居然还依赖了外网的某个url，我记妥当年ibatis切域名的那一次，就是突然一批机器启动失败，差点形成大缺点，还有一次印象深入的海底光缆断掉的那一次，也是差点引发大缺点。

关于下面这样的现象，最好的方法自然是确保本地有相应的dtd/xsd文件，从而防止去外网加载，但为什么要做到这点这么费事呢，缘由在于dtd/xsd文件究竟从哪加载是完全可以由解析XML的顺序自行来决议的，于是就悲催了。

在解析XML时可自行完成EntityResolver接口，例如Spring的BeansDtdResolver，在这个类中，Spring会首先从以后类的classloader中来获取相应途径的dtd文件，如找不到则从指定的classloader中获取，依然找不到的话就前往null，以后往null后，外层的ResourceEntityResolver则会访问相应的url去获取dtd，关于xsd文件的处置也基本相似。

独一还好的就是基本一切解析xml的顺序在对dtd/xsd的处置上，都遵照了先尝试从本地装载，之后再从url装载的先后顺序。

关于这个头疼的效果，我之前见过的处置方法有：
1.将一切的dtd/xsd触及的域名都解析到本地的一台机器，以防止访问外网的现象出现，这个的效果在于无法做到穷举，由于能够不是你的顺序需求解析XML，而是你援用的其他jar中有；
2.制止效劳器访问外网，这样的益处就是效果暴露的比拟直接，但能够有些运用确实会有需求访问外网的需求；
3.将xml文件中的dtd/xsd改为本地相对途径，这种一个效果是下面的穷举效果，另一个效果是相对途径究竟如何访问其实异样取决于自定义完成的xml解析顺序；
4.在解析xml时绕过dtd的验证，假设能保证xml文件格式没效果的话，可以绕掉dtd的验证，但xsd就不行了，xsd文件是必需获取到的，否则xml文件压根就没法解析。

目前我们没采用以上4个方法，在前年的时分由于延续出了好几次dtd/xsd访问不了招致各种运用启动不了的现象，我就花了点时间想方法去处置掉这个效果，事先我的处置思绪是下面的4个方法在我们的场景中都不能处置，看起来一个折中的方法就是在测试阶段就发现这个效果，然后强迫运用途理掉，这样就可以确保部署到线上的时分访问的一定是本地。

要在测试阶段发现这个效果怎样做呢，想到的方法是用btrace来跟踪URL.openConnection的调用，如URL的开头是.dtd或.xsd，那么就在日志中输入错误信息和堆栈信息，启动脚本在反省到错误信息后就让进程参与，这样可以确保运用方必需处置掉这个效果。