Problems with removing '£' from a money string.

[Paul-D]

Hi. I have 2 text boxes where I add money in to an account and money out. This works. But if I accidently put a £ into the text box which is not needed, I get an error. I decided to do a string replace but  get an error if I put the £ symbol in. Surley this should be simple? It works fine when I leave the '£' out.

	$Comment_Name = $_SESSION['COMMENT_NAME'];
	$_SESSION['DE_MyReason'] = $_POST['Reason']; // Keep the default regardless
	$_SESSION['DE_Money_In'] = $_POST['MoneyIn'];
	$_SESSION['DE_Money_In'] = str_replace ("£","",$_SESSION['DE_Money_In']);
	$_SESSION['DE_Money_Out'] = $_POST['MoneyOut'];
	$_SESSION['DE_Money_Out'] = str_replace ("£","",$_SESSION['DE_Money_Out']);
	$_SESSION["DE_DD_Entry"] = $_POST['DD_Entry'];
	$_SESSION["DE_MM_Entry"] = $_POST['MM_Entry'];
  

 

Edited November 23, 2025 by Paul-D

[requinix]

If the input is supposed to be numbers then help yourself by using an input with type=number so the user can't accidentally type non-digits.

Also, it would help to give a visual indication of the currency being implied - typically this looks like a little £ symbol to the left of the input area.

 

 

The actual problem you're having is 99% likely to be character encoding. There are multiple possible byte encodings of the character "£", and PHP only cares about bytes. So if the £ coming from the form is encoded one way and the £ written in your code is encoded another way, the substitution doesn't happen.
Make sure you're using UTF-8 encoding (or some other specific encoding) for absolutely everything - your webpages, your database, your code files, everything. Then you won't have problems with bytes not matching up.

[Paul-D]

Yes the form does have a pound sign to the left. It's just me copying and pasting that has happend. However if there is a way of escaping hitting a pound sign then how do I do that without some kind of javascript?

And yes there are other dorm of using the £.  I have this in the code.

$Comment = str_replace ( "£", "£", $_SESSION["DE_Comment"] ) ;

 

 

Edited November 23, 2025 by Paul-D

[requinix]

5 minutes ago, Paul-D said:

However if there is a way of escaping hitting a pound sign then how do I do that without some kind of javascript?

Why even consider Javascript when all you have to do is use a number input?

[Psycho]

I agree 100% with @requinix about setting the type of the field to a numeric input. However, I am a belt and suspenders type of programmer. UI constraints are great for helping the user to avoid common data entry errors, but I believe all such validations should have server-side controls (what if the user POSTed a form outside the UI?).

The problem is you are making the problem harder than it needs to be. Why do you only care about '£' character? Just because you are accidentally copy/pasting that character doesn't mean you wouldn't have issues with other characters. So, rather than trying to exclude only that specific, arbitrary character - you should remove all characters that would create an invalid number. Or, conversely, you could detect that the value is not a valid number and return the user back to the input page showing an appropriate error. The choice would be a business decision.

Taking the first approach, here is one way to do it:

function forceToNumber($value)
{
    //Remove everything that is not a digit or decimal point
    $value = preg_replace('/[^\d.]/', '', $value);
    //Check if there is more than one decimal point
    if(substr_count($value, '.') > 1)
    {
        //Remove everything from the 2nd decimal
        $value = substr($value, 0, strpos($value, '.', strpos($value, '.')+1));
    }
    //Retur4n value as a float
    return (float) $value;
}

I'm sure there is a more elegant way to deal with possible multiple decimal points (possibly with a single regex), but I've not worked with Regex for quite a while.

[requinix]

55 minutes ago, Psycho said:

I'm sure there is a more elegant way to deal with possible multiple decimal points (possibly with a single regex), but I've not worked with Regex for quite a while.

It's a little painful, but not too complicated if you treat the input as being one of two things: a number starting with a ".", or a number starting with a digit and optionally containing a fractional portion.

^(\.\d+|\d+(\.\d*)?)

The separation because there has to be at least one digit in there somewhere, but it could be before the decimal or after.

If you run that through preg_match, $1 (and $0 for that matter) is the leading numeric portion of the string it matched. Then you can also do a quick strlen check to see if anything got lost.

However, floatval/cast to float will implicitly drop any trailing non-numeric portion as it is, so there's no need to try to remove it manually. Minor downside that exponential numbers, like "1.23e45" are acceptable, but IMO it doesn't matter enough to prohibit it in the backend if someone the frontend allowed it.

[gizmola]

This comes down to some basic advice, particularly where databases are concerned (assuming you are using a sql database):

• Always use the right datatype.  Money is a particular problem for floats, so depending on the database, you can either hack the use of an integer or if there's a datatype like the mysql DECIMAL type, something already designed to handle money without the potential for rounding errors.
• This also should tell you, that to support flexibility, your database should also include an indicator of the "type" of currency.  If you implement a type table, your application will be able to know the difference between an amount that is stored in pounds or euros, or US dollars.  
• Once you realize that floating point datatypes aren't good for handling calculations involving money, you then want to look into possible approaches.    Even if you are using a DECIMAL field in the database, that doesn't insulate you from rounding errors if you read the values into PHP Floats and start doing calculations with those values.

This is a few years old, but I think it's a good starting point for considering how your code works now, and potential ways to address currency and calculations that involve currency.

In general, the display of data formatted in a way that is standard for an end user is referred to as "locale" and when you setup a personal workstation or server, you are asked questions that then configure the OS, typically using locale specific standards.  So the presentation of a "currency" number and the actual currency that number represents should be a presentation issue.  Unless you have a system that is actually storing values in multiple currencies (which would then add an entire extra layer of complexity that's probably beyond the scope of what you are currently working on), you should not be accepting strings that may or may not include a currency character, and then trying to manipulate them.  That is all presentation logic, that should be separate, and essentially invisible to the inner workings of your application.  

Don't accept character fields in your form, and this problem goes away.  If you want to add some intrinsic UI functionality that allows you to cut/paste a value, handle that in javascript and just strip out any non numeric characters.

 

[gizmola]

On 12/2/2025 at 7:45 AM, Psycho said:

I agree 100% with @requinix about setting the type of the field to a numeric input. However, I am a belt and suspenders type of programmer. UI constraints are great for helping the user to avoid common data entry errors, but I believe all such validations should have server-side controls (what if the user POSTed a form outside the UI?).

Right.  It's an annoying issue with web development, but user input can never be trusted, and input validation must always be placed in both places.

My approach has long been to start with the backend and insure that you are validating raw submission.  This is where tools like postman are helpful.    Once the backend is locked down, you can then move to validation in the HTML and javascript.  You can get by without validation or HTML5 forms in the front end, but you can't get by without the backend validation.