1. Get is used to obtain data from the server, while Post is used to pass data to the server.
2. Get adds the data in the form to the URL pointed to by the action in the form of variable=value, and uses a ? connection between the two, while the & connection between each variable; Post is to place the data in the form in the data body, and pass it to the URL pointed to by the action in the way the variable and value corresponds to the value.
3. Get is not safe because during the transmission process, data is placed in the requested URL. Nowadays, many existing servers, proxy servers or user agents will record the requested URL into the log file and then place it somewhere, so that some privacy information may be seen by third parties. In addition, users can also directly see the submitted data on the browser, and some internal system messages will be displayed in front of the user. All operations of Post are invisible to the user.
4. The amount of data transmitted by Get is small, which is mainly due to the limitation of URL length; and Post can transfer a large amount of data, so you can only use Post when uploading files (of course there is another reason, which will be mentioned later).
5. Get restricts the value of the data set of Form forms to be ASCII characters; while Post supports the entire ISO10646 character set. By default, ISO-8859-1 encoding
6. Get is the default method of Form.
The following comparison is very, very useful:
I have been working on Java web development for a while, and there is a problem that always bothers me, which is the problem of garbled. Basically, I search for solutions online (there are really a lot of online information), and they all introduce how to solve such garbled problems, but few of them explain the whole story of the problem clearly. Sometimes after reading some articles, I think I understand it, but in development, the garbled problem comes out like a ghost and is really a big deal! This article is a accumulation of some understanding of my long-term struggle with garbled codes, and I hope more friends will give me some advice and supplements.
There are 2 methods for form to submit data to the server, let’s talk about get and post respectively.
(I) get submission
1. First, let’s talk about how to encode the data and submit it to the server using the get method.
For the get method, data is concatenated after the requested url as parameters, such as: http://localhost:8080/servlet?msg=abc
(A very common problem of garbled code will appear. If Chinese or other special characters appear in the url, such as: http://localhost:8080 /servlet?msg=Hangzhou, garbled code is easy to get garbled code on the server), after the url splicing is completed, the browser will URL encode the url and then send it to the server. The process of URL encode is to encode part of the url as characters and encode it into binary byte code according to a certain encoding method (such as: utf-8, gbk, etc.), and then each byte is represented by a string %xy containing 3 characters, where xy is the two-bit hexadecimal representation of the byte. What I said here may not be clear. For details, please see the introduction of the java.net.URLEncoder class here. After understanding the process of URL encode, we can see two very important questions. First: the characters that require URL encode are generally non-ASCII characters (generally speaking). In simple terms, except for English letters (such as Chinese, Japanese, etc.) all have to perform URL encode. Therefore, for us, the URL encode will not be garbled when the server gets garbled code. The garbled code is caused by the url containing Chinese or special characters in the url; Second: In which encoding method does URL encode characters? This is the browser's business, and different browsers have different practices. Chinese versions of browsers generally use GBK by default. UTF-8 can also be used by setting the browser. Different users may have different browser settings, which leads to different encoding methods. Therefore, many websites do the URL encode first by using JavaScript for the Chinese or special characters in the URL, and then splicing the URL to submit data, that is, making URL encode for the browser. The advantage is that the website can unify the encoding method of submitting data. After completing the URL encode, the current URL becomes a character within the ASCII range, and then converts it into binary in the encoding method of iso-8859-1 and is sent out together with the request header. I would like to say a little more here that for the get method, there is no request entity, and the URL containing data is all in the request header. The reason why I use URL encode is: for the request header, the pure data of the request header must be encoded into binary 101010... in the end, pure data of the request header must be transmitted on the Internet. If you directly encode special characters such as Chinese and other characters iso-8859-1, the information will be lost, so it is necessary to do URL encode first.
2. How does the server side (tomcat) get the data for decoding.
The first step is to decode the data with iso-8859-1. For the get method, tomcat obtains the data header characters in the ASCII range, and the request url contains parameter data. If there are special characters such as Chinese in the parameter, then it is still the %XY state after the URL encode. Stop first, let's talk about the general process of obtaining data by developers. Usually everyone gets parameter data. The request object or data we get is decoded, but the program cannot specify it during the decoding process. Here we have to say that many newbies say that using request.setCharacterEncoding (character set) can specify the decoding method, but it is actually not possible . Looking at the official API of the servlet, there is an explanation for this method: Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader(). It can be seen that he is powerless to do anything about the get method. So what encoding method is used to decode data? This is tomcat's business. The default default is iso-8859-1, so we can find why the get request has Chinese parameters and why the garbled code is obtained on the server side. The reason is that UTF-8 or GBK is usually used to encode the data URL encode. Here, the URL decoder is obviously not possible. In the program, we can directly
Java code
1. new String(request.getParameter(name).getBytes(iso-8859-1), the URL encode encoding method specified by the client)
Restore back to the bytecode and decode the data in the correct way. Online articles usually make a configuration in tomcat
Xml code
1. <Connector port=8080 protocol=HTTP/1.1 maxThreads=150 connectionTimeout=20000 redirectPort=8443 URIEncoding=GBK/>
This allows tomcat to use the specified method to retrieve the data. The introduction of URL decoder is here
(I) Post Submission
1. How to encode the data and submit it to the server using the post method of the client (browser).
The data to be transmitted in the post method also needs to be URL encode, so what encoding method does it use?
If there is a segment <meta http-equiv=Content-Type content=text/html; charset=character set (GBK, utf-8, etc.) in the html file where the form is located, then the post will be encoded in the encoding method specified here. Generally, everyone thinks that this code is to let the browser know what character set to interpret the web page, so the website will place it at the front end of the html code and try not to appear garbled code. In fact, it also has another function to specify the URL encode encoding method of the form form's post method to submit data . From here we can see that for the get method to count, the browser's URL encode encoding method is determined by the browser settings (can be specified in js for unified specification), and the post method can be specified by the developer.
2. How does the server side (tomcat) get the data for decoding.
If you use tomcat default settings and no encoding settings such as filters are made, then it is also decoded with iso-8859-1, but request.setCharacterEncoding (character set) can come in handy.
I found that the premise of what tomcat does above is that there is no encoding method specified in the request header. If the encoding method specified in the request header, it will be encoded in this way.There are 2 articles recommended, and the addresses are
In-depth and easy-to-understand URL encoding: http://www.cnblogs.com/yencain/articles/1321386.html;
Garbage code problem when submitting data using post method: http://wanghuan8086.javaeye.com/blog/173869
It is important to use post. If there is a segment in the html file where the form is located. <meta http-equiv=Content-Type content=text/html; charset=character set (GBK, utf-8, etc.)/>
Highly recommended to submit post