1. Get is used to obtain data from the server, while Post is used to transfer 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 the two are connected using "?", and each variable is connected using "&"; Post is to The data in the form is placed in the data body of the form and passed to the URL pointed to by the action according to the corresponding variables and values.
3. Get is unsafe because during the transmission process, the data is placed in the requested URL, and many existing servers, proxy servers or user agents will record the requested URL in log files and then put Somewhere, there may be some private information that can be seen by a third party. In addition, users can also see the submitted data directly on the browser, and some internal system messages will be displayed in front of the user. All Post operations are invisible to users.
4. The amount of data transferred by Get is small, mainly because it is limited by the URL length; while 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 limits the value of the data set in the Form form to ASCII characters; while Post supports the entire ISO10646 character set. The default is to use ISO-8859-1 encoding
6. Get is the default method of Form.
The following comparison is very useful:
I have been doing Java web development for a while, and there is a problem that always bothers me, which is the garbled code problem. Basically I was looking for solutions online (there are really a lot of information online), and there were a lot of introductions on how to solve this kind of garbled code problem, but few of them explained the ins and outs of the problem clearly. Sometimes after reading some articles, I thought I I understand, but during development the garbled code problem appears like a ghost and scares people. It’s really a big headache! This article is the accumulation of some understanding of my long-term struggle with garbled characters. I also hope that more friends can give pointers and supplements.
The form has two methods to submit data to the server, get and post. Let’s talk about them respectively.
(1) Get submission
1. First, let’s talk about how the client (browser) form uses the get method to encode the data and submit it to the server.
For the get method, the data is concatenated behind the requested url as a parameter, such as: http://localhost:8080/servlet?msg=abc
(a very common garbled problem It is about to appear. If Chinese or other special characters appear in the URL, such as: http://localhost:8080 /servlet?msg=Hangzhou, the server side is easy to get garbled characters). After the URL splicing is completed, the browser will process the URL. URL encode, and then sent to the server. The process of URL encode is to use part of the URL as characters, encode it into binary bytecode according to a certain encoding method (such as utf-8, gbk, etc.), and then use a Represented by the 3-character string "%xy", where xy is the two-digit hexadecimal representation of the byte. What I’m talking about here may not be clear. For a detailed introduction, you can read the introduction of the java.net.URLEncoder class here. After understanding the process of URL encoding, we can see two very important issues. First: the characters that require URL encoding are generally non-ASCII characters (generally speaking), and more generally speaking, they are text other than English letters ( Such as: Chinese, Japanese, etc.) must be URL encoded, so for us, URLs with English letters will not cause the server to get garbled characters. Garbled characters are caused by Chinese or special characters in the URL; second :Which encoding method does URL encode use to encode characters? This is a matter of browsers, and different browsers have different approaches. The Chinese version of the browser generally uses GBK by default. You can also use UTF-8 by setting the browser. Different users may have different browsing preferences. The browser settings result in different encoding methods, so many websites use JavaScript to URL encode the Chinese or special characters in the URL first, and then splice the URL to submit the data, that is, URL encode is done for the browser. The advantage is that the website can unify the encoding method of data submitted by the get method. After URL encoding is completed, the URL now becomes a character in the ASCII range, and is then converted into binary using iso-8859-1 encoding and sent out along with the request header. What I want to say a few more words here is that for the get method, there is no request entity, and the URL containing the data is in the request header. The reason why URL encode is used I personally think is: for the request header In the end, the pure data of 101010... will be encoded into binary using the iso-8859-1 encoding method and transmitted over the Internet. If the special characters containing Chinese and other characters are directly encoded in iso-8859-1, the information will be lost, so It is necessary to do URL encode first.
2. How does the server side (tomcat) obtain the data and decode it.
The first step is to decode the data using iso-8859-1. For the get method, tomcat obtains the data with request header characters in the ASCII range. The request url contains parameter data. If there is Chinese in the parameter Wait for special characters, then it is still in the %XY state after URL encoding. Let’s stop for now. Let’s first talk about the process of developers generally obtaining data. Usually, everyone uses request.getParameter("name") to obtain parameter data. The data we get in the request object has been decoded, and it cannot be specified in the program during the decoding process. Let me talk about it here. Many novices say You can use request.setCharacterEncoding("Character Set") to specify the decoding method. In fact, it is not possible . See the official API description of servlet for an explanation of 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 with the get method. So what encoding method is used to decode the data? This is a matter of tomcat. The default is iso-8859-1, so we can find out why the get request with Chinese parameters is garbled on the server side. On the client side, UTF-8 or GBK is generally used to encode the data URL. It is obviously not possible to use the iso-8859-1 URL decoder here. In the program, we can directly
Java code
1. new String( request.getParameter("name").getBytes("iso-8859-1"),"URL encode encoding method specified by the client")
Restore back to bytecode, and then decode the data in the correct way, online The article is usually configured in tomcat
Xml code
1.
This allows tomcat to use the specified URL decoder after obtaining the data. The introduction of the URL decoder is here
(1) post submission
1. Client (browser) How the form uses the post method to encode the data and submit it to the server.
The data to be transmitted in the post method also requires URL encoding, so what encoding method does it use?
If there is a segment in the html file where the form is located, Generally everyone thinks that this code is to let the browser know what character set to use to interpret the web page, so the website will put it at the front end of the html code to try to avoid garbled characters. In fact, it also has another function: Specify the URL encode encoding method for data submitted by the post method of the form . It can be seen from here that for the get method, the encoding method of the URL encode of the data by the browser is determined by the browser settings (it can be specified uniformly with js), and for the post method, the developer can specify it.
2. How does the server side (tomcat) obtain the data and decode it.
If you use the default settings of tomcat and do not make any encoding settings such as filters, then it will also be decoded using iso-8859-1, but request.setCharacterEncoding("Character Set") can come in handy.
I found that the premise of what tomcat mentioned above is that the encoding method is not specified in the request header. If the encoding method is specified in the request header, it will be in this way. coding.
There are 2 articles recommended, the addresses are
Explain URL encoding in simple terms: http://www.cnblogs.com/yencain/ articles/1321386.html;
Garbled characters problem when the form submits data using the post method: http://wanghuan8086.javaeye.com/blog/173869
It is very important to use post. If there is a section in the html file where the form is located,
It is strongly recommended to use post submission