I am trying to send Danish characters (Æ, Ø, Å) in an alarm notification using Easy APNs but when doing so, no message is send. If I send it with sound, only the sound is send. Also the message will be set to "null" in the database if it includes any of the Danish characters.
Does anyone know a fix for this?
This was caused by json_encode(). Using utf8_encode() on my alert views before json_encode() solved the issue.
UPDATE (How to fix the issue)
1. In class_APNS.php around line 411, you have
$msg = chr(0).pack("n",32).pack('H*',$token).pack("n",strlen($message)).$message;
Above that, put:
$message = utf8_encode($message);
2. In class_APNS.php (same file) put this:
$usermessage['aps']['alert'] = utf8_encode($usermessage['aps']['alert']);
Put it just above the following:
$fk_device = $this->db->prepare($list[$i]);
$message = $this->_jsonEncode($usermessage);
$message = $this->db->prepare($message);
$delivery = (!empty($when)) ? "'{$when}'":'NOW()';
Related
I am using SMPP Receiver API to get the messages from specific MSISDN. I am getting the English text correctly. But the Dari and Pashto text is not in same format. It shows output like below :
/ '2(� /'HFD/1
My Code is :
ob_start();
require_once "smpp.php";//SMPP protocol
//connect to the smpp server
$tx=new SMPP('IP',PORT);
//bind the receiver
$tx->system_type="NUll";
$tx->addr_npi=0;
$tx->bindReceiver("username","password");
do
{
//read incoming sms
if($sms=$tx->readSMS())
{
print_r($sms);
}
}while($sms);
And smpp.php is at :
http://121.100.50.58/apps/smpp/
How I can get the correct Dari and Pashto Language Message text?
Try this
$utf8 = $body;
$encodedMessage = mb_convert_encoding($utf8, "UCS-2", "utf8");
$from = new SmppAddress($sender, SMPP::TON_ALPHANUMERIC);
$to = new SmppAddress($number, SMPP::TON_INTERNATIONAL, SMPP::NPI_E164);
$smppClient->sendSMS($from, $to, $encodedMessage, [], SMPP::DATA_CODING_UCS2);
It works completly for polish characters and I'm pretty sure it works with all unicode.
Save the .php script itself in utf-8. This also has to line up with the charset in your browser.
If that still doesnt work, check out mb_convert_encoding http://de2.php.net/manual/en/function.mb-convert-encoding.php.
The text seems to be sent from the SMSC in UNICODE. It should be just a matter of using the correct encoding and charset ... try using charset UTF16-BE and encoding UCS2
I am using imap_open function in PHP to download emails and insert them into a mysql database
Here is my code to get the headers and body message etc:
$emails = imap_search($inbox,'ALL');
//if emails are returned, cycle through each...
if($emails)
{
//begin output var
$output = '';
//put the newest emails on top
rsort($emails);
//for every email...
foreach($emails as $email_number)
{
//get information specific to this email
$header=imap_headerinfo($inbox,$email_number);
$structure = imap_fetchstructure($inbox,$email_number);
$from = $header->from[0]->mailbox . "#" . $header->from[0]->host;
$toaddress=$header->to[0]->mailbox."#".$header->to[0]->host;
$replyto=$header->reply_to[0]->mailbox."#".$header->reply_to[0]->host;
$datetime=date("Y-m-d H:i:s",$header->udate);
$subject=$header->subject;
$message = quoted_printable_decode(imap_fetchbody($inbox,$email_number,1.1));
if($message == '')
{
$message = quoted_printable_decode(imap_fetchbody($inbox,$email_number,1));
}
}
}
but it doesnt seem to get the body of all emails. For example, when it receives Read Receipts the body is just blank and the same with some other emails people send.
sometimes, the email body looks like:
PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PnJlcGx5PC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt YXJnaW46IDBweCAwcHggMTJweDsiPjxiPktpbmQgUmVnYXJkcyw8YnI+DQo8YnI+DQpDaGFybGll IEZvcmQgfCZuYnNwOzwvYj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyNTIsIDc5LCA4KTsiPjxi PlRlY2huaWNhbCBNYW5hZ2VyJm5ic3A7PC9iPjwvc3Bhbj48Yj58Jm5ic3A7SW50ZWdyYSBEaWdp dGFsPC9iPjxmb250IGNvbG9yPSIjNTk1OTU ... continued
How can i convert the whole message body to be plain text
Here's what I use, in general. $email refers to one of the objects from the return of eg imap_fetch_overview:
$structure = imap_fetchstructure($email->msgno);
$body = imap_fetchbody($email->msgno, '1');
if (3 === $structure->encoding) {
$body = imap_base64($body);
} else if (4 === $structure->encoding) {
$body = imap_qprint($body);
}
Note there are 6 possible encodings (ranging from 0 to 5), and I'm only handling 2 of them (3 and 4) -- you might want to handle all of them.
Also note I'm also getting only the 1st part (in imap_fetchbody) -- you might want to loop over the pieces to get them as needed.
Update
One other thing I noticed about your code. You're doing imap_fetchbody($inbox,$email_number,1.1). That third argument should be a string, not a number. Do this instead:
imap_fetchbody($inbox, $email_number, '1.1')
The code given handles only simple text messages having at most one sub-part and no encoding. This is basically the simplest kind of email there is. The world used to be that simple, sadly no more!
To handle more email, your code must be expanded to handle:
Multi-parts
Encodings
Multi-part is the concept that a single email message (a bunch of data) can be divided into multiple, logically-separate pieces. In the simplest case, there is only one part: the text of the message. In the next simplest case, there is message text with a single attachment. The next simplest case is message text plus multiple attachments. Then it starts to get hard, when the text of the message refers inline or embeds the attachments (think of an HTML message with an image -- that image could be an attachment that's linked with "local" CSS or embedded as eg base64 data url).
Encoding is the idea that email needs to accommodate the lowest common denominator of SMTP servers on the Internet. From 1971 to the early 1990s, most email messages were plain text using 7-bit US ASCII character set -- and SMTP mailers in the middle relied on this 7-bit framework. As the need for character sets became more apparent, simultaneously with the need to send binary data (eg images), 8-bit SMTP mailers cropped up as did various methods to shoe-horn 8-bit clean data into 7-bits. These include quoted-printable and base64. While 7-bit is virtually dead, we still have all the hoops of this history to jump through.
Rather than re-invent the wheel, there is a good piece of code on PHP.net that handles multi-part encoded messages. See the comment by david at hundsness dot com. You would use that code like this:
$mailbox = imap_open($service, $username, $password) or die('Cannot open mailbox');
// for all messages
$emails = imap_fetch_overview($mailbox, '1:1'/* . imap_check($mbox)->Nmsgs*/);
foreach ($emails as $email) {
// get the info
getmsg($mailbox, $email->msgno);
// now you have info from this message in these global vars:
// $charset,$htmlmsg,$plainmsg,$attachments
echo $plainmsg; // for example
}
imap_close($mailbox);
(Side note: his code has three parse errors, where he does ". =" to mean ".=". Fix those and you're good to go.)
Also, if you're looking for a good blog on doing this "from the ground up", check out this: http://www.electrictoolbox.com/php-imap-message-parts/
I'm making a SMS sending function for at project i'm working on. The code works just fine, but
when i send the letters 'æ-ø-å-Æ-Ø-Å' it turns to 'f-x-e-F-X-E'.
How do i change the encoding so that I can send these letters?
This is my code:
<?php
include "php_serial.class.php";
$html = $_POST['msg'];
$serial = new phpSerial;
$serial->deviceSet("/dev/cu.HUAWEIMobile-Modem");
$serial->deviceOpen();
$serial->sendMessage("ATZ\n\r");
// Wait and read from the port
var_dump($serial -> readPort());
$serial->sendMessage("ATE0\n\r");
// Wait and read from the port
var_dump($serial -> readPort());
// To write into
$serial->sendMessage("AT+cmgf=1;+cnmi=2,1,0,1,0\n\r");//
$serial->sendMessage("AT+cmgs=\"+45{$_POST['number']}\"\n\r");
$serial->sendMessage("{$html}\n\r");
$serial->sendMessage(chr(26));
//wait for modem to send message
sleep(3);
$read=$serial->readPort();
$serial->deviceClose();
$read = preg_replace('/\s+/', '', $read);
$read = substr($read, -2);
if($read == "OK") {
header("location: index.php?send=1");
} else {
header("location: index.php?send=2");
}
?>
First of all, you must seriously redo your AT command handling to
Read and parse the every single response line given back from the modem until you get a final result code for every single command line invocation, no exceptions whatsoever. See this answer for more details.
For AT+CMGS specifically you also MUST wait for the "\n\r> " response before sending data, see this answer for more details.
Now to answer your question about æøå turning into fxe, this is a classical stripping of the most significant bit of ISO 8859-1 encoding (which I had almost forgotten about). This is probably caused the default character encoding, but since you always should be explicit and set the character encoding you want to use in any case, investigating that further is of no value. The character encoding used for strings to AT commands is controlled by the AT+CSCS command (see this answer for more details), run AT+CSCS=? to get a list of options.
Based on your information you seem to using ISO 8859-1, so running AT+CSCS="8859-1" will stop zeroing the MSB. You might be satisfied with just that, but I strongly recommend using character encoding UTF-8 instead, it is just so vastly superior to 8859-1.
All of that failing I am quite sure that at least one of the GMS or IRA encodings should supports the æøå characters, but then you have to do some very custom translation, those characters will have binary values very different from what is common in text elsewhere.
I'm using the CodeIgniter email library to send emails using our Exchange server. The problem I get is that the content of the email gets messed up.
There are some words that get replaced with equal signs "=", I tried 2 different Exchange servers (they are in different locations and have no relation what so ever) and I still get the same issue. If I use any other server as an SMTP server to send emails everything works fine and the content stays intact and unchanged.
Content before sending:
Dear Customer
Please find attached a comprehensive explanation of how to get our brochure of Angola. This has been sent to you at the request of Alex.
The information has been taken from www.example.co.uk "Company name" is one of the leading tile and marble companies in the UK.
Content after sending it through the Microsoft Exchange:
Dear Customer
Please find attached a comprehensive explanation of how to get our brochure of A=gola. This has been sent to you at the request of Alex.
The information has been taken from www.example.co.uk "Company name" is one of the leadi=g tile and marble companies in the UK.
As you can see for some reason some of the "n" characters were replaced with equal signs "=" (Example: Angola > A=gola)
My email configuration:
$this->load->library('email');
$config['charset'] = 'utf-8';
$config['mailtype'] = 'html';
// SMTP
$config['protocol'] = 'smtp';
$config['smtp_host'] = 'exchange.example.com'; //ssl://
$config['smtp_user'] = 'email#example.com';
$config['smtp_pass'] = 'password';
$config['smtp_port'] = 25;
$this->email->set_newline( "\r\n" );
$this->email->initialize( $config );
$this->email->clear();
......
$this->email->from( $frome, $fromn );
$this->email->to( $email );
$this->email->subject( $subject );
$this->email->message( $send_message );
$this->email->send();
Does anyone know why is the Microsoft exchange behaving this way? or is there some sort of setting I should use?
That's odd, specially since not all the ns are transliterated and not at a specific position.
Try calling $this->email->set_crlf( "\r\n" ); as well. Look up the message details in Exchange and inspect the Content-Type and Charset / Encoding - post the raw thing here so we can inspect it.
I found this in Microsoft Knowledgebase:
Microsoft Exchange uses an enhanced character set. The default MIME
character set for Microsoft Exchange is ISO 8859-1. Some gateways do
not support the way this character set issues a soft return for line
feeds. When this occurs, each line is terminated with an equal sign
showing the line break where the gateway's line-length support ends.
I solved this (kinda) by setting $charlim = '998' in the _prep_quoted_printable function.
When I set $crlf = "\r\n" the resulting email was completely garbled for some reason. But I noticed that the = signs were appearing at regular intervals which was caused by the line length being limited to 76 characters. So increasing the max characters per line (998 is the RFC2822 limit) solves the problem, as long as you don't have really long lines.
I've set up a script that processes incoming emails and creates blog entries on Blogger. I'm using PEAR's Mail_Mime libs (for now) to read the incoming message. The messages often have characters in them that cannot be read by browsers--this happens most often when people use Outlook or cut/paste from MS Word.
So the output at the other end is something like this:
Here is a test post with “quotes” and ‘apostrophes�for what it�s worth, it also has dashes�and other strange formatting cut and paste from MS Word.
You can also see the output in the wild.
It's not hard to fix any specific instance, but each client (hotmail, gmail, outlook, etc) seems to handle things just a bit differently. Mail_Mime only seems to munge the output and, if I turn off Mail_Mime's parsing and try to translate the encoded characters myself using mb_convert_encoding or some manual simulation of this, it's even worse.
Please not that this is not going to be solved by selecting the right encoding type and using decode/encode/convert functions. The incoming formats vary from Windows-1252 to UTF8 to just about anything else mail clients can think of.
Has anyone scripted this before that could save me some time by offering up a sample or advice on the best approach? I've tried all the simple answers and done plenty of experimenting, so please don't bother responding unless you've dealt with a similar issue successfully or have a deep understanding of encoding issues.
The only way to do this is to do it by the spec's which is I'm afraid to pull in the 'Content-Type' mime header, pick up the charset (it'll look like Content-Type: text/plain; charset="us-ascii") then convert to UTF-8, and of course ensure your output on the web is sent as UTF-8 with the right headers.
To solve this problem, and get my message into valid UTF-8 that is readable from a browser, I found this PHP lib, ConvertCharset by Mikolaj Jedrzejak, which worked on almost everything. It still had issues with a specific symbol (=A0) when converting from Windows-1252 or iso-8859-1. So I converted this character manually before setting the code loose.
Here's what it looks like overall:
// decode using Mail_Mime
require 'Mail.php';
require 'Mail/mime.php';
require 'Mail/mimeDecode.php';
$params['include_bodies'] = true;
$params['decode_bodies'] = true; // this decodes it!
$params['decode_headers'] = true;
$decoder = new Mail_mimeDecode($input);
$mime = $decoder->decode($params);
// too much work to put in this example
$charset = ...; //do some magic with $mime->parts to get the character set
$text = ...; //do some magic with $mime->parts to get the text
// fix the =A0 control character; it's already been decoded
// by Mail_Mime, so we need the actual byte code now
// this has to be done before trying to convert to UTF-8
$char = chr(hexdec(substr('A0',1)));
$text = str_replace($char, '', $text);
// convert to UTF-8 using ConvertCharset
require 'ConvertCharset.class.php';
if( strtolower($charset) != 'utf-8' ) {
$converter = new ConvertCharset($charset, 'utf-8', false);
}
$text = $converter->Convert($text);
Then everything is spiffy. It even does the infamous Iñtërnâtiônàlizætiøn conversion, as well as accepting french, spanish, and pastes directly from MS Word :)