My site's encoding is UTF-8. Is there any invalid character for text fields?
All characters are acceptable?
Ex. emoji or ¥n
I tried to send as an event: an emoji and the two special characters you wrote.
This is the result in Google Analytics:
Google Analytics allows those characters.
Related
My server logs show a many attempts to access non existing sides. These are the "usual" bots scanning for known vulnerabilities. Many of the URLs contain =3D, e.g.
/?q=3Duser%2Fpassword&name%5B%23p=
/user/register/?element_parents=3Daccou=
/wp-admin/admin-post.php?swp_debug=3Dlo=
%3D is the url encoded value of = so I would expect to find %3D within the URL but not =3D. However, =3D can be found all over the logs. What is the meaning of this?
=3D is an example of a Quoted-Printable encoding for ASCII 0x3D, or the equals sign character (=).
You don't usually see this in URLs. It's not the normal encoding to use. It's a standard MIME type, an alternative to using base64. It looks like the request is expecting the app to decode the query string using Quoted-Printable, and then use the resulting path in some further redirect.
I'm creating HMAC-SHA256 Authorization header for my rest request.
My hunch is that internally Paw is using UTF-8 (or some other non-Unicode) encoding to calculate the checksum. My server side API uses Unicode to calculate the same thing for comparison but with the same inputs I receive different outputs on each end :(
Is there a way to configure Paw to use Unicode?
For unicode inputs for HMAC-SHA256 you can use the Escape Sequence dynamic value. Choose ``Custom` escape sequence and type your sequence in the input field (\u + code for unicode characters and \x + code for hex bytes).
If this doesn't work for you, don't hesitate ti send us a support e-mail to support#luckymarmot.com
As part of our app, user can save some data as XML on server which becomes RSS feed for them.
Now some of the file user created have & in file name as BB&T_RSS.xml.
So when user point this to http://example.com/BB&T.xml, they won't get this.
How to stop this? I tried BB%26T.xml, BB&T.xml without any success with IE, Chrome
use an
%26
for an
&
http://example.com/BB%26T.xml,
http://www.w3schools.com/tags/ref_urlencode.asp
then use
HttpServerUtility.UrlDecode Method
to get the file from the url again
URL encoding ensures that all browsers will correctly transmit text in URL strings. Characters such as a question mark (?), ampersand (&), slash mark (/), and spaces might be truncated or corrupted by some browsers. As a result, these characters must be encoded in tags or in query strings where the strings can be re-sent by a browser in a request string.
Many URL schemes reserve certain characters for a special meaning:
their appearance in the scheme-specific part of the URL has a
designated semantics. If the character corresponding to an octet is
reserved in a scheme, the octet must be encoded. The characters ";",
"/", "?", ":", "#", "=" and "&" are the characters which may be
reserved for special meaning within a scheme. No other characters may
be reserved within a scheme. (src)
I need to allow the user to submit queries as follows;
/search/"my search string"
but it's failing because of request validation, as outlined in the following 2 questions:
How to include quote characters as a route parameter? Getting "Illegal characters in path" message
How to modify request validation?
I'm currently trying to figure out how to disable request validation for the quote character, but i'd like to know the risks before I actually put the site live with this disabled? I will not disable the request validation unless I can only disable it for the quote character, so I do intend to disallow every other character that's currently not allowed.
According to the URI generic syntax specification (RFC 2396), the double-quote character is explicitly excluded and must be escaped (i.e. %22). See section 2.4.3. The reason given in the spec:
The angle-bracket "<" and ">" and double-quote (") characters are excluded because they are often used as the delimiters around URI in text documents and protocol fields.
You can see easily why this is the case -- imagine trying to create a link in HTML to your URL:
<a href="http://somesite/search/"my search string""/>
That would fail HTML parsing (and also breaks SO's syntax highlighting). You also would have trouble doing basic things with the URL like emailing it to someone (the email client wouldn't parse the URL correctly), posting it on a message board, sending it in an instant message, etc.
For what it's worth, spaces are also explicitly excluded (same section of the RFC explains why).
let's say I have a JSP Page(i just list part of it, please don't mind):
<%# page language="java" contentType="text/html;charset=UTF-8"%>
<form>
<input type=input>
</input>
中華<!--character with BIG5 encoding>
</form>
and In server side I use this request.setCharacterEncoding("UTF-8");
my problem is:
If i use IME to input Chinese characters into the input box, then when I submit this form, what encoding will the character in the input box is ? WHY?
And if i try to copy the "中華" in the jsp page into the input box and submit the form, in server side, i found the string in the input box is not "UTF-8"(same as the setting in request.setCharacterEncoding) but "BIG5".
And this is in java/jsp, it seems that the request are not really as the setting to be "UTF-8".
why ? can someone tell me something about this ?
But In asp.net, whatever character i input into the input box and post the form, in server side, it will always be UTF-8, and seems to never corrupt.
Why ? does asp.net handle this automatically? it Change the character encoding in the input box into UTF-8 automatically?
I always think that the form post action just treat all the character in the form as some HEX, and will not process them automatically, it just enclose these HEX with header and then send it to server.
But if this idea is true, why the characters will never get corrupted in asp.net?
Thanks in advance!
Identify the point of failure.
中華
The characters you have chosen are (as Unicode codepoints) U+4E2D and U+83EF (in the CJK Unified Ideographs block). On the server, if you take the string you receive and output the values of the constituent characters using Integer.toHexString(mystring.charAt(i)), you should see these values. If this is not the case, there is a problem interpreting data from the client.
You are specifying a page encoding of UTF-8. Encoded as UTF-8, the above characters should take on the following byte sequence values in the rendered HTML:
U+4E2D 0xE4 0xB8 0xAD
U+83EF 0xE8 0x8F 0xAF
So, save the page in the browser as a file and open it in a hex editor - you should see the characters encoded as above.
You can also glean information about what is being sent from the client by sending the form to a servlet, dumping the raw byte input to a file, and inspecting it with a hex editor. It is also worth inspecting the HTTP headers and what character encodings the server and client say they will accept and are sending (see Firebug).