From: Ashley Sheridan on 22 Jan 2010 03:41 On Fri, 2010-01-22 at 03:47 +0100, Jochem Maas wrote: > Op 1/22/10 2:28 AM, Ryan Park schreef: > > Forgot to reply all. > > > > You can see that it's in the middle of the sql statement. > > It looks fine here but some how it breaks during the query. > > > > <?php > > mysql_connect("localhost", "adminID", "password") or die(mysql_error()); > > echo "Connected to MySQL<br />"; > > > > mysql_select_db("databasename") or die(mysql_error()); > > echo "Connected to Database<br />"; > > > > $sql = "INSERT INTO xe_modules (module_srl, module, module_category_srl, > > layout_srl, menu_srl, site_srl, mid, skin, browser_title, description, > > is_default, content, open_rss, header_text, footer_text, regdate) VALUES > > ('135', 'bodex', '0', '53', '0', '0', 'free', 'xe_default', 'ìì ê²ìí > > ', '', 'N', '', 'Y', '', '', UNIX_TIMESTAMP());"; > > you need to: > > 1. have some understanding of char encoding and character sets. > 2. define you DB[tables] to use a collation that supports the stuff you want to enter. > 3. you need to connect to the DB with a suitable charset (google 'SET NAMES') > 4. you need to make sure the data you are putting into your queries is in that same charset. > > basically you need UTF8 - be prepared for some pain and a lot of reading in order > to get to grips with these concepts, I've personally found that encoding, charsets et al > are not the easiest things to one's head round. > > > > > mysql_query($sql) or die(mysql_error()); > > > > mysql_close(); > > ?> > > > > On 1/21/2010 5:19 PM, Jim Lucas wrote: > >> Ryan Park wrote: > >> > >>> Hello I'm currently trying to use PHP to insert foreign characters > >>> into one of the mysql database tables.mysql_query() worked > >>> seamlessly, but when I check the inserted data on phpMyAdmin it shows > >>> the foreign characters in broken letters, like this ìâ¹ÅÃÅ<- > >>> jibberish...The foreign characters show fine when I'm typing it out > >>> on my editor to code PHP, but it gets broken into unrecognizable > >>> symbols when put into mysql database columns. > >>> I tried to create the same thing this time through phpMyAdmin console > >>> and it worked great, the foreign characters showed correctly as they > >>> should.The column that I'm trying to put the foreign characters into > >>> is set as utf8_general_ci.I wish to use PHP to insert the data into > >>> the database because I'll be inserting massive amounts of them at > >>> once, so I just can't continue with this problem at hand. > >>> I'll greatly appreciate any help, thank you. > >>> _________________________________________________________________ > >>> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > >>> http://clk.atdmt.com/GBL/go/196390709/direct/01/ > >>> > >> How about showing a little of the insert code. ie: how you are > >> gathering the > >> data, how you are preping the data, and the actual insert statement. > >> > >> > > > > You're also forgetting one of the most important elements of this. If you're displaying the characters on a web page, chances are that you need to add a corresponding meta tag to inform the browser that the content is utf-8 <meta http-equiv="content-type" content="text/html; charset=UTF-8"/> Otherwise the browser will attempt to guess from the first few characters of output, and because of the large headers in some websites, will guess completely wrong. Thanks, Ash http://www.ashleysheridan.co.uk
From: "Michael A. Peters" on 22 Jan 2010 04:53 Ashley Sheridan wrote: > > > You're also forgetting one of the most important elements of this. If > you're displaying the characters on a web page, chances are that you > need to add a corresponding meta tag to inform the browser that the > content is utf-8 > > <meta http-equiv="content-type" content="text/html; charset=UTF-8"/> > > Otherwise the browser will attempt to guess from the first few > characters of output, and because of the large headers in some websites, > will guess completely wrong. Just to add - I had to deal with this, I think I got it right now but I'm not positive. My /etc/my.cnf file has the following: default-character-set=utf8 That way I don't have to remember to specify the charset when I create a new table. If you don't have control over that file (IE shared host) when you create your database tables, I believe you need to do SET character_set_client = utf8; before your create table commands. You should also send the charset in a header, IE header('Content-type: text/html; charset=utf-8'); but for html you also need to have the meta tag as mentioned because if the page is saved to disk, there's no other way for a browser to know the charset (and if it isn't there, w3c validator complains). proper xhtml doesn't need the meta tag because it has the charset in the <?xml version="1.0" encoding="UTF-8"?> that opens a proper xhtml document. If the charset isn't set, then any information sent via post will probably be sent using whatever charset the operating system uses by default, so setting the charset to utf-8 is important for pages that are forms as well as pages that display data. I'm by no means an expert, that's just what I had to do to get Aneides iëcanus to properly display. I already was doing the utf-8 for the web pages, but MySQL defaults to a different character set - I consider it a CentOS bug, they should have shipped with my.cnf set to utf-8 IMHO because just about everything else in the OS is utf-8 by default, but I pulled my hair out for half an hour trying to figure out why it wasn't working when the reason was the default charset of the MySQL client used to initially create the database table.
From: Ryan Park on 22 Jan 2010 05:33 Thank you all for the helpful comments. I've finally solved the problem through sql command "set name." On 1/22/2010 1:53 AM, Michael A. Peters wrote: > Ashley Sheridan wrote: > >> >> >> You're also forgetting one of the most important elements of this. If >> you're displaying the characters on a web page, chances are that you >> need to add a corresponding meta tag to inform the browser that the >> content is utf-8 >> >> <meta http-equiv="content-type" content="text/html; charset=UTF-8"/> >> >> Otherwise the browser will attempt to guess from the first few >> characters of output, and because of the large headers in some websites, >> will guess completely wrong. > > Just to add - I had to deal with this, I think I got it right now but > I'm not positive. > > My /etc/my.cnf file has the following: > > default-character-set=utf8 > > That way I don't have to remember to specify the charset when I create > a new table. > > If you don't have control over that file (IE shared host) when you > create your database tables, I believe you need to do > > SET character_set_client = utf8; > > before your create table commands. > > You should also send the charset in a header, IE > > header('Content-type: text/html; charset=utf-8'); > > but for html you also need to have the meta tag as mentioned because > if the page is saved to disk, there's no other way for a browser to > know the charset (and if it isn't there, w3c validator complains). > > proper xhtml doesn't need the meta tag because it has the charset in the > <?xml version="1.0" encoding="UTF-8"?> > that opens a proper xhtml document. > > If the charset isn't set, then any information sent via post will > probably be sent using whatever charset the operating system uses by > default, so setting the charset to utf-8 is important for pages that > are forms as well as pages that display data. > > I'm by no means an expert, that's just what I had to do to get > Aneides iëcanus > to properly display. > > I already was doing the utf-8 for the web pages, but MySQL defaults to > a different character set - I consider it a CentOS bug, they should > have shipped with my.cnf set to utf-8 IMHO because just about > everything else in the OS is utf-8 by default, but I pulled my hair > out for half an hour trying to figure out why it wasn't working when > the reason was the default charset of the MySQL client used to > initially create the database table. > >
From: tedd on 22 Jan 2010 12:04 At 4:18 PM +0000 1/22/10, Ashley Sheridan wrote: > >You'd be surprised how many people still use a dumb browser! > >Thankfully though, it seems that people are wising up a bit more, as >these stats from a media website show: > >Safari 4 2624 >Firefox 3.5 1320 >Firefox 3 690 >IE 8 501 >IE 6 465 >IE 7 417 >Safari 3.2 171 >Firefox 2 151 >Mozilla 1.9 109 >Unknown 0 56 >Safari 3.1 53 >Chrome 3 34 >Safari 3 19 >Google Webmaster Tools 0 7 >Flock 2 5 >Opera 10 1 > >This is a media-based website, which would explain the large use of >browsers available for the Mac, but I still take it as a good sign. > >Thanks, >Ash Ash: As you know, stats really depend upon the site tested. I have one site where over 99 percent of the visitors are Mac users (over 120 unique visitors each day). The following link I think provides more typical browser selection stats. http://www.w3schools.com/browsers/browsers_stats.asp Fortunately IE6 is on the way out (good riddance) and other IE's are losing ground (Woo Hoo!). More browser developers are trying to adhere to standards rather than fighting them like M$ does. As I see it, it always takes M$ a little more time to learn anything worthwhile. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
From: Ashley Sheridan on 22 Jan 2010 12:06 On Fri, 2010-01-22 at 12:04 -0500, tedd wrote: > At 4:18 PM +0000 1/22/10, Ashley Sheridan wrote: > > > >You'd be surprised how many people still use a dumb browser! > > > >Thankfully though, it seems that people are wising up a bit more, as > >these stats from a media website show: > > > >Safari 4 2624 > >Firefox 3.5 1320 > >Firefox 3 690 > >IE 8 501 > >IE 6 465 > >IE 7 417 > >Safari 3.2 171 > >Firefox 2 151 > >Mozilla 1.9 109 > >Unknown 0 56 > >Safari 3.1 53 > >Chrome 3 34 > >Safari 3 19 > >Google Webmaster Tools 0 7 > >Flock 2 5 > >Opera 10 1 > > > >This is a media-based website, which would explain the large use of > >browsers available for the Mac, but I still take it as a good sign. > > > >Thanks, > >Ash > > > Ash: > > As you know, stats really depend upon the site tested. I have one > site where over 99 percent of the visitors are Mac users (over 120 > unique visitors each day). > > The following link I think provides more typical browser selection stats. > > http://www.w3schools.com/browsers/browsers_stats.asp > > Fortunately IE6 is on the way out (good riddance) and other IE's are > losing ground (Woo Hoo!). > > More browser developers are trying to adhere to standards rather than > fighting them like M$ does. As I see it, it always takes M$ a little > more time to learn anything worthwhile. > > Cheers, > > tedd > > -- > ------- > http://sperling.com http://ancientstones.com http://earthstones.com > I agree that stats vary from site to site, I was just picking one I had my own tracking on that wasn't of a technical persuasion. W3C admits themselves that their stats are probably tainted by the technical experience of its visitors. I don't want to hijack this thread so I won't go into anything that would spur a mass debate! (don't read those last two words aloud too quickly!) Thanks, Ash http://www.ashleysheridan.co.uk
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: linked data Next: Help on compiling PHP for MIPS, Bus Error thrown |