The node-sms-pdu is a SMS-SUBMIT PDU (Packet Data Unit) generator and SMS-SUBMIT/DELIVER PDU parser. This module supports the GSM 7-bit default alphabet encoding and the UCS-2 16-bit alphabet encoding. Besides, it supports the Concatenated (or Multipart or Long) SMS.
1) When the @ symbol appeared in a multipart message immediately preceded by a space, the septets would stop being buffered and a range error would be produced. I have no idea why the preceding space triggered it but I found that the return value of shift() was being tested with a ! (falsey) so the break condition was met when @ was encountered which has a gsm7 code value of 0. Changing this to test for typeof undefined instead fixed the issue for long messages containing @ ... again I have no idea why this didn't break for all long messages containing @ 🤷🤷🤷
2) The regex for splitting multipart ucs2 messages used the "." character class, which doesn't match newlines all the time (unless some modifiers are used). I have found the most reliable way to match any character including a new line is to not use a modifier by rather to use the character class [^] which just basically means any character at all (ie. "not nothing"). This fixes a bug where multipart UCS2 messages with newlines present in the final part of the message were not delivered successfully. Previously what happened was that the final part was ignored so only the first 2 PDUs would be sent to the handset and the message would never be displayed (because the UDH values were calculated from the original string, not the split components).
Hi there, I found 2 cases caused problems:
1) When the @ symbol appeared in a multipart message immediately preceded by a space, the septets would stop being buffered and a range error would be produced. I have no idea why the preceding space triggered it but I found that the return value of shift() was being tested with a ! (falsey) so the break condition was met when @ was encountered which has a gsm7 code value of 0. Changing this to test for typeof undefined instead fixed the issue for long messages containing @ ... again I have no idea why this didn't break for all long messages containing @ 🤷🤷🤷
2) The regex for splitting multipart ucs2 messages used the "." character class, which doesn't match newlines all the time (unless some modifiers are used). I have found the most reliable way to match any character including a new line is to not use a modifier by rather to use the character class [^] which just basically means any character at all (ie. "not nothing"). This fixes a bug where multipart UCS2 messages with newlines present in the final part of the message were not delivered successfully. Previously what happened was that the final part was ignored so only the first 2 PDUs would be sent to the handset and the message would never be displayed (because the UDH values were calculated from the original string, not the split components).