On Wed, May 2, 2007 5:32 pm, Rangel Reale wrote: > You are right, I really don't know Unicode very much! :P > > What I was trying to understand was, because unicode.runtime_encoding > = > iso-8859-1, I tought that all internal operations were done in this > encoding, and only when outputting (unicode.output_encoding = utf-8) > data > would be converted to utf-8. So to me, I did a mysql query with > latin1, data > comes to my variables as iso-8859-1, I use them, and only when I > echo'ed > them, they would become utf-8, from a iso-8859-1-to-utf-8-like > function. > > The strange thing to me, is the mysql_fetch_assoc function give this > error > even before I accessed the field values, as I understanded from the > above > explanation. > > Did I understood it wrong? No, you're probably right... I think that PHP may be "biased" toward UTF-16 (32?) internally, and be converting to/from UTF-16 and keeping everything in UTF-16 internally... But, really, since PHP 6 is not actually released yet, you probably need to be asking about this on "Internals", I think, to get a real answer... I suspect you'll still want to use iso-8859-1 on the output after you solve this bug, though, if you don't want it converted to utf-8 in the end.. You may also want to just try it with unicode semantics OFF, since that's probably the least debugged and biggest change in PHP 6, and if you do *everything* in Latin1, that's pretty much the state PHP was in since nineteen-ninety-mumble, and it will just work anyway... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
