From: [EMAIL PROTECTED]
Operating system: Win NT
PHP version: 4.2.1
PHP Bug Type: OCI8 related
Bug description: OCI fetch routines not working with UTF8 DB
I seem to be unable to return un-corrupted data from a UTF8 Oracle
database.
Consider this example:- (appologies for debugging)
<?
putenv("NLS_LANG=American_America.UTF8");
mb_internal_encoding("UTF-8");
$sql = "select dump(mycolumn) dump, mycolumn from my_table";
$link = OCIplogon("user","pass","connection");
//OCIInternalDebug(1);
$parse = OCIParse($link,$sql);
OCIExecute($parse);
if (OCIFetch($parse))
{
$mycolumn = OCIResult($parse, "mycolumn");
$mycolumndump = OCIResult($parse, "DUMP");
print "found:";
print bin2hex($mycolumn);
print ": ".$mycolumn." : len = ".mb_strlen($mycolumn);
print "<br><br>";
print $mycolumndump;
print "<br><br>";
print mb_detect_encoding($mycolumn, "auto");
print "<br><br>";
print mb_internal_encoding();
print "<br><br>";
print_r( mb_get_info("all"));
}
?>
e.g.
If mycolumn contains a single UTF8 character E594B4 (three bytes)
I get the result:-
found:bf {upsidedown question mark} len=1
Typ=1 Len=3 228,148,180
EUC-JP
UTF-8
-
I would have expected to see:
found:e594b4 {a japanese glyph} len=3
I suppose the question is, does the OCI interface work correctly with
multi-byte strings?
--
Edit bug report at http://bugs.php.net/?id=17381&edit=1
--
Fixed in CVS: http://bugs.php.net/fix.php?id=17381&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=17381&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17381&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17381&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17381&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17381&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17381&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17381&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=17381&r=globals
