Use HTML entities. No idea about Perl but in PHP there is functions to encode and decode them

PHP's htmlentities() did this:

$foo = 'And then they said, "howdy!"';
echo htmlentities($foo);

# And then they said, "howdy!"

So simply converting " to "

But that gives me the same issue: Perl wouldn't know whether " is intended to be literal or should be decoded. Which, admittedly, there are very few times where $foo should contain a literal " so it's a fair replacement. But if I'm going to do that then I'd be better off using a near-impossible delimiter like ::phranqueistheman::.

Or, more practically, a diacritic like ï (if the forum doesn't show that, it's an i with 2 dots over it).

Is some part of the system constrained to a one-byte encoding (ASCII, Win1252, whatever)? If not, the civilized solution would be to use “curly quotes” ... which, come to think of it, do exist in Windows 1252, and hence de facto in most-though-not-all Latin-1 environments. Or, depending on language, some form of «guillemets».

Is some part of the system constrained to a one-byte encoding (ASCII, Win1252, whatever)?

Yes and no :-/

For 20 some years I've had the same system in place for people to enter their profile information, and I have max lengths of 50 characters on most of it. And if they modify their profile, the system reads MySQL and plugs the values into the <input> tag.

I recently had an issue reported by someone (a generic, "it doesn't work"), and the ONLY reason I can see for it is that their password is 50 characters and has 2 double-quotes in it. So whenever the value is being plugged into an <input> tag and then processed, it's not going to match what's in MySQL.

In that particular case I can't convert " to &quot; because they're already at the maximum size. And changing the <input> attribute to wrap with ' or ` doesn't solve the problem because, of course, I have users with those in the username / password, too. So that would just be kicking the problem down the road a little, so to speak.

My rebuild changes the password to be stored in MD5, which would (in theory, I guess) solve this issue, but it's not ready to go live yet. And it doesn't fix the username, anyway.

In lieu of a better alternative, I'm thinking that the only option is to leave the " in MySQL, then convert it in PHP to a curly quote or something, then when processing convert that curly back to a ". The ONLY issue I can think of for that is when the user sees it in the <input> value then it might be a tad confusing.

A long-term solution would probably involve barring certain characters (I can conceive of angle brackets < > or, heck, backslash \ also causing trouble) at the outset.

I THINK that I do now. I modified everything awhile back to block injection attempts, and I'm pretty sure that I blocked double quotes and angles at the time. But this particular user's account dates back to 2012, so he got in long before I had any idea about that.

Out of about 1 million accounts, I only have 30 with a double quote. So this isn't a major problem or anything, just something I'm trying to figure out how to fix without wasting TOO much time on it :-/

You should test it's what you expect instead of trying to block things. e.g. if you expect only alphanumeric data test that it's only alphanumeric.

Asking 30 or so to update (change!) their password using new criteria is a whole lot easier than trying to covert stuff that makes more problems than it solves.

Besides, ALL users should change their passwords periodically, and if they don't, YOU SHOULD REMIND THEM TO DO SO!