JavaScript-%0a (line break) execution parsing process

test.phpThe code for the file is as follows:

Scenario 1:
The value of variable A is controllable, as determined by the parameter input,
So, when accessing from the browser: http://127.0.0.1/test.php?input=start_%0a_end
The time
To view the Web page source code, the results are as follows:

//省略……
  
   
  
   //省略……

We can see that in case 1, there is a newline, and condition 2 remains the same.
Why does this happen?

Who can help explain the principles in detail ?

Here's my opinion on this issue:
When the client accesses the URL (http://127.0.0.1/test.php?input=start_%0a_end), because it is a PHP file, so the server will be a Apache servers to parse the execution, and return the results to the service side, The server then returns the result through the HTTP response to the client (browser), and the browser renders the page and renders it to the user.
User---> Browser---> Server--->apache
So
Line breaks are:
1. At the stage of Apache's parsing execution
2. The browser will present the final results to the user at this stage
If it appears in Apache's parsing execution phase, then there should be a newline, but there is no
And if the line break is out of the present: the browser's render phase, then

There should be a line break, but there's actually no

Reply content:

test.phpThe code for the file is as follows:

Scenario 1:
The value of variable A is controllable, as determined by the parameter input,
So, when accessing from the browser: http://127.0.0.1/test.php?input=start_%0a_end
The time
To view the Web page source code, the results are as follows:

//省略……
  
   
  
   //省略……

We can see that in case 1, there is a newline, and condition 2 remains the same.
Why does this happen?

Who can help explain the principles in detail ?

Here's my opinion on this issue:
When the client accesses the URL (http://127.0.0.1/test.php?input=start_%0a_end), because it is a PHP file, so the server will be a Apache servers to parse the execution, and return the results to the service side, The server then returns the result through the HTTP response to the client (browser), and the browser renders the page and renders it to the user.
User---> Browser---> Server--->apache
So
Line breaks are:
1. At the stage of Apache's parsing execution
2. The browser will present the final results to the user at this stage
If it appears in Apache's parsing execution phase, then there should be a newline, but there is no
And if the line break is out of the present: the browser's render phase, then

There should be a line break, but there's actually no

@安坚实answer, due to the query string address bar display, logging, or escaping the need for all aspects, you must translate some of the characters (such as unable to display characters, special meaning of the control characters, etc.)

So when you search for a symbol in Baidu, & access to the link is actuallyhttp://www.baidu.com/s?wd=%26
Because this character conflicts with the query string 参数连接符 , it needs to be escaped.

This process is a coding process, the most common encoding algorithm URLEncode andBase64Encode
What is used here is URLEncode that this is defined in RFC 3986

When the server receives this request, it is recorded in the log as-is, and then the parameter becomes the string in the application to be processed by the Web application.
A decoding process is required at this time, otherwise the resulting data is inconsistent with the expected

Next to the example above, I want to search for strings & instead of strings %26 , so I need to decode and change back&

Again to explain the LZ example, when accessed in the browser http://127.0.0.1/test.php?input=start_%0a_end ,
In fact, the actual value of the input parameter is not start_%0a_end the string, just because the address bar can not display line breaks, the newline character is escaped, his actual value is start_[换行]_end , the page output, he reverted to a[换行]

If you want to specify an actual value for the input parameter start_%0a_end , you need to % escape it once, and change to%25

Try to access a bithttp://127.0.0.1/test.php?input=start_%250a_end

The parsing process is actually like this:
User--browser--server--Apache---PHP interpreter

First, start_%0a_end when passed to the PHP interpreter,%0a is not converted to newline.

var_dump($_SERVER['QUERY_STRING']);   # string(19) "input=start_%0a_end"

However, when it is written to the $_get global array, it becomes a newline.

var_dump($_GET['input']); #string(11) "start_#_end"

Therefore, it should be that the PHP interpreter has done some processing when it writes the value of query string to $_get.
As to why this is handled, and how to solve ... This is beyond my scope of knowledge ...

In fact, there is only one point of knowledge, Uriencode,
The characters inside the URI are escaped when they are transmitted, and are reversed when the handler receives the data;
%0aThe escape process is roughly as follows (js,php's process @ Ann Solid has explained the section):

// encodeencodeURIComponent('\n') // %0AencodeURIComponent('\n').toLowerCase() === '%0a' // true// decodedecodeURIComponent('%0a').charCodeAt(0)  // 10'\n'.charCodeAt(0) // 10

About JS URI encoding section is visible:
Http://www.ruanyifeng.com/blog/2010/02/url_encoding.html

