Java判斷ip是否為IPV4或IPV6地址的多種方式
判斷字符串是否為IP地址通常都是基于正則表達式實現的,無論是引入外部的依賴包亦或是自己寫正則實現,基本都是基于正則表達式實現的判斷。然而比較例外的是,jdk自身提供了Inet4Address.getByName
方法也可以幫助我們實現ip地址的判斷。本文將詳細列舉常見的判斷字符串是否為IPV4,IPV6地址的方式,并分析其存在的局限性。
一、判斷是否為IPV4,IPV6地址的常見方式
1. 使用Apache Commons Validator做判斷
需要引入依賴包
<dependency> <groupId>commons-validator</groupId> <artifactId>commons-validator</artifactId> <version>1.6</version> </dependency>
有了依賴包,后續(xù)調用InetAddressValidator
的核心API就好了。
1.1判斷是否為IPV4地址
private static final InetAddressValidator VALIDATOR = InetAddressValidator.getInstance(); public static boolean isValidIPV4ByValidator(String inetAddress) { return VALIDATOR.isValidInet4Address(inetAddress); }
1.2判斷是否為IPV6地址
public static boolean isValidIPV6ByValidator(String inetAddress) { return VALIDATOR.isValidInet6Address(inetAddress); }
1.3判斷是否為IPV6或者IPV4地址
public static boolean isValidIPV6ByValidator(String inetAddress) { return VALIDATOR.isValid(inetAddress); }
2. 使用Guava做判斷
引入依賴包
<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>30.0-jre</version> </dependency>
調用InetAddresses.isInetAddress
即可實現快速的判斷,但這個方式能同時判斷字符串是否為IPV4或者IPV6地址,如果你只想判斷其中一種格式,那就不行了。
public static boolean isValidByGuava(String ip) { return InetAddresses.isInetAddress(ip); }
3. 使用OWASP正則表達式做判斷
OWASP提供了一系列用于校驗常見web應用名詞的正則表達式,通過OWASP_Validation_Regex_Repository你可以檢索到他們。這個判斷方式只能判斷是否為IPV4地址。
private static final String OWASP_IPV4_REGEX = "^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\." + "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\." + "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\." + "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$"; private static final Pattern OWASP_IPv4_PATTERN = Pattern.compile(OWASP_IPV4_REGEX); public static boolean isValidIPV4ByOWASP(String ip) { if (ip == null || ip.trim().isEmpty()) { return false; } return OWASP_IPv4_PATTERN.matcher(ip).matches(); }
4. 使用自定義正則表達式做判斷
如下通過自定義的正則表達式判斷字符串是否為IPV4地址,它的正則表達式以及實現細節(jié),其實和第一種方案中判斷IPV4是一致的,如果你只想判斷字符串是否為IPV4地址,又懶得引入外部包,那么3,4這兩種方式適合你。
private static final String IPV4_REGEX = "^(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})$"; private static final Pattern IPv4_PATTERN = Pattern.compile(IPV4_REGEX); public static boolean isValidIPV4ByCustomRegex(String ip) { if (ip == null || ip.trim().isEmpty()) { return false; } if (!IPv4_PATTERN.matcher(ip).matches()) { return false; } String[] parts = ip.split("\\."); try { for (String segment : parts) { if (Integer.parseInt(segment) > 255 || (segment.length() > 1 && segment.startsWith("0"))) { return false; } } } catch (NumberFormatException e) { return false; } return true; }
5. 使用JDK內置的Inet4Address做判斷
JDK從1.4版本開始就提供了Inet4Address
類實現對IP的各項校驗操作,結合該類的getByName
和getHostAddress
方法可實現IP地址判斷,但是頻繁的調用這兩個方法會產生一定的性能問題。以下是通過JDK判斷字符串是否為IPV4地址的方式:
public static boolean isValidIPV4ByJDK(String ip) { try { return Inet4Address.getByName(ip) .getHostAddress().equals(ip); } catch (UnknownHostException ex) { return false; } }
二、并不適合ping命令
1. IPV4的標準格式
本文列舉的幾種判斷方式都是針對標準的IP地址而言,標準指的是IP地址由4位通過逗號分割的8bit長度的數字字符串組成,由于每位數字只有8bit長度,所以每個數字的值應該在0~255范圍內。相關文檔可以參考RFC5321。
2. 有效性驗證
我們選舉幾組字符串,有缺少位數的,有數字以0開頭的,也有一組是符合標準格式的。然后通過之前列舉的方法判斷是否為有效的IP地址。
測試過程就不再贅述,直接將測試用例和測試結果匯總成如下的表格:
用例 | isValidIPV4ByValidator | isValidIPV6ByValidator | isValidByGuava | isValidIPV4ByOWASP | isValidIPV4ByCustomRegex | isValidIPV4ByJDK |
---|---|---|---|---|---|---|
172.8.9.28 | true | false | true | true | true | true |
192.168.0.072 | false | false | false | true | false | false |
172.08.9.28 | false | false | false | true | false | false |
172.9.28 | false | false | false | false | false | false |
192.168.072 | false | false | false | false | false | false |
192.168.1 | false | false | false | false | false | false |
2001:0db8:85a3:0000:0000:8a2e:0370:7334 | false | true | true | false | false | false |
通過這7個測試用例中,不難看出:
- 第1個IP剛好是4位,每位都在0~255之間,且沒有任何一位以0開頭。所有判斷IPV4的方法都返回了true,符合預期。
- 第2,3個IP也都是4位地址,但是某一位出現以0開始的數字,此時采用OWASP正則表達式的方式返回了true,其他方法都返回了false。
- 第4,5,6個IP都是3位地址,所有方法返回了false。
- 最后一個是合法的ipv6地址,我們通過Apache Commons Validator或者Guava包提供的判斷方法能夠正常返回true。
3. 性能對比
本文在列舉的第5個判斷方法時特意提到了性能問題,那么使用Inet4Address
判斷IP地址到底會導致多大的性能損耗呢?實驗證明,當判斷使用大規(guī)模非法IP地址做輸入,該方法的性能損耗將不敢想象!
下面將通過一項測試來驗證這個結論。
private static List<String> generateFakeIp(int capacity) { List<String> ipList = new ArrayList<String>(capacity); for (int i = 0; i < capacity; i++) { int parts = boundRandom(1, 3); if (chanceOf50()) { //each ip has 50% chance to be 4 parts parts = 4; } StringBuilder sbBuilder = new StringBuilder(); for (int j = 0; j < parts; j++) { if (sbBuilder.length() > 0) { sbBuilder.append("."); } StringBuilder stringBuilder = new StringBuilder(); if (chanceOf10()) { //each part has 10% chance to generate a fake number stringBuilder.append('a'); } else { //each part has 90% chance to generate the correct number stringBuilder.append(boundRandom(0, 255)); } sbBuilder.append(stringBuilder); } ipList.add(sbBuilder.toString()); } return ipList; } private static long correctCount(List<String> ipList) { return ipList.stream().filter(ip -> isValidIPV4ByCustomRegex(ip)).collect(Collectors.toList()).size(); } // 50% chance private static boolean chanceOf50() { return boundRandom(0, 9) < 5; } // 10% chance private static boolean chanceOf10() { return boundRandom(0, 9) < 1; } private static Random random = new Random(); // random int between [start, end], both start and end are included private static int boundRandom(int start, int end) { return start + random.nextInt(end); }
我們通過上面的generateFakeIp
方法來產生一批隨機的IP地址,這些IP中有正確格式的,也有非法格式的。
主體測試方法如下,該方法將比較isValidIPV4ByCustomRegex
和isValidIPV4ByJDK
這兩種判斷IP地址的總耗時,以分析性能問題。
public static void performanceTest() { List<String> ipList = generateFakeIp(100); double chance = correctCount(ipList); System.out.println("start testing, correct ip count is : " + chance); long t1 = System.currentTimeMillis(); ipList.stream().forEach( ip-> isValidIPV4ByCustomRegex(ip)); long t2 = System.currentTimeMillis(); ipList.stream().forEach( ip-> isValidIPV4ByJDK(ip)); long t3 = System.currentTimeMillis(); System.out.println("isValidIPV4ByCustomRegex cost time : " + (t2-t1)); System.out.println("isValidIPV4ByJDK cost time : " + (t3-t2)); }
直接運行后,打印以下結果。
start testing, correct ip count is : 37.0
isValidIPV4ByCustomRegex cost time : 2
isValidIPV4ByJDK cost time : 13745
可以看到,當100個IP中只有37個是合法IP時,基于正則表達式的判斷方法只用了2ms,而基于JDK內置的Inet4Address
實現的判斷方法卻用了13s,這已經不在在同一個數量級了。如果我們將測試基數再擴大,那更加不敢想象,所以實際工作中,千萬不要使用Inet4Address
來做IP合法性判斷。
4. 判斷IPV4的方法并不適合ping命令
對于標準IPV4格式的地址來說,以上判斷方式是沒問題的,但是部分非標準IPV4格式的地址,卻能夠被ping命令正常解析。
對于ping命令來說,我們這里列舉的第2~6個IP地址都是合法的,能夠被正常解析。
不妨驗證一下:
可以看出,當我們輸入的IP地址中,某一位數字位以0開頭,那么也能被正常解析,從圖片可以看出192.168.0.072
被解析成了192.168.0.58
,172.08.9.28
被解析成了172.08.9.28
。這是為什么呢?
當ping命令接收的IP地址中,出現以0開頭的數字位,那么ping命令將嘗試以八進制解析該位,八進制的072,即對應十進制的58,所以192.168.0.072
就被解析成了192.168.0.58
。
如果以0開頭的數字位,不符合八進制的格式,則依然以十進制對待該數字位,并忽略最高位的0,由于172.08.9.28
中08
并不是一個合法的八進制數,所以依然按十進制對待并忽略最高位的0,即實際解析成172.8.9.28
此外,當輸入的IP地址并不是以逗號分割的四位,ping命令依然能夠正常解析。分別ping 196.168.072
,192.168
,196
時,實際被解析成了 196.168.0.072
,196.0.0.168
,0.0.0.192
可以看出,當IP不足四位時,ping命令會在合適的位置補0,其規(guī)律如下所示:
1 part (ping A) : 0.0.0.A
2 parts (ping A.B) : A.0.0.B
3 parts (ping A.B.C) : A.B.0.C
4 parts (ping A.B.C.D) : A.B.C.D
三、小結
這幾種判斷字符串是否為IPV4或者IPV6地址的方式,其內在實現原理都大同小異,除了最后一個方案外都是用正則表達式來實現的。
但是基于正則表達式實現的方法并不能很友好地處理非十進制數字位的情況,而ping命令能夠接收的字符串遠比這個復雜的多,如果你想通過Java來實現判斷ping命令后面的地址是否是合法的IP,那應該是難于上青天,除非你去弄懂ping命令的底層源碼。
當然在現實業(yè)務場景中,我們判斷字符串是否為合法IP地址一般都是基于其標準格式來操作的,也不用擔心文中的方法不靠譜,除了第3和最后一個方案外,大膽用吧!
到此這篇關于Java判斷ip是否為IPV4或IPV6地址的多種方式的文章就介紹到這了,更多相關Java判斷ip是否為IPV4或IPV6內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
SpringBoot+Vue靜態(tài)資源刷新后無法訪問的問題解決方案
這篇文章主要介紹了SpringBoot+Vue靜態(tài)資源刷新后無法訪問的問題解決方案,文中通過代碼示例和圖文講解的非常詳細,對大家解決問題有一定的幫助,需要的朋友可以參考下2024-05-05Springboot通過ObjectMapper配置json序列化詳解
SpringBoot默認集成Jackson庫,其中ObjectMapper類是核心,用于Java對象與JSON字符串的互轉,提供配置序列化特性、注冊模塊等方法,在SpringBoot中可以全局配置JSON格式,如日期格式化、將Long轉為字符串,還可以配置序列化時的各種規(guī)則,感興趣的可以了解一下2024-10-10Spring?boot事務無效報錯:Transaction?not?enabled問題排查解決
在業(yè)務代碼中經常需要保證事務的原子性,但是有的時候確實是出現事務沒有生效,這篇文章主要給大家介紹了關于Spring?boot事務無效報錯:Transaction?not?enabled問題排查的相關資料,需要的朋友可以參考下2023-11-11解決Springboot項目中很多頁面出現Whitelabel Error Page(404)的問題
最近在接手的前后端項目中發(fā)現其默認路徑不是主機+端口(如:http://localhost:3453/)的形式,很多頁面的訪問是加了一個層級,只要訪問頁面就會出現Whitelabel Error Page(404),所以本文給大家提供了解決方案,需要的朋友可以參考下2024-02-02