I would like to understand the differences between the next parameters:
smpp.data_coding
smpp.dcs
smpp.dcs.charset
It seems to be that the vale of smpp.data_coding and smpp.dcs always match. However, I'm not sure if the value of smpp.dcs could be different of the value of smpp.data_coding.
I was looking for some information, but it isn't still clear for me, so I appreciate your help.
Thank you.
Kind regards,
I am not sure if its gonna help, maybe you have read it already but there is not much of the difference contextually between data_coding and dcs. However, data_coding field is restricted to sharing 1 byte of value and representing what coding is being used. While, with dcs in addition to the 1 byte of data that is associated about the coding scheme, we also get additional attribute fields like - charset.
This may not be significant in general sense, but check this out - https://helpx.adobe.com/in/campaign/kb/smpp-protocol-wireshark.html
The data_coding field tells you which encoding is used. The only problem is that the value 0 means default SMS-C encoding in the specification, but in general it means GSM7. Check with the SMS-C partner what encoding is associated to data_coding = 0 (Adobe Campaign only supports GSM7 for data_coding = 0).
Hence, while value of data_coding and dcs might look same, dcs.charset helps identify the character set being used and hence the message size too.
Maybe you have figured it out already..
Related
I'm trying to understanding the legalities of query params. Specifically, I'm curious if it's a hard-and-fast rule that the query string must be made up of key-value pairs or if it's technically valid to have a key-only. No, I don't mean a key with an equals-sign then nothing after it. I mean not even the equals-sign. Just a key.
For instance 'demomode' in this example:
https://www.somesite.com/search?searchString=abc&demomode
Again, this is how I would actually do it...
https://www.somesite.com/search?searchString=abc&mode=demo
-or-
https://www.somesite.com/search?searchString=abc&demomode=1
-or-
https://www.somesite.com/search?searchString=abc&demomode=true
... and I am in no way promoting the first example above. I'm just curious.
I haven't been able to find anything that says if it's a hard-rule in the standard, a convention that people just agreed upon, or if it's more platform/parser specific, and therefore it depends.
Again, I am not encouraging this. Just curious. It came about when looking at some code earlier that contained some pound-defines. You can pound-define something with a value, like #define mode=4 then check for 4 later, but you can also simply pound-define something without giving it a value, such as #define header_x then simply check if that value is defined, not caring what the value is, or even if there is one in the first place.
I have problem with comparison of two variables of "Real" type. One is a result of mathematical operation, stored in a dataset, second one is a value of an edit field in a form, converted by StrToFloat and stored to "Real" variable. The problem is this:
As you can see, the program is trying to tell me, that 121,97 is not equal to 121,97... I have read
this topic, and I am not copletely sure, that it is the same problem. If it was, wouldn't be both the numbers stored in the variables as an exactly same closest representable number, which for 121.97 is 121.96999 99999 99998 86313 16227 83839 70260 62011 71875 ?
Now let's say that they are not stored as the same closest representable number. How do I find how exactly are they stored? When I look in the "CPU" debugging window, I am completely lost. I see the adresses, where those values should be, but nothing even similar to some binary, hexadecimal or whatever representation of the actual number... I admit, that advanced debugging is unknown universe to me...
Edit:
those two values really are slightly different.
OK, I don't need to understand everything. Although I am not dealing with money, there will be maximum 3 decimal places, so "currency" is the way out
BTW: The calculation is:
DATA[i].Meta.UnUsedAmount := DATA[i].AMOUNT - ObjQuery.FieldByName('USED').AsFloat;
In this case it is 3695 - 3573.03
For reasons unknown, you cannot view a float value (single/double or real48) as hexadecimal in the watch list.
However, you can still view the hexadecimal representation by viewing it as a memory dump.
Here's how:
Add the variable to the watch list.
Right click on the watch -> Edit Watch...
View it as memory dump
Now you can compare the two values in the debugger.
Never use floats for monetary amounts
You do know of course that you should not use floats to count money.
You'll get into all sorts of trouble with rounding and comparisons will not work the way you want them too.
If you want to work with money use the currency type instead. It does not have these problems, supports 4 decimal places and can be compared using the = operator with no rounding issues.
In your database you use the money or currency datatype.
How can I write a routine in ESQL/C which will initialize to 0 (zero) all numeric fields (smallint, decimal, etc) and to a space the other fields in a table?
You asked this question on one of the IIUG (International Informix Users Group) mailing lists, and received answers there.
As I mentioned when I responded this morning, you need to think rather carefully about some of the types you don't mention. Zeroing a DATE sets it to 1899-12-31. Zeroing an INTERVAL makes sense (though you don't do it by setting all bytes zero; a similar comment applies to DECIMAL and MONEY and related types). Zeroing a DATETIME generates an invalid value. And BYTE, TEXT, BLOB, CLOB have separate sets of issues.
Setting character fields to a space is easy enough. Setting integer fields of various sorts to zero is also easy enough.
You can look at the code in either Art Kagel's utils2_ak package or in my SQLCMD package, both available from the IIUG Software Archive. They have code that cover many of the situations you're likely to encounter.
If they're not sufficient to help, then you need to show the code you're having problems with, explaining what is happening, what you want to happen, and (if appropriate) any messages your getting that are preventing it happening.
I've recently been receiving a lot of first name only entries in a form. While maybe I should have had 2 separate first and last name fields this always seemed to me a bit much. But I would like to try and get a full name which basically can only be determined by having at least one space.
I came up with this, but I'm wondering if someone has a better and possibly simpler solution?
/([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,}) ([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,})/
This is basically this /([a-zA-Z,.'-]) ([a-zA-Z,.'-])/ plus unicode support.
I'd first make sure that you really do need people to give you a last name. Is that a genuine requirement? If not, I'd skip it because it adds unnecessary complication and barriers to entry. If it really IS a requirement, it probably makes sense to have separate first and last name fields in your UI so that it's explicit.
The fact that you didn't do that to begin with suggests that you might not really need the last name as much as you think you do.
To answer your original question, this expression might give you what you're looking for without the guesswork:
/[\w]+([\s]+[\w]+){1}+/
It checks that the string contains at least 2 words separated by whitespace. Like Tim Pietzcker pointed out, validating the words themselves is prone to error.
In Ruby 1.9, you have access to Unicode properties (\p{L} is a Unicode letter). But trying to validate a name in any way (regex or not) is prone to failure because names are not what you think they are.
Your theory that "if there's a space, there must be a last name there" is incorrect, too - think of first and middle names...
Assume you have a variety of number or int based variables that you want to be initialized to some default value. But using 0 could be problematic because 0 is meaningful and could have side affects.
Are there any conventions around this?
I have been working in Actionscript lately and have a variety of value objects with optional parameters so for most variables I set null but for numbers or ints I can't use null. An example:
package com.website.app.model.vo
{
public class MyValueObject
{
public function MyValueObject (
_id:String=null,
_amount:Number=0,
_isPurchased:Boolean=false
)
{ // Constructor
if( _id != null ) this.id = _id;
if( _amount != 0 ) this.amount = _amount;
if( _isPurchased != false ) this.isPurchased = _isPurchased;
}
public var id:String;
public var amount:Number;
public var isPurchased:Boolean;
}
}
The difficulty is that using 0 in the above code might be problematic if the value is not ever changed from its initial value. It is easy to detect if a variable has a null value. But detecting 0 may not be so easy because 0 might be a legitimate value. I want to set a default value to make the parameter optional but I also want to later detect in my code if the value was changed from its default without hard to debug side affects.
I suppose I could use something like -1 for a value. I was wondering if there are any well known coding conventions for this kind of thing? I suppose it depends on the nature of the variable and the data.
This is first my stack overflow question. Hopefully the gist of my question makes sense.
A lot of debuggers will use 0xdeadbeef for initializing registers. I always get a chuckle when I see that.
But, in all honesty, your question contains its own answer - use a value that your variable is not ever expected to become. It doesn't matter what the value is.
Since you asked in a comment I'll talk a little bit about C and C++. For efficiency reasons local variables and allocated memory are not initialized by default. But debug builds often do this to help catch errors. A common value used is 0xcdcdcdcd which is reasonably unlikely. It has the high bit set and is either a rather large unsigned or rather large negative signed number. As a pointer address it is odd which will cause an alignment exception if used on anything but a char (but not on X86). It has no special meaning as a 32 bit floating point number so it isn't a perfect choice.
Occasionally you'll see a partially aligned value in a variable such as 0xcdcd0000 or 0x0000cdcd. These can be treated as suspcious at the very least.
Sometimes different values will be used depending on the allocation area of library. That gives you a clue where a bad value may have originated (i.e., it itself wasn't initialized but it was copied from an unititialized value).
The ideal value would be invalid no matter what alignment you read from memory and is invalid over all primitive types. It also should look suspicious to a human so even if they do not know the convention they can suspect something is a foot. That's why 0xdeadbeef can be a good choice because the (hex viewing) programmer will recognize that as the work of a human and not random chance. Note also that it is odd and has the high bit set so it has that going for it.
The value -1 is often traditionally used as an "out of range" or "invalid" value to indicate failure or non-initialised data. Then again, that goes right down the pan if -1 is a semantically valid value for the variable...or you're using an unsigned type.
You seem to like null (and for a good reason), so why not just use it throughout?
In ActionScript you can only assign Number.NaN to variables that are typed Number, not int or uint.
That being said, because AS3 does not support named arguments you can always look at the arguments array (it's a built-in array that all functions have, unless you use the ...rest construct). If that array's length is less than the position of your numeric argument you know it wasn't passed in.
I often use a maximum value for this. As you say, zero often is a valid value. Generally max-int, while theoretically valid, is safe to exclude. But not always; be careful.
I like 0xD15EA5ED, it's similar to 0xDEADBEEF but is usually more accurate when debugging.