incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@apache.org
Subject svn commit: r1550337 - /sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
Date Thu, 12 Dec 2013 03:17:07 GMT
Author: cziegeler
Date: Thu Dec 12 03:17:06 2013
New Revision: 1550337

URL: http://svn.apache.org/r1550337
Log:
CMS commit to sling by cziegeler

Modified:
    sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext

Modified: sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext?rev=1550337&r1=1550336&r2=1550337&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext (original)
+++ sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext Thu
Dec 12 03:17:06 2013
@@ -47,15 +47,15 @@ Be warned: Only rely on request paramete
 
 Traditionally, the encoding of parameters, especially in text area input forms, has been
a big issue. To solve this issue Sling introduces the following convention:
 
-   * All forms should contain a hidden field of the name <code>_charset_</code>
containing the actual encoding used to send the form from the server to the client
+   * All forms should contain a hidden field of the name `_charset_` containing the actual
encoding used to send the form from the server to the client
    * All forms should be sent with *UTF-8* character encoding
 
 The first rule is essential as it helps decoding the form input correctly. The second rule
is not actually a very hard requirement but to enable support for all (or most) character
sets used, using *UTF-8* is one of the best choices anyway.
 
-When Sling is now receiving a request and is asked for the parameters, the parameters are
parsed in two phases: The first phase just parses the raw input data using an identity transformation
of bytes to characters. This identity transformation happens to generate strings as the original
data was generated with `ISO-8859-1` encoding. The second phase locates the <code>_charset_</code>
parameter and fixes the character encodings of the parameters as follows:
+When Sling is now receiving a request and is asked for the parameters, the parameters are
parsed in two phases: The first phase just parses the raw input data using an identity transformation
of bytes to characters. This identity transformation happens to generate strings as the original
data was generated with `ISO-8859-1` encoding. The second phase locates the `_charset_` parameter
and fixes the character encodings of the parameters as follows:
 
    * All names of the parameters are re-encoded
-   * The parameter values are re-encoded, unless the parameter value is an uploaded file.
Actually the parameter (not the files of course) are internally as `byte[]({{ refs..path }})`
where the conversion to a string is done on the fly (and yes, the conversion using the <code>_charset_</code>
character encoding is of course cached for performance reasons)
+   * The parameter values are re-encoded, unless the parameter value is an uploaded file.
Actually the parameter (not the files of course) are internally as `byte[]({{ refs..path }})`
where the conversion to a string is done on the fly (and yes, the conversion using the `_charset_`
character encoding is of course cached for performance reasons)
    * If the parameter is an uploaded file, the file name is re-encoded on the fly when accessed
 
 <div class="info">



Mime
View raw message