I have customer details , have lastname column ,
Some of records contain white space in the name front and back ,
i want to do the alphabetical order , but not working properly,
plz chk this screen shot , i cant able to guess wha tis the exact reason ,
space is considered as character, then it will taken into account when you sort the data.
you might want to trim() data before inserting into database.
leonardys is right, you should trim all your inputs before they even go into the database. However, this alone will not solve your problems with people putting punctuation characters and the such in front of their name.
Assuming this database reflects user input, you should do a more thorough input validation. Allowing only alphabetical input (with accents as well if needed) is for example a good solution (given that you expect real names only). Instead of trying to eliminate the unwanted characters, restrict the input to only the allowed ones. Space however, should not be restricted as many valid names contain spaces (e.g. Ann Mary), and therefore you should trim your input after it has been entered.
As for updating the database, that would be tricky. Trimming will only solve the spaces problem. If this is user based data, try asking the ones with illegal characters to update their profile and not let them access the site until they do so. You could excuse it as a database upgrade or some other technical issue.
Hope I helped.
Related
I have this bit of code here which is part of a php login form which take a user's first and last name and a password.
$first_name = SANITIZE(trim(strtolower(#$_POST["f_name"])));
$last_name = SANITIZE(trim(strtolower(#$_POST["l_name"])));
These work fine on desktop for any kind of name but on mobile there seems to be an issue with names that have either a ' or a - in them. So for example Shaquille O'Neal can log in just fine on desktop with his first and last name, but if he tries to log in with mobile something happens with the apostrophe in his name and it says the user doesn't exist. Any ideas why this might happen? Has been tested on both iphone and android phones with the same result.
Try testing this with htmlspecialchars(). Sometimes special characters don’t play nice when entering data into forms or displaying it from a database.
Try getting the character codes and comparing with the database.
Although ASCII only has one code for single quote (not counting back quote) UTF character sets have multiple ones. Similar for '-'. Mobile devices with "smart" keyboards may susbstitute what they think is a more grammatically correct letter.
Previously I wrote this which is wrong:
If this is the case you fix this by specifying that your webserver (at least for the login page) only wants ASCII with the header:
Accept: text/html;charset=US-ASCII, text/plain;charset=US-ASCII
I attempting what I thought would be a simple exercise, but unless I’m missing a trick, it seems anything but simple.
Im attempting to clean up user input into a form before saving it. The particular problem I have is with hyphenated town names. For example, take Bourton-on-the-Water. Assume the user has Caps lock on or puts spaces next to the hyphens of any other screw up that might come to mind. How do I, within reason, turn it into what it’s meant to be?
You can use trim() to remove whitespace (or other characters) from the beginning and end of a string. You can also use explode() to break strings into parts by a specified character and then recreate your string as you like.
I think the only way you can really accomplish this is by improving the way the user inputs their data.
For example use a postcode lookup system that enters an address based on what they type.
Or have a autocomplete from a predefined list of towns (similar to how Facebook shows towns).
To consider every possible permutation of Bourton On The Water / Bourton-On-The-Water etc... is pretty much impossible.
I am using a 3rd party "shopping cart" program (CartWeaver) that uses a MySQL database. The products in my store have primary and secondary categories, the latter of which where my issue lies.
I am using date ranges (e.g. 1930-1939, 1940-1949, etc), however when I view the ranges on the product search page, the first number sequence is displaying incorrectly. For example, the date range 1930-1939 is displaying as 3860-1930, and 1940-1949 is displaying as 3880-1949 (you can see the issue at www.silverscreencollectibles.com/searchpage.php).
I have tried multiple variables to try to get around this, all to no available. Here is what I've tried: Starting the sequence with an alpha character, starting it with a special character, putting the range in single as well as double quotes, putting a space between the sequences, replacing the dash with the alpha "to". I have also deleted and recreated the subcategories, and nothing I have tried changes the result. The entry for "2000-Present" also displays incorrectly (as 4000-Present).
I'm just a dumb user, not a programmer, so any responses that anyone is kind enough to offer will need to be "dumbed down". The application support group wants me to either send them my entire database, or allow them to directly access my site...and neither option appeals to me, from a security standpoint. I thought I would throw the issue out to the StackOverFlow community to see if anyone has seen this sort of issue before, and may be able to point me in the right direction to address the issue. Thank you so much for your time.
hi I have a problem on formatted amounts.
On my input form, users can add and edit a formatted amount. Since this is a multi-language program, users can specify their own format, so there isn't a fixed pattern.
Examples:
250.000
250,000
250.000,00
250,000.00
Sadly, I have to "un-format" them, before store them into the database or MySQL will understand my number as floats and viceversa.
How can I overcome this? Any ideas?
You can either go on the side of allowing the users to enter what they want, in which case you'll ahve to sanitize (and translate in the case of the decimal symbol), as you guess here. Or you can restrict what they enter and force them to leave out thousand separators.
You will have to check the localization of the client and accordingly parse the data that way. coz 2,500.00 = 2.500,00. It depends on the location.
Do not let the users enter ",".
Have a separate box to let users enter things after the decimal.
Let the box be pre-filled with 0.00. Telling the user this is the format.
Taking input from user in a proper format is a good way, put a viewable format message displayed near the input area.
You should validate the input data when user perform submit.
You can validate using regular expression in both JavaScript and in your server-side programming language before storing the user-input directly into the database.
ok, finally I made it, so I'll share my solution
First of all, I used Mootools to format the input field while to user is typing.
Then I moved server side.
Format options are saved inside my application, so this is the code
//get decimal separator from saved params
$dec = $params->get('decimalSep', '.');
//remove any char that's not a number or decimal separator
//(i don't care about thousands sep)
$regex = '#[^0-9-'.preg_quote($dec).']#';
$normalized = preg_replace($regex, '', $price);
$normalized = str_replace($dec, '.', $normalized);
Basically I get rid of everything except the decimal separator, then I replace it with the standard one (.).
It works like a charm.
When I display contents from the database, I get this:
��Some will have a job. Others will want one. They are my people, they are my clients and they are being denied their rights.
This text had been entered by the user via textarea with tinyMCE. How can I replace special characters (using preg_replace()) from the sentence to ' ' except for the characters: <>?
This article is totally worth a read. Dealing with UTF-8 characters is something that we all go through at some point. The trick seems to be to catch them before they go into the database or to fix the database so that when they're going in they aren't broken. Once they're in there though it's slightly more difficult.
As Chuck mentioned above, it is the database problem. Unless you only wish to display non-Unicode, ie Latin characters, then yes, preg_replace is the way to go. You will need to know the character sets well enough to filter out what you don't want.
But if you just want everything to display nicely, ie no garbage characters, then change the corresponding parts of the db to accept utf-8.
e.g. If you are using mySQL, try changing the field and table encoding to be able to accept UTF-8. The default is latin1_general_ci - try changing it to utf8_general_ci. Hope that explains my point.