PHP iOS Push notifications arabic multilingual text larger in size - php

I don't really know how to ask these but hopefully i can make myself clear enough for you to understand my questions
Below is the Arabic text which I want to send via Apple iPhone Push Notifications:
يبدا بقرص العقيلي واللقيمات وينتهي مع خالد حرية بالامارات نكهة وبهار مع القصار-٦ مساءا على يشان الليله في انا والعسل مع غاده عبدالرازق تلفزيون الكويت
Can i send this long text?
Because when I prepare a payload, it says 360 bytes of size. While Apple allows only 256 bytes of payload.
What can be done for same?
I'm using this code for same.

Doesn't sound like this is something you can work around. Try shortening the notification message and then pointing the user towards your app where you can display a more descriptive message.

Got one trick [not sure this is permanent soln though] temporarily: May be handy to other people in future
commented below code of line
//$payload = json_encode($body);
And directly appending JSON format to Payload variable
$payload = '{"aps":{"alert":"'.$message.'","sound":"default","badge":"+1"}}';
Here, $message will be my Arabic string for actula message and it WORKS !!

Related

How to encode SMS PDU in php

I was trying to apply AT commands on my Huawei modem using gammu. I can use following commands to access USSD from ZTE Modem:
gammu getussd *111#
but in huawei modem, it doesn't work. As per my study, I need to provide PDU instead of text. Then I used this link to encode my code *111# and try following on command line.
gammu getussd AA582C3602
and it works!. Now I need to convert *111# to AA582C3602 using php.
This link describe how to decode PDU Encoded message. but I didn't find any reverse way to convert back the normal text into PDU encoded message.
Badly need your help.
Some Huawei modems don't support USSD... E220 doesn't... I'm using E1550 in Portugal for NOS (old Optimus) operator with no issues, but yes it's PDU encoded.
Tell the modem you will be sending PDU encoded whith AT+CMGF=0.
I use this commands prior to send the USSD
AT+CMGF=0
AT+CSCS="IRA"

Sending compressed text over Amazon SQS from PHP to NodeJS

I seem to be stuck at sending the compressed messages from PHP to NodeJS over Amazon SQS.
Over on the PHP side I have:
$SQS->sendMessage(Array(
'QueueUrl' => $queueUrl,
'MessageBody' => 'article',
'MessageAttributes' => Array(
'json' => Array(
'BinaryValue' => bzcompress(json_encode(Array('type'=>'article','data'=>$vijest))),
'DataType' => 'Binary'
)
)
));
NOTE 1: I also tried putting compressed data directly in the message, but the library gave me an error with some invalid byte data
On the Node side, I have:
body = decodeBzip(message.MessageAttributes.json.BinaryValue);
Where message is from sqs.receiveMessage() call and that part works since it worked for raw (uncompressed messages)
What I am getting is TypeError: improper format
I also tried using:
PHP - NODE
gzcompress() - zlib.inflateraw()
gzdeflate() - zlib.inflate()
gzencode() - zlib.gunzip()
And each of those pairs gave me their version of the same error (essentially, input data is wrong)
Given all that I started to suspect that an error is somewhere in message transmission
What am I doing wrong?
EDIT 1: It seems that the error is somewhere in transmission, since bin2hex() in php and .toString('hex') in Node return totally different values. It seems that Amazon SQS API in PHP transfers BinaryAttribute using base64 but Node fails to decode it. I managed to partially decode it by turning off automatic conversion in amazon aws config file and then manually decoding base64 in node but it still was not able to decode it.
EDIT 2: I managed to accomplish the same thing by using base64_encode() on the php side, and sending the base64 as a messageBody (not using MessageAttributes). On the node side I used new Buffer(messageBody,'base64') and then decodeBzip on that. It all works but I would still like to know why MessageAttribute is not working as it should. Current base64 adds overhead and I like to use the services as they are intended, not by work arounds.
This is what all the SQS libraries do under the hood. You can get the php source code of the SQS library and see for yourself. Binary data will always be base64 encoded (when using MessageAttributes or not, does not matter) as a way to satisfy the API requirement of having form-url-encoded messages.
I do not know how long the data in your $vijest is, but I am willing to bet that after zipping and then base64 encoding it will be bigger than before.
So my answer to you would be two parts (plus a third if you are really stubborn):
When looking at the underlying raw API it is absolutely clear that not using MessageAttributes does NOT add additional overhead from base64. Instead, using MessageAttributes adds some slight additional overhead because of the structure of the data enforced by the SQS php library. So not using MessageAttributes is clearly NOT a workaround and you should do it if you want to zip the data yourself and you got it to work that way.
Because of the nature of a http POST request it is a very bad idea to compress your data inside your application. Base64 overhead will likely nullify the compression advantage and you are probably better off sending plain text.
If you absolutely do not believe me or the API spec or the HTTP spec and want to proceed, then I would advise to send a simple short string 'teststring' in the BinaryValue parameter and compare what you sent with what you got. That will make it very easy to understand the transformations the SQS library is doing on the BinaryValue parameter.
gzcompress() would be decoded by zlib.Inflate(). gzdeflate() would be decoded by zlib.InflateRaw(). gzencode() would be decoded by zlib.Gunzip(). So out of the three you listed, two are wrong, but one should work.

