|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2002-05-23 06:50 UTC] robert dot earls at lis dot co dot uk
[2003-10-14 21:00 UTC] sniper@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Nov 03 01:00:01 2025 UTC |
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?