Hi everyone,
I’m running asterisk 1.4 (yes is old). I already know that for working with special character like $,% it must be quote it with a preceding \ but that is not working with “ñ”, very used Latin special character.
For example, word “Señor” below it’s replaced by “▒”. That is breaking my PHP code.
exten => 1234,1,Answer()
exten => 1234,n,agi(ibmtts.php,'Buenos dias Se\ñor Martinez")
Result:
Executing [1234@from-internal:1] Answer(“SIP/150-0000015c”, “”) in new stack
– Executing [1234@from-internal:2] AGI(“SIP/150-0000015c”, “ibmtts.php|Buenos dias Se▒or Martinez”) in new stack
Any idea would be appreciated.
Regards
There were significant changes in the parsing between 1.4 and 1.6.
Asterisk treats character as 8 bit so will treat the individual bytes of UTF-8 as individual characters.
What character encoding were you actually using?
I can think of no way in which the transformation you are showing, between +00F1 and U+2592 could happen, even if the coding were UTF-8.
Hi David thanks for the answer.
I’m using character “ñ”, but really don’t know about encoding.
Just know that when “ñ” is used is transformed to this mysterious character“▒”.
Any ideas?
Asterisk doesn’t know about encoding either. It assumes that the known special characters have their ASCII encoding, but, otherwise, should pass through bytes intact.
Your problem is going to be encoding dependent, so you need to know what the encodings are to make any progress, e.g. is it possible that you are writing with one encoding, but reading with another.
Encoding for “ñ” is ASCII 164.
How can I now what encoding are used for reading and writing?
ASCII has no code points beyond 127, so it is not ASCII. It is compatible with IBM CP437, which is essentially obsolete, although might be used in Windows DOS boxes.
Typical modern systems, in the USA and Western Europe, use the ISO 8859-1 encoding, in which the code point would be 251, although there is an increasing trend towards using UTF-8, in which it would be represented by the two byte sequence. This forum uses UTF-8.
The encoding you are actually reading out will depend on the OS you are using and how it is configured, as well as the configuration of any terminal program you are using. These are essential things to know if using characters outside the 95 character ASCII printable range (counting space as printable), and nothing to do with Asterisk.
If you read out 164 as ISO 8859-1, you would see an uncommon currency symbol, consisting of a small, centered circle, with spikes pointing out in NE, SE, SW and SE directions (assuming North is up). That is not what you posted to the forum, though. That character is “¤”, although I cannot guarantee that your system will reproduce it.
Interpreted as UTF-8 it is an invalid first byte of a code, so would presumably produce some form of error recovery action.
My best guess is you are writing it as CP437, and you are seeing the results of error recovery from trying interpret it as invalid UTF-8, with Asterisk not changing it at all.
1 Like