PHP: How to distinguish between encrypted and unencrypted email?

I want to create a new email account which only receives encrypted email. Unfortunately, I cannot modify the mail server configuration so I considered checking incoming email every 2 minutes with a cronjob and automatically rejecting those messages which are not encrypted.
So far I did this:
$body = imap_body($mbox, $i);
if (substr($body,0,27) == "-----BEGIN PGP MESSAGE-----")
$encrypted = true;
else
$encrypted = false;
Works, but I'm pretty sure I don't capture all encrypted email. I didn't find a unique option in the header which would tell me that a message is encrypted. Enigmail left a message though:
X-Enigmail-Version: 1.5.1
This, however, does not help me in any way. Is it enough to just grep for the BEGIN PGP MESSAGE string as I did above?
As a student of computational linguistics my first idea was to try it statistically:
As far as I know encrypted messages do not contain spaces. So you could tokenize the email body into words, and calculate the average length of the words. Try this on some other mails or texts and see how the average length differs.
It may be a bit extravagant, but is more effective than looking for a substring: for example someone may send a webpage or text dealing with encryption or the latest NSA leaks ;-)

PHP Post Body Encoding Problems

I'm trying to mimick an application that sends octet streams to and from a server. The data contained in the body looks like raw bytes, and I'm fairly certain the data being sent for each command is static, so I'm hoping to map the bytes to something more readable in my application. For example, I'll have an array that does: "test" => "&^D^^&#*#dgkel" So I can call "test" and get the real bytes that need to be sent. Trouble is, PHP seems to convert these bytes. I'm not sure if it is an encoding problem or what, but what has been happing is I'll give it some bytes (for example, �ھ����#�qs��������������������X����������������������������) which has a length of 67 I believe, but PHP will say (when I do a var_dump of the HTTP request) that the headers sent contained "Content-Length: 174" or something close to that and the bytes will look like �ھ����#�qs��������������������X����������������������������
So I'm not really sure how to fix this.. Anyone have any ideas? Cheers!
Edit, a little PHP:
$request = new HttpRequest($this->GetMessageURL(), HTTP_METH_POST);
$request->addHeaders($headers);
$request->addRawPostData($buttonMapping[$button]);
$request->send();

What kind of image format is this?

My webserver is receiving image data from an iOS App via HTTP POST.
The transmitted image-data looks like this:
$postvar1=x&image=<89504e47 0d0a1a0a 0000000d 49484452 00000100 00000064 08060000 006960ee 9e000020 00494441 547801ed 5d099c14 c5b9afea 9ed9fb98 5941c428 a2c62320 0a8a8047 3cf06017 573cc178 c0eea246 8db9f4f9 e22f79fa 7c26e6c5 f78cd1e4 19351ad9 5d0ea360 3c815d62 bc350a51 f008781b 82181570 67f66477
I don't know what to do with this string in PHP. What kind of encoding is it?
Thanks!
Its a PNG file.
The PNG Magic number is 8950.4e47.0d0a.1a0a
ASCI \x89PNG\r\n\x1a\n
It's binary, it's an image file, it can't "Do" anything with it as it is...
And according to my hex editor, it's a PNG...
Since the other answers miss it: It what you get from -[NSData description] (a hexdump between angle brackets, like <01234567 89ABCDEF>). This probably happens due to someone doing something like [NSString stringWithFormat:#"blah&image=%#", data]. The reasons why this is terrible are too numerous to mention.
It's far, far preferable to upload as multipart/form-data or (if you send any other fields you need in a header) just image/png or application/octet-stream. The hexdump overhead is huge.
It's a png here is it
http://i.stack.imgur.com/bUXLb.png
256x100 but it's just transparent
If you want to convert it in php have a look at the pack function

Categories