There is probably a much more elegant way to say the title, but that's the best I could come up with because frankly I am feeling silly that I don't know the answer and even have to ask but that's how you learn, so no shame necessary.
I have stored dataURIs such as :
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAE5klEQVR4nO1ZS0hjVxg+9xEJVFAnCzcuurVC3XfTWpqMMTGJbrSFQumAxhERFdE4YK4Bo5kY8zAvo0434nKghW46pXRhH5sKBXHXdikyDjGK0ETj7f/f5KY3N68bySSh9YPP/5x7Xv9/znfOubkS8oAH/L9B1XtAnufVYNTZbBqYpCgqVaKuCgySxiwwBXVvpHXYt+hrKajn5+fjNzc3hGEYolarT1ZXV0NLS0t74FwSK4DjLQ6H48nCwsJkKpXqSafTQl2v19sKxQ0PIAcM4vr6+r2rq6uQzWZ7ur+//8nd3R1ZXFz8Hp73YDnLsoSmaQwKm/DyPuj6u03+drvd7Z2dnf1dXV2fazSaX2DmSSKR6Dk+Pn55cnLy8vLysgeftbW1/Qz1Puvo6ND5fL53iGz2EXXfA3Kgzp1O59jZ2VkQZxmJzkNgT+12+w6kb8u1b3gACAwCJPRjPB7/APM48y6X68NKziMaIaEC4MnS2toaQr0jIR1U4jyioZtYCtiw57hZEbe3t+dK2zXFCiC6u7uP0eIeWFlZ+Ulpu6ZZgZGRkcTh4WHV7ZpmBUiRM14JGGnm4OCAHx4e5pBDaIeGuCGgBa3FwlmAZrRmM2c2WzgTWpOJM5nM3CDawUHBGsEajUbBGsAaDECjgRswAAfQDnD6AaAerZ7r1+u5346Onp2/fi348ceffz3T6rSc7nE/8DGn1ek4nS5jtVod9+rVdyuiz3kSQv2Njo4qnyYxQ4lpXpop3qbog8zDmZkZwQerdbzk+F6vLy9fEAACr/O8cSQD8lKvs/VzSfxDSQLgC5pncnx5vcAplOtaCpWKlYyfQd4euJcICSk62D16yU1guftVPhZbrFSs07//phae5fDtpx3KKpabEVlZUQmJuKvJzFaPcsPKJZQfgCyRfhsBlNK/uF8q6FGRhETUfgVq0GGzSogvMn6pelIUSCjD7HFarwCqOMbkQdZXQhXOf2V9lJWQmMqcw/VaAekwFTexLC+TEC+KUcjXOoDip091g1QlodrcsMqhZBMrkpBY5dcnj/IqU8J1T7LvO7lWxUx+eUnty6+lyqgsIQkoaQk6gY5nH2a+HuT3WvWC3WOF5atEy0qFXlmGFsjkmPmxzTJMljRRscy/eUgzbMYWMNtWVUAog7dLlYQiVLLn+eUV3kb3Xrwgu3t7And2d0lsBxkj27FtEt1GRkkkGiXhCDJCQuEwCYbCJBQKkWAwRLa2gsAtEghsEX8gQHwBP/H5/cTr9xGvz0c2vV7i8W6SjU2wHrAeD3FveIS0OMPP3Rtk3fWcrK27yNraOnECV51rQGfBvmyK70IIcJydmJgQvrxFIhGWoqi0knbN9Jv4XmiaAGZnZ98X09PT071K2zVNACCh9qxF0660XdPsgcnJyQD8Fp7CNMMwgXA4PN1onxRjeXlZY7Va42NjYzwS03Nzc4p+fzZ8BWw226NEIvFDOp3upbI3I34VoWn695aWlr5AIBAv177uewA0TjscDs3U1FQf8MuLi4sjdF5whqZnkRgIBNGbTCaPYDW+GB8f/6hUf434Nkqdnp6ei//MEP+hAbp3wGUofLWC+6ANjB3K3gV+hc9AWiQWixUopqGnEDoOrxnfAD+GTWuHPI+MRqMc2D7g1xX7qIejUqCEJOMKL1/odL39eMAD/iv4B7EvTT8yUT9VAAAAAElFTkSuQmCC
in a variable by simply doing: $some_var = "INSERT_ABOVE"; and has usually worked fine, but I am finding in a piece of code I am working on right now that the code breaks anytime one of the variable=>datauri scheme I showed above is used but deleting that line, fixes the code.
So I am not sure ?WHY? this particular datauri is breaking the code and shouldn't anything inside "" QUOTATIONS be treated as a literal string? Is there a best practice or should I say recommended way of storing datauris as variables to be used through the code, so it doesn't break?
Any thoughts and/or suggestions would be greatly appreciated, TIA.
PS. This wasn't just due to the backslash at the end, it was also that the string by itself wasn't being respected, now it is storing into variable like this, thanks. Since the title most accurately describes what was being achieved, I think its more appropriate.
Use Heredoc string quoting. It's another way to represent strings in PHP. It can eliminate your problem of ending quote getting escaped by string data.
$str = <<<EOD
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAYAAABXAvmHAAAE5klEQVR4nO1ZS0hjVxg+9xEJVFAnCzcuurVC3XfTWpqMMTGJbrSFQumAxhERFdE4YK4Bo5kY8zAvo0434nKghW46pXRhH5sKBXHXdikyDjGK0ETj7f/f5KY3N68bySSh9YPP/5x7Xv9/znfOubkS8oAH/L9B1XtAnufVYNTZbBqYpCgqVaKuCgySxiwwBXVvpHXYt+hrKajn5+fjNzc3hGEYolarT1ZXV0NLS0t74FwSK4DjLQ6H48nCwsJkKpXqSafTQl2v19sKxQ0PIAcM4vr6+r2rq6uQzWZ7ur+//8nd3R1ZXFz8Hp73YDnLsoSmaQwKm/DyPuj6u03+drvd7Z2dnf1dXV2fazSaX2DmSSKR6Dk+Pn55cnLy8vLysgeftbW1/Qz1Puvo6ND5fL53iGz2EXXfA3Kgzp1O59jZ2VkQZxmJzkNgT+12+w6kb8u1b3gACAwCJPRjPB7/APM48y6X68NKziMaIaEC4MnS2toaQr0jIR1U4jyioZtYCtiw57hZEbe3t+dK2zXFCiC6u7uP0eIeWFlZ+Ulpu6ZZgZGRkcTh4WHV7ZpmBUiRM14JGGnm4OCAHx4e5pBDaIeGuCGgBa3FwlmAZrRmM2c2WzgTWpOJM5nM3CDawUHBGsEajUbBGsAaDECjgRswAAfQDnD6AaAerZ7r1+u5346Onp2/fi348ceffz3T6rSc7nE/8DGn1ek4nS5jtVod9+rVdyuiz3kSQv2Njo4qnyYxQ4lpXpop3qbog8zDmZkZwQerdbzk+F6vLy9fEAACr/O8cSQD8lKvs/VzSfxDSQLgC5pncnx5vcAplOtaCpWKlYyfQd4euJcICSk62D16yU1guftVPhZbrFSs07//phae5fDtpx3KKpabEVlZUQmJuKvJzFaPcsPKJZQfgCyRfhsBlNK/uF8q6FGRhETUfgVq0GGzSogvMn6pelIUSCjD7HFarwCqOMbkQdZXQhXOf2V9lJWQmMqcw/VaAekwFTexLC+TEC+KUcjXOoDip091g1QlodrcsMqhZBMrkpBY5dcnj/IqU8J1T7LvO7lWxUx+eUnty6+lyqgsIQkoaQk6gY5nH2a+HuT3WvWC3WOF5atEy0qFXlmGFsjkmPmxzTJMljRRscy/eUgzbMYWMNtWVUAog7dLlYQiVLLn+eUV3kb3Xrwgu3t7And2d0lsBxkj27FtEt1GRkkkGiXhCDJCQuEwCYbCJBQKkWAwRLa2gsAtEghsEX8gQHwBP/H5/cTr9xGvz0c2vV7i8W6SjU2wHrAeD3FveIS0OMPP3Rtk3fWcrK27yNraOnECV51rQGfBvmyK70IIcJydmJgQvrxFIhGWoqi0knbN9Jv4XmiaAGZnZ98X09PT071K2zVNACCh9qxF0660XdPsgcnJyQD8Fp7CNMMwgXA4PN1onxRjeXlZY7Va42NjYzwS03Nzc4p+fzZ8BWw226NEIvFDOp3upbI3I34VoWn695aWlr5AIBAv177uewA0TjscDs3U1FQf8MuLi4sjdF5whqZnkRgIBNGbTCaPYDW+GB8f/6hUf434Nkqdnp6ei//MEP+hAbp3wGUofLWC+6ANjB3K3gV+hc9AWiQWixUopqGnEDoOrxnfAD+GTWuHPI+MRqMc2D7g1xX7qIejUqCEJOMKL1/odL39eMAD/iv4B7EvTT8yUT9VAAAAAElFTkSuQmCC\
EOD;
echo $str;
Related
I am trying to convert a single quote into html specialchars.. but its not working. I am not sure what I am doing wrong here. Below is how I am using the function
echo htmlspecialchars("Housemade Mac N' Cheese",ENT_QUOTES);
Any help would be really appreciated!
The following comes from my own experiment.
Try this, it will replace all single quote by ߴ, which is an Unicode character. nko high tone apostrophe (U+07F4). Php/js will treat it as a regular character, so no headaches here.
Of course the content of $string is going to be altered, this is not the perfect solution but a workaround.
echo htmlspecialchars(preg_replace("/'/","ߴ",$string),ENT_QUOTES);
To understand it better, in your showcase, the following should be ok, but what if the string will change to something you don't know yet. Will it contains single quotes, on, two, three, where? This is hard stuff! Look simple but it is actually a very complex case!
echo htmlspecialchars("Housemade Mac N\' Cheese",ENT_QUOTES);
Philosophical annexe, this part can be skipped...
The most complex things are hiding in the simplest.
Personal reflexion 💡
It's a pretty silly question, sorry. There is a big and rather complex system that has a bug and I managed to track it down to this piece
return str_replace('%2F', '/', rawurlencode(str_replace('%20', ' ', $key)));
There is a comment explaining why slashes are replaced - to preserve path structure, e.g. encoded1/encoded2/etc. However there is no explanation whatsoever why %20 is replaced with space and that part is the direct cause of a bug. I am tempted to just remove str_replace() but it looks like it was placed there for some reason and I have a feeling that I'll break something else by doing this. Has anyone encountered anything similar? Perhaps it's a dirty fix for some PHP bug? Any guesses and insights are highly appreciated!
Doing so would prevent %20 (encoded space) from being encoded to %2F20. However, it only serves to prevent double escaped spaces; other special characters would still get double encoded.
This is a sign of bad code; strings that are passed into this function shouldn't be allowed to have encoded characters in the first place.
I would recommend creating unit tests that cover all referencing code and then refactor this function to remove the str_replace() to make sure it doesn't break the tests.
First thing that jumps to mind is as a mitigation technique against double encoding.
Not that I would recommend doing such a thing this way, as it would get real messy real quickly (and one would already wonder why only that entity, perhaps 'they' never experienced issues with any others... yet).
It could be the result of a misunderstanding of rawurlencode() vs urlencode()
urlencode() replaces spaces with + signs
If the original author thought that rawurlencode() did the same thing, they would be attempting to pre-encode the spaces so they don't get turned into +s
I have an issue here, and I'm looking for experienced programmers to tell me which is the preferred solution.
I have values being returned that are surrounded in quotes. "TOTAL" and "VALUE" being two examples. These should not be confused with TOTAL and VALUE -- the string is actually surrounded by double quotes.
What I noticed is that the switch statement below doesn't work because it's looking for TOTAL not "TOTAL":
switch ($statTypeName) {
case "TOTAL":
echo "<br>TOTAL";
break;
case "VALUE":
echo "<br>VALUE";
break;
}
To get this working, I had to put a single quote around the case -- '"TOTAL"'.
In my text editor (Notepad++), it is difficult to see the single quote around the double quotes.
I know this isn't a common issue, but what would be the "professional" way of solving this? The way I did it, or should I be extracting the string from the quoted string and do away with the double quotes altogether..?
Thanks!
case "\"TOTAL\"":
Escape the inner double quotes. It will work the same way and might be a little more visible to the reader
What you're running into is indeed common, and you can go about it a couple different ways. There's nothing wrong with the way you're doing it, or #KyleBanks solution (escaping the double quotes). Given php provides single and double quote string definitions, I prefer the first. But its up to your preference, or your dev team.
As far as extracting the substring within the string quotes.. it depends on what they're there for in the first place.
I would suggest using a better font in Notepad++. I personally use Consolas however here you can find heaps of other good options:
Recommended Fonts for Programming?
Other then changing font escaping quotes as was suggested is another alternative:
case "\"TOTAL\"":
You can also try to strip quotes:
switch (substr($statTypeName, 1, -1)) {...}
but i consider it as a more dangerous approach unless you start using more complicated code to strip them with checks and everything in which case it clearly becomes an overkill.
Except if your given code is not part of some kind of StatType class and is dealing internally with the representation of stat type states my answer might be missing the point a bit, but in any case here it is.
In fact you are doing something wrong here and what you are asking is to find a way to workaround the essential problem you are having. Instead, you should fix the essential problem.
Essential problem is that you are missing one layer of abstraction which will sit between the way you are representing your statType and the way you are using it.
So, your program should not care if you call your statType:
"TOTAL" or '"TOTAL"' or "Total" or "total"
What you need to care is that your statType is in certain state in one moment of program execution. How that representation of the state is implemented ( a string with quotes or a number) is detail of implementation and your switch statement should not care about it.
What happens if you decide to change your statTypeName to be without quotes for example. Than you'll have to go to every line of code that depended on it having quotes and to change it. If you would hide the implementation details in some way you would not need to change more than one line of code.
Maybe one approach to setting abstraction around statTypes? (simplified for clarity)
class StatType
{
const TOTAL = 0;
const VALUE = 1;
// etc.
}
switch ($statType->type()) {
case StatType::TOTAL:
echo "<br>TOTAL";
break;
case StatType::VALUE:
echo "<br>VALUE";
break;
}
I'm looking for a regex that will scan a document to match a function call, and return the value of the first parameter (a string literal) only.
The function call could look like any of the following:
MyFunction("MyStringArg");
MyFunction("MyStringArg", true);
MyFunction("MyStringArg", true, true);
I'm currently using:
$pattern = '/Use\s*\(\s*"(.*?)\"\s*\)\s*;/';
This pattern will only match the first form, however.
Thanks in advance for your help!
Update
I was able to solve my problem with:
$pattern = '/Use\s*\(\s*"(.*?)\"/';
Thanks Justin!
~Scott
If you only care about the value of the first parameter, you can just chop off the end of the regex:
$pattern = '/Use\s*\(\s*"(.*?)\"/';
However, you should understand that this (or any pure-regex solution for this problem) will not be perfect, and there will be some possible cases it handles incorrectly. In this case, you'll get false positives, and escaped quotes (\") will break it.
You can ignore escaped quotes by complicating it a bit:
$pattern = '/Use\s*\(\s*"(.*?)(?!<(?:\\\\)*\\)\"/';
This ignores " characters inside the quoted string if they have an odd number of backslashes in front of them.
However, the false-postives issue can't be helped without introducing false-negatives, and vice versa. This is because PHP is an irregular language, so it can't be parsed with "pure" regex, and even modern regex engines that allow recursion are going to need some pretty complex code to do a really thorough job at this.
All I'm saying is, if you're planning a one-off job to quickly scrape through some PHP you wrote yourself, regex is probably fine. If you're looking for something robust and open-ended that will do this on arbitrary PHP code, you need some kind of reflection or PHP parser.
This might be slightly simpler, though will only work if you have double quotes and not single quotes:
$pattern = /Use\s*[^\"]*\"([^\"]*)\"/
I have a form into which I entered a newline character which looked correct when I entered it, but when the data is now pulled from the database, instead of the white space, I get the \n\r string showing up.
I try to do this:
$hike_description = nl2br($hike_description);
But it doesn't work. Does anyone know how this can be fixed? I am using PHP.
And here is the page where this is happening. See the description section of the page:
http://www.comehike.com/hikes/scheduled_hike.php?hike_id=130
Thanks,
Alex
Does anyone know how this can be fixed?
Sure.
Your code doing unnecessary escaping, most likely before adding text to the database.
So, instead of replacing it back, you have to find that harmful code and get rid of it.
This means, you have probably plain text '\n\r' strings in the db.
Try to sanitize db output before display:
$sanitized_text = preg_replace('/\\[rn]/','', $text_from_db);
(just a guess).
Addendum:
Of course, as Col. Shrapnel pointed out, there's something fundamentally wrong
with the contents of the database (or, it is used this way by convention and you don't know that).
For now, you have fixed a symptom partially
but it would be much better to look for the reason for these escaped characters
being in the database at all.
Regards
rbo
You can use str_replace to clean up the input.
$hike_description = nl2br(str_replace("\r\n", "\n", $hike_description));
$hike_description = str_replace(array('\n','\r'),'',$hike_description);
You may want to read up on the differences between the single quote and double quote in PHP as well: http://php.net/manual/en/language.types.string.php