Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to solve the common problems of creating URL in Java". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

URLEncoder of the question 1:Java

Not only is this class poorly named, but its documentation is not quite correct in terms of sentences.

Utility class for HTML form encoding.

You may be wondering why it is called URLEncoder. When you see this line, you are completely speechless.

If you've read Lunatech's blog post, you should understand by now that you can't miraculously transform a URL string into a secure, correctly encoded URL object through this class, but of course, if you haven't done your homework, here's a little example to help you understand.

Suppose you have a HTTP service endpoint http://foo.com/search that accepts the value of the query parameter pforce p as the string to look for. If you search for the string "You & I", the URL of the search you created * might look like this: http://foo.com/search?q=You & I. This certainly doesn't work because & is the delimiter that separates the query parameter name/value pairs. If you get this crazy URL string, there's nothing you can do about it, because you can't parse it correctly in the first place.

All right, let's use URLEncoder. URLEncoder.encode ("You & I", "UTF-8") is the result You+%26+I. This% 26 is decoded as &, and the + sign represents a space in the query string, so the URL works properly.

Now suppose you want to use your query string to concatenate the URL path instead of putting it in the URL parameter. Obviously, http://foo.com/search/You & I is wrong. Unfortunately, the result of URLEncoder.encode () is also wrong. Http://foo.com/search/You+%26+I will get / search/You+&+I after decoding, because the + sign does not resolve to spaces in the URL path.

URLEncoder may be able to satisfy some of your scenarios. Unfortunately, its overly generic name makes it easy for developers to misuse it. So the way to * is not to use it, lest other developers make mistakes when using other features on top of you (unless you are really "HTML form coding").

Question 2:Groovy HttpBuilder and URI of Java

HTTP Builder is a HTTP client library of Groovy.

Creating a normal GET request is very simple:

New HTTPBuilder ("http://localhost:18080").request(Method.GET) {

Uri.path = "/ foo"

}

This code will send GET / foo HTTP/1.1 to the server (you can run nc-l-p 18080 and then execute this code to verify).

Let's try URL with spaces.

New HTTPBuilder ("http://localhost:18080").request(Method.GET) {

Uri.path = "/ foo bar"

}

This one sends GET / foo%20bar HTTP/1.1, which looks good.

Now suppose there is a section in our path called foo/bar. This cannot simply be done by sending foo/bar, because it will be thought of as having two segments in the path, foo and bar, so let's try foo%2Fbar (replace / replace with the corresponding code).

New HTTPBuilder ('http://localhost:18080').request(Method.GET) {

Uri.path ='/ foo%2Fbar'

}

This one sends GET / foo%252Fbar HTTP/1.1. This is not good. % of% 2F is repeatedly encoded so that the decoded path is foo%2Fbar instead of foo/bar. What's really to blame here is java.net.URI, because that's what the URIBuilder class in this HTTPBuilder uses.

The type of uri attribute exposed in the configuration closure in the above code is URIBuilder. If you pass uri.path =... To update the path property of uri, it will eventually call a constructor of URI, which describes the incoming path property as follows:

If the path parameter is provided, append it to the URL. Characters in path are encoded as long as they are not non-reserved, punctuation, escape and other categories, and are not / or @ characters.

This doesn't make much sense, because if the unencoded text contains special characters, it cannot generate a correctly encoded path segment. In other words, "I will encode this string, and after encoding it will be correct," which is, of course, a fallacy, and URI happens to be the victim of this fallacy. If the string is encoded correctly, there is no problem, and if not, it is over, because the string cannot be parsed. In fact, what the document says about not escaping the / sign means that it assumes that the path string has been correctly encoded (that is, using / to separate the path correctly) and that it has not been correctly encoded (parts other than / still need to be encoded).

It would be nice if HTTPBuilder didn't use the flawed functionality of the URI class, and of course, if URI itself was fine.

The right thing to do

UrlBuilder.forHost ("http", "foo.com")

.pathSegment ("with spaces")

.pathSegments ("path", "with", "varArgs")

.pathSegment ("& =? /")

.queryParam ("fancy + name", "fancy?=value")

.matrixParam ("matrix", "param?")

.fragment ("#? =")

This is the end of .toUrlString () "how to solve common problems in creating URL in Java". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.