FAQ and solutions for Java create URLs _java

URLs are ubiquitous, but it seems that developers don't really understand them, because I often see someone asking how to create a URL correctly on stack overflow. Want to know how the URL syntax works, you can see the Lunatech this article, very good.

This article does not delve into the full syntax of the URL (if you want to fully understand the URL, you can read the RFC 3986, RFC 1738, and the article mentioned above, as well as the W3 above, and here I want to talk about some common library errors in manipulating URLs, and how to pass the URL -builder to use it correctly, this is a Java library that we publish to properly create URLs.

The urlencoder of the problem 1:java

Not only does this class have a bad name, but the first sentence on its document is not very good.

Utility class for HTML form encoding.

You may be wondering why it's called Urlencoder, and it's completely silent to see this line.

If you've read Lunatech's blog post, now you should understand that you can't magically convert a URL string into a secure, properly coded URL object, of course, if you haven't done your homework, here's a small example to help you understand.

Suppose you have an HTTP service endpoint Http://foo.com/search that accepts a query parameter P,p value is the string to look for. If you search the "You & I" string, the URL of the search you created for the first time might be this: Http://foo.com/search?q=You & I. This certainly won't work, because & is the separator that separates query parameter Name/value pairs. If you get this deranged URL string, you have nothing to do with it, because first you can't parse it correctly.

Well, let's use the next urlencoder. Urlencoder.encode ("You & I", "Utf-8″") is the result of you+%26+i. After this%26 decoding is, and the + number in the query string represents the space, so this URL is able to work properly.

Now suppose you want to use your query string to splice the URL path instead of the URL parameter. Obviously, Http://foo.com/search/You & I are wrong. Unfortunately, the results of Urlencoder.encode () are also wrong. Http://foo.com/search/You+%26+I decoding will get/search/you+&+i, because the + number in the URL path is not resolved into spaces.

Urlencoder may be able to satisfy some of your scenes. Unfortunately, it is an overly generic name that makes it easy for developers to misuse it. So the best way to do this is not to use it, so that other developers on your basis are making mistakes (unless, you're actually doing HTML form coding).

Problem 2:groovy Httpbuilder and Java URI

HTTP Builder is an HTTP client library of groovy.

Creating a normal GET request is 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 before performing this code validation).

Let's try a URL that contains spaces.

New Httpbuilder ("http://localhost:18080"). Request (Method.get) { 
Uri.path = "/foo Bar" 
}

This was sent by Get/foo%20bar http/1.1, and it looked good.

Now suppose that one of our paths is called Foo/bar. This is not a simple way to send a foo/bar, as this would be thought to include two paragraphs in the path, Foo and bar, so let's try the Foo%2fbar bar (put/replace the corresponding encoding).

New Httpbuilder (' http://localhost:18080 '). Request (Method.get) { 
Uri.path = '/foo%2fbar ' 
}

This is sent by Get/foo%252fbar http/1.1. That's not good. The% in the%2f is duplicated, so the path to the decoding is Foo%2fbar rather than foo/bar. The real blame here is Java.net.URI, because the UriBuilder class used in this httpbuilder is it.

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 attribute of the URI, it will eventually call a constructor of the URI, which is described in the Path property passed in:

If the path parameter is provided, it is appended to the URL. The characters in the path, as long as they are not unreserved, punctuation, escape, and other categories (which are described in detail in RFC 2396), and are not/or @, are encoded.

This does not make sense because if the text before it contains special characters, it cannot generate a properly encoded path fragment. In other words, "I'm going to encode this string and it's right after coding," which is certainly a fallacy, and the URI is the victim of this fallacy. If the string is encoded correctly, that's fine, and if it's not, it's over, because this string can't be parsed. In fact, the document does not escape the word/number meaning that it assumes that the path string is correctly encoded (that is, the correct use/to separate the path) and that it is not properly coded (other parts except/are still required to encode).

It would be nice if Httpbuilder did not use this defective feature of the URI class, and, of course, it would be better if the URI itself had no problem.

The right approach

We wrote this url-builder, which helps developers to easily splice various types of URLs. It follows the coding specifications in the first few references, and it also provides a streaming API. The following examples of usage can cover almost all of the usage scenarios:

Urlbuilder.forhost ("http", "foo.com") 
. PathSegment ("with Spaces") 
. Pathsegments ("path", "with", "VarArgs") 
. PathSegment ("&=?/") 
. Queryparam ("Fancy + Name", "Fancy?=value"). 
Matrixparam ("Matrix", "param?") 
. Fragment ("#?=") 
. Tourlstring ()

The result: http://foo.com/with%20spaces/path/with/varArgs/&=%3F%2F;matrix=param%3F?fancy%20%2B%20name=fancy?% 3dvalue#%23?=

This example illustrates the different coding rules for each part of the URL, such as &= that are not encoded in the path and are allowed./is required to encode, but in the query parameters = is required to encode, but? The number is not required, because this is already part of the query string (s): The query string is from one? Number began, So the following can contain a number.

Thank you for reading, I hope to help you, thank you for your support for this site!