I am developing mobile with Xamarin and Node.js
and I want to post text using 'Editor'
In Xam.Android, Xam.iOS,
When I post text,
the result is
aa
bb
But In UWP
aabb
When I checked text that post's body in client,
all platforms show correct body
But, When I check text that post's body in node
Android, iOS's body is correct, UWP's body is incorrect
How I solve this?
Android, iOS's body is correct, UWP's body is incorrect
The Editor control is used to accept multi-line input. For my test, the line breaks for each platform are different.
IOS: \n
Android:\n
UWP:\r
So you could replace \r with \n in your client or make your node.js service support \r line break.
var Str = editor.Text.Replace("\r", "\n");
Related
I'm trying to send a request to my Nestjs application, with just plain string in the request body, for example:
test23+Se5+345
Then in my application, I have a middleware, where I need to do something with this string.
The problem is when I access request body in middleware const requestBody = Object.keys(req.body)[0];, this string looks like this:
test23 Se5 345
All of the + symbols are substituted by
I don't have additional convertings before this, and I know that middleware runs first in the request lifecycle. I think maybe there is some issue with body-parser, but I don't know yet how to fix this.
This is because symbol + is treated as space, so before send it, you need to encode your + characters to %2b. More here: How to encode the plus (+) symbol in a URL
I'm having an issue with a NodeJS REST api created using express.
I have two calls, a get and a post set up like this:
router.get('/:id', (request, response) => {
console.log(request.params.id);
});
router.post('/:id', (request, response) => {
console.log(request.params.id);
});
now, I want the ID to be able to contain special characters (UTF8).
The problem is, when I use postman to test the requests, it looks like they are encoded very differently:
GET http://localhost:3000/api/â outputs â
POST http://localhost:3000/api/â outputs â
Does anyone have any idea what I am missing here?
I must mention that the post call also contains a file upload so the content type will be multipart/form-data
You should encode your URL on the client and decode it on the server. See the following articles:
What is the proper way to URL encode Unicode characters?
Can urls have UTF-8 characters?
Which characters make a URL invalid?
For JavaScript, encodeURI may come in handy.
It looks like postman does UTF-8 encoding but NOT proper url encoding. Consequently, what you type in the request url box translates to something different than what would happen if you typed that url in a browser.
I'm requesting: GET localhost/ä but it encodes it on the wire as localhost/ä
(This is now an invalid URL because it contains non ascii characters)
But when I type localhost/ä in to google chrome, it correctly encodes the request as localhost/%C3%A4
So you could try manually url encoding your request to http://localhost:3000/api/%C3%A2
In my opinion this is a bug (perhaps a regression). I am using the latest version of PostMan v7.11.0 on MacOS.
Does anyone have any idea what I am missing here?
yeah, it doesn't output â, it outputs â, but whatever you're checking the result with, think you're reading something else (iso-8859-1 maybe?), not UTF-8, and renders it as â
Most likely, you're viewing the result in a web browser, and the web server is sending the wrong Content-Type header. try doing header("Content-type: text/plain;charset=utf-8"); or header("Content-type: text/html;charset=utf-8"); , then your browser should render your â correctly.
I want to return some preformatted html in a snap application. However, when the handler below is served,
aPage :: Handler App App ()
aPage = do
writeText "<p>This is a page</p>"
The output is couched in < pre > tags.
...<body><pre><p>This is a page</p></pre></body> ...
Is there a simple way to add a verbatim string to the response body?
You don't.
As Carl pointed out in the comment to my question, it was not "escaped" to begin with. What I was seeing was the browsers rendition of the plaintext document. Simply sending a properly formatted document gives me what I was expecting.
aPage :: Handler App App ()
aPage = do
writeText "<!DOCTYPE html><html><head></head><body><p>This is a page</p></body></html>"
After fiddling with Blaze-html and Lucid, two libraries for generating html, I was sure some sort of formatting was going on under the hood and thought some sort of toHtmlRaw function was needed. Not at all the answer I was expecting.
file_get_contents(http://smshorizon.co.in/api/sendsms.php?user=***&apikey=******&mobile=*****&message=Hello World&senderid=xxyy&type=txt)
Here in this SMS API when I use a message with space say "Hello World" then it return HTTP/1.1 400 Bad Request. But when I remove the space and instead I write HelloWorld it works fine.
What is the issue?
Why its happening (Problem):
URL is getting spitted because of space between messages and it will consider only part before space.
Solution:
You can use PHP inbuilt function urlencode();
Input : urlencode('Hello World');
Output : urlencode('Hello%20World');
I have a server running on nodejs, and I have the following piece of code to manage a post request -
form.on('file', function (field, file) {
var RecordingInfo = JSON.parse(file.name);
...
when I tried to upload a file I got the following exception:
undefined:1
"}
SyntaxError: Unexpected end of input
at Object.parse (native)
at IncomingForm.<anonymous> (.../root.js:31:34)
...
searching around the web, I fond that this exception is caused because the data comes in bits, and the event is fired after the first bit arrives, and I don't have all the data. OK. The thing is, after a little testing I fond that from chrome I can upload large files (tried a 1.75gb file) without any problem, while firefox crashes the server with a 6kb file.
My question is - why are they different?
A sample capture can be downloaded form here. The first post is from chrome, the second from firefox.
The complete file.name string before uploading is:
// chrome
"{"subject":"flksajfd","lecturer":"אבישי וינר","path":"/גמרא","fileType":".png"}"
// firefox
"{"subject":"fdsa","lecturer":"אלקס ציקין","path":"/גמרא","fileType":".jpg"}"
(The data submitted is not the same, but I don't think it matters)
Chrome is encoding double-quotes in the JSON-encoded "filename" as %22 while Firefox is encoding them as \".
Your file upload parsing library, Formidable, explicitly truncates the filename from the last \ character. It expects double-quotes to be encoded as %22 although RFC 2616 allows backslash-escaped quotes like Firefox has implemented. You can consider this a bug in Formidable. The result is that the following JSON string:
'{"subject":"fdsa",...,"fileType":".jpg"}'
...is encoded as follows:
'{%22subject%22:%22fdsa",...,%22fileType%22:%22.jpg%22}' // Chrome
'{\"subject\":\"fdsa\",...\"fileType\":\".jpg\"}' // Firefox
...and then decoded by Formidable:
'{"subject":"fdsa",..."fileType":".jpg"}' // Chrome
'"}' // Firefox
To fix the issue you have a few choices:
Raise the issue with Formidable to correctly handle backslash-escaped quoted-value strings (or fix it yourself and submit a pull request).
Send the JSON payload in a separate part of the FormData object, e.g. using a Blob.
Transliterate all double-quote characters in your JSON-format filename to a 'safe' character that will not appear elsewhere in the string (I chose ^ as an example); replace the quote client-side and reinstate it server-side as follows.
Client:
var formData = new FormData();
formData.append('file', $scope.recording, JSON.stringify(RecordingInfo).replace(/"/g, '^');
Server
form.on('file', function (field, file) {
var RecordingInfo = JSON.parse(file.name.replace(/\^/g, '"');