The length of the string Pépé is 6 characters in Chrome, but it is 4 characters in Safari. To determine this, I open up the consoles in both the browsers and enter the following code:
"Pépé".length
This difference is giving me trouble on the server side.
I am using jQuery.$ajax to send a POST request with data containing the string Pépé. When that data reaches the server, it is treating the values differently. I am able to retrieve the data when I am in Chrome but not when I am in Safari.
Inside of the ajax request, I am setting the parameter, contentType: application/json; charset=utf-8.
On the server side, it looks like Pépé when doing the POST request from Safari and Pépé when doing the POST request from Chrome.
Any clue why there is a difference between browsers?
You are probably running into different "normalizations" as there are different ways those accents etc. could be mushed into UTF-8.
There is a really nice discussion here in the answers:
What is normalized UTF-8 all about?
That answer is in the PHP section of Stack Overflow, Java has similar ways of manipulating UTF-8 too. The browsers are probably going to send UTF-8 how they are going to send it. On the server side you probably need to just normalize all your data to NFD or NFC.
I would just force everything to NFC server side. If you are in Java something like this can do it:
http://docs.oracle.com/javase/6/docs/api/java/text/Normalizer.html
Edit:
in all cases byte length and character length will depend on the normalization, as will strict comparisons -- regardless of programming language.
Related
I'm having some trouble receiving information through $_GET[' '].
I send a request to a PHP document, like this
procura_plano.php?plano='+plano+'&operadora='+operadora+'&contrato='+contrato+'&idade='+idade+'&acomo='+acomodacao+'&valor='+valor
because I'm using javascript to make the request. But the last value seems not to be set. Is there a limit of parameters that I can pass through the link?
Sorry for my english :/
Please note that PHP setups with the suhosin patch installed will have
a default limit of 512 characters for get parameters. Although bad
practice, most browsers (including IE) supports URLs up to around 2000
characters, while Apache has a default of 8000.
To add support for long parameters with suhosin, add
suhosin.get.max_value_length = <limit> in php.ini
For More info check this link or URL parameters- Stack Overflow
What w3 Schools say is: Yes, when sending data, the GET method adds
the data to the URL; and the length of a URL is limited (maximum URL
length is 2048 characters)
Check this, GET URL Parameters- w3 Schools
I have been breaking my head for the last couple of days trying to save the screenshot from a ThreeJS on the server using .NET Web API.
I have gone through all the possible questions on this specific topic and related ones on StackOverflow and tried the suggestions as well.
The issue details are specified below:
I am successfully able to get the base64 encoded string from renderer.domElement.toDataUrl() which contains a valid threejs image.
When I pass this string as is to my .NET WebAPI, the Convert.FromBase64String() method fails saying invalid length of the Base64 string or invalid padding characters. I ensured to extract out the "data:image/png;base64," part before passing.
I tried a number of things to resolve this issue like adding padding characters to ensure the length is mod 4, using regular expression to extract out the right data. I was able to get through the Convert.FromBase64String() and saved the resulting byte array as a png on my server. It resulted in a blank image.
I also discovered that when I used the chrome extension Advanced Rest Client to hit my WebAPI and used the Encode Payload feature before posting the string, I was able to get the image saved on my server successfully and got back the desired image as well.
Seeing this, I used the encodeURIComponent() function in Javascript to pass my base64 string to the WebAPI from my web app, but failed, getting back the same behavior as my earlier attempts.
One important observation was that the whitespaces were getting eliminated in case of Encode Payload but not in case of encodeURIComponent.
I compared the strings between encodeURIComponent() and the Encode Payload from Advanced Rest Client. Although, on a high level, they do the same thing by replacing the special characters with their escape sequences, there is still a significant difference between them.
Request help on this issue.
I would like to know if there is any other way of getting the threejs base64 string passed to .NET successfully.
What might be the difference between the encoding of encodeURIComponent and Advanced Rest Client Encode Payload feature?
Thanks in advance!
I have a long JSON string that I want to send from the front-end to PHP on the back-end, but it doesn't seem to work in IE8 because the string exceeds the 2,048 character limit.
The request gets cut off regardless of whether I use a GET request or a POST request.
Are there any ways to get around this limitation?
Thank you.
Edit: To save time reading, the solution is to use POST instead of GET. POST was in fact working, but I had another error in my code, which led me to believe that it wasn't working.
You should just drop the support to IE8.
But, if you really want to use IE8, are you sure you can't use POST for that?
According to this, the limit is on the URL length, but shouldn't affect the POST length (that's what I made of what's written there, perhaps I'm wrong; but I don't have any IE8 installed, so I can't test that).
I have a form which is submitted via mailto to a email server.
As you most know, there is a limitation to the mailto content over which it won't work because it exceeds URL characters limit.
I developed some custom data compression that are domain specific, but it is still not enough (In case all fields are filled, it will bust the limit, this is rare... but rare is bad enough for the client. Never is better.).
I found the Lempel–Ziv–Welch algorithm (http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch) and concluded it would allow me to save 40% of the length average.
Unfortunately, I need of course to call encodeURIComponent to send it to mailto, and as LSW algorightm will return many URL unsupported characters this will in fact make it worse once URL encoded.
Before you tell me it would be easier to make a post to a server using server-side language, let me tell you this is a really unique situation where the form has to be submitted via email via a client-side application, because emails are the only way to connect with the outside world for the end users...
So, do you know any way to compress data efficiently without encodeURIComponent ruining it all ?
Or is there a way to send content to mailto without going through browser ?
I've seen some ways to open Outlook with ActiveX and stuff, but this is pretty browser/email client specific.
Also I checked for options where I save form info in a file using javascript... but the application users are, well let's just say they are not experts at all, and from what I've been told, they could fail to attach the email. (yes, they are that bad)
So I look for the simplest option, where user involvment is almost 0 and where the result is an email sent with the form data, all of that without server-side languages, with a compression algorithm if applicable.
Thanks a lot for your help !
You'll have a hard time getting to "never" with compression, since there will always be strings that a compressor expands instead of compresses. (Basic mathematical property of compression.)
Having said that, there are much better compressors than LZW, depending on the length of your input. You should try zlib and lzma. The binary output of those would then need to be coded using only the allowed URL characters.
Is there a limit to the length of the parameter that be can added to the url for ajax? I am using Thin server on Ruby, and did an ajax request from the web browser in this format:
io=new XMLHttpRequest();
io.open("GET","http://localhost:3000&v="+encodeURIComponent(JSON.stringify(v)),true);
When the length of the string v exceeds about 7000 bytes, it seems to crash. When less, it seems to work. Is my observation right? Where is the restriction coming from? From Thin, Javascript, or the browser? I use Google Chrome browser.
Is there a limit to the length of the parameter that can added to the url for ajax?
Yes, if you are using a GET request there's a limit which will depend on the client browser. And this limit has nothing to do with AJAX. IIRC it was around 4K for IE but things might have changed. But in any case there's a limit. If you don't want to be limited you should use POST.
Restriction most likely comes from the browser. According to this discussion you should try to keep your URLs under about 2000 characters.
There is a limit to the GET request depending on the character bytes. If you use ASCII it's 256 characters including the url itself. For UTF-8 it's practically the half because 1 utf character is 2bytes long.
You won't have this problem on POST though.