When I insert a link through a form with PHP, my database puts backslashes before the links. I use tinyMCE.
Example, this is how it looks in the database:
(14, 'MULTIMÉDIA', 'multimdia', '<h2><strong>RISING HARMONY </strong></h2>\r\n<p><strong>ITT A ZENE VILÁGA URALKODIK.</strong></p>\r\n<p><strong>KEDVENCÉT ÖN IS MEGOSZTHATJA </strong><strong>AZ ALÁBBI CÍMEN:</strong></p>\r\n<p><strong>personicum#gmail.com </strong></p>', '<p><iframe src=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"/www.youtube.com/embed/1ov6USLXwGA\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" width=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"270\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" height=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"152\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" frameborder=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"0\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" allowfullscreen=\\"allowfullscreen\\"></iframe> <iframe src=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"/www.youtube.com/embed/bnv6dPQ5f88\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" width=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"263\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" height=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"150\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" frameborder=\\"\\\\"\\\\\\\\"\\\\\\\\\\\\\\\\"0\\\\\\\\\\\\\\\\"\\\\\\\\"\\\\"\\" allowfullscreen=\\"allowfullscreen\\"> )
This should be a youtube video, inserted through tinyMCE. It does the same thing to images and any kind of links. So, my question is, why do these things appear?
Here is the table:
CREATE TABLE IF NOT EXISTS `blog_posts_seo` (
`postID` int(11) unsigned NOT NULL AUTO_INCREMENT,
`postTitle` varchar(255) DEFAULT NULL,
`postSlug` varchar(255) DEFAULT NULL,
`postDesc` text,
`postCont` text,
`postDate` datetime DEFAULT NULL,
PRIMARY KEY (`postID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=25 ;
With another table it worked fine, so it means that the problem isn't with my php, but I will copy it here if it is needed. What is this problem caused by? On the website there is a 404 error instead of the video.
If I insert them manually through MySQL, then everything is fine, but if I insert it through the form it looks like this. Also, if I use the same php with another database, it works fine. It's a paradox and I am not experienced. I couldn't find the problem.
Also, locally it works fine, it shows like this:
<p><iframe src="//www.youtube.com/embed/Lcu8SdcsYnY" width="425" height="350"></iframe></p>
Thank you, in advance.
You run addslashes(), or other escaping functions multiple times over your input. You might have also magic quotes on. You should keep your strings in raw, and escape them only right before inserting into database. Best by using PDO's bound parameters.
Related
I'm trying to convert a database to use utf8mb4 instead of utf8. Everything is going fine except one table:
CREATE TABLE `search_terms` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`search_term` varchar(128) NOT NULL,
`time_added` timestamp NULL DEFAULT NULL,
`count` int(10) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `search_term` (`search_term`),
KEY `search_term_count` (`count`)
) ENGINE=InnoDB AUTO_INCREMENT=198981 DEFAULT CHARSET=utf8;
Basically all it does is save an entry every time somebody searches something in a form so we can track the number of searches, very simple.
There's a unique index on search_term because we want to only have one row per search term and instead increment the count value.
However when converting to utf8mb4 I am getting duplicate entry errors. Here is the command I am running:
ALTER TABLE `search_terms` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Looking in the database I can see various examples like this:
ｆｍ２０１２
ｆｍ2012
fm2012
In it's current utf8 character set, these are all being treated as unique and exist within the database without ever having an issue with the unique index on search_term.
But when converting to utf8mb4 they are now being considered equal and throwing an error due to that index.
I can figure out how to merge these together easily enough, but i'm concerned this may be a symptom of a greater underlying problem. I'm not really sure how this has happened or what the consequences may be, so my questions are a bit vague:
Why is utf8mb4 treating these differently to utf8?
What are the possible consequences?
Is there someway I can do a conversion so things like "ｆｍ２０１２" never appear in my database and I only have "fm2012" (I am also using Laravel 5.1)
Your problem is the change of collation: you're using general_ci and you're converting to unicode_ci: general_ci is quite a simple collation that doesn't know much about unicode, but unicode_ci does.
The first "ｆ" in your example string is a "Fullwidth Latin Small Letter F" (U+FF46) which is considered equal to "Latin Small Letter F" (U+0066) by unicode_ci but not by general_ci.
Normally it's recommended to use unicode_ci exactly because of its unicode-awareness but you could convert to utf8mb4_general_ci to prevent this problem.
To prevent this problem in the future, you should normalize your input before saving it in the DB. Normally you'd use NFC, but your case seems to call for NFKC. This should bring all "equivalent" strings to the same form.
Despite what was said previously it is not about general_ci being more simplistic than unicode_ci. Yes, it can be true, but the issue is that you need to keep it matching to the sub-type you have.
For example, my database is utf8_bin. I cannot convert to utf8mb4_unicode_ci nor to utf8mb4_general_ci. These commands will throw an error of a duplicate key being found. However the correct collation utf8mb4_bin completes without issues.
I created a table in database named file
CREATE TABLE `file` (
`name` varchar(255) NOT NULL,
`type` varchar(255) NULL,
`content` varchar(255) NULL,
PRIMARY KEY (`name`)
)ENGINE=MyISAM;
but I want when I get record of a specific file type, open the content of this file
for example:
name: test type: php content:<?php echo "hello world" ?>
and append it as hello world in a page
thanks :)
Assuming I understand the question correctly and your want to run whatever code your PHP content has:
You can basically do this using two methods, but I wouldn't recommend either:
1) Use eval(). This is a very simple solution but also a very bad idea, and it won't work on many shared servers.
http://il1.php.net/manual/en/function.eval.php
2) Write the content field to an actual PHP file (if it's not in a file already) and get the contents of that file using file_get_contents() or similar. You need to put the URL of the file so you only get the output, and this also won't work on some shared servers.
http://il1.php.net/manual/en/function.file-get-contents.php
I have a shape file, and I want to show it on the web by using leaflet (http://leaflet.cloudmade.com/). Since leaflet only support geoJSON, I should change the shp file into geoJSON. It is easy since I can use "save as" capability in Quantum-GIS.
Although I can use geojson as database (by reading, edit and writing the file programmatically), I think it is better to use the "real" database. My-SQL is the most popular one, and it support spatial data, so I decide to use MySQL.
The scenario is:
Change shp into MySQL (I use ogr2ogr and just simply run this command: ogr2ogr -f "MySQL" MySQL:"geo,user=root,host=localhost,password=toor" -lco engine=MYISAM airports.shp)
Fetch MySQL database into geojson <-- here is the problem
Using ajax to get the geojson and change the layout <-- this should be easy, I'm good with JQuery
There is a column in My MySQL table which its type is "GEOMETRY", Look the table definition below:
CREATE TABLE IF NOT EXISTS `airports` (
`OGR_FID` int(11) NOT NULL AUTO_INCREMENT,
`SHAPE` geometry NOT NULL,
`cat` decimal(10,0) DEFAULT NULL,
`na3` varchar(80) DEFAULT NULL,
`elev` double(32,3) DEFAULT NULL,
`f_code` varchar(80) DEFAULT NULL,
`iko` varchar(80) DEFAULT NULL,
`name` varchar(80) DEFAULT NULL,
`use` varchar(80) DEFAULT NULL,
UNIQUE KEY `OGR_FID` (`OGR_FID`),
SPATIAL KEY `SHAPE` (`SHAPE`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=77 ;
Is there any way to change such a table into geojson format?
(I prefer the easy way, but if there is not, just change the column into array like is acceptable)
EDIT:
I use geophp written by phayes.
https://github.com/phayes/geoPHP/wiki/Example-format-converter.
This solves the main problem. Only need to a bit mess up with adding feature etc.
Any easier solution?
While there may not be a direct method to convert from a mysql spatial entity to geojson, you can try the following:
get the WKT (Well Known Text) of the entity. (MySQL Reference)
convert from WKT to geojson (Done in perl, although you should be able to find it in other languages or write your own in javascript);
Note that just calling jsonEncode() on the entity, as others have suggested, will not yeild geoJson.
My personal suggestion, which does not directly answer your question, would be to store the data in the format you need it retrieved in. It will reduce the overhead required to process the data every time you need it.
The easiest way to do this is to store the geojson in plain text as you suggested. If, for whatever reason, you also need the geometry stored in native format, you can store it in another column. The only downside is keeping the two columns in sync.
Problem: Cyrillic, UTF-8 encoded string, for example, "Михаил", specified in an HTML form, saved by PHP into MYSQL turns to unreadable krakozyabras like "Михайлович".
This is now a new problem, but I have found no solution so far... Please help if someone encountered this before.
HTML page is UTF-8 encoded and has properly set META; saving PHP script is UTF-8 encoded (with, or without BOM - doesn't matter). MySL table has DEFAULT ENCODING utf-8:
CREATE TABLE `cms_deposit_request` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Any input welcome! Thanks!
Always call
mysql_set_charset('utf8');`
function (or a similar function from the API you are using) right after connecting to database
if there is no such function, run
SET NAMES utf8
SQL query in the same place
Password needs to be matched by Password Hash which was originally created on a .NET platform and stored on MSSQL (so encryption is probably SHA1).
Here is how MySQL table looks like:
CREATE TABLE IF NOT EXISTS `test` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`UserName` varchar(100) COLLATE latin1_general_ci DEFAULT NULL,
`PasswordHash` varchar(100) CHARACTER SET utf8 DEFAULT NULL,
`PasswordSalt` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=12535 ;
--
-- Dumping data for table `test`
--
INSERT INTO `test` (`id`, `UserName`, `PasswordHash`, `PasswordSalt`) VALUES(9836, 'demoadmin', '?z1??9t|????e&??9aK', -1190254076);
INSERT INTO `test` (`id`, `UserName`, `PasswordHash`, `PasswordSalt`) VALUES(12534, 'sunny', '??o\\(R?8~??6>?t????o', 549612932);
I've found two very close examples to what I need to be done but I was enable to make it work.
Example 1: http://gilbert.pellegrom.me/replicating-net-password-hashing-in-php/
Example 2: http://www.kevinbruce.com/Blog?area_id=6&blog_id=3&ba_id=27
Usernames and passwords are:
First user: demoadmin/demotest
Second user: sunny/eclyptix
Please help!
It looks like you have an encoding problem:
'?z1??9t|????e&??9aK'
It seems that your original code was broken and was converting characters out of the printable ASCII range into question marks.
You could try to replicate this behaviour in PHP. However continuing to use this broken scheme will compromise the security of your system as it is much more likely that a hash collision can be found. It might be necessary to get all your users to change their passwords. This time make sure that the hashes are stored correctly. You may also want to consider storing them as hexadecimal strings instead of binary data to minimize the risk of further encoding problems.
Kevin Bruce here (from the second example you cited).
For what it's worth, I never got the problem solved with my experience. I actually spoke with Elizabeth Smith (who works on PHP core for Windows) and she agreed that there is a big disconnect in hash support on the same level as .NET, due to character encoding support in PHP. This is what I suspected.