ID: 17381
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: OCI8 related
Operating System: Win NT
PHP Version: 4.2.1
New Comment:
I'm having exactly the same problem here.
PHP 4.2.2
RH Linux 2.4.9-34smp #1 SMP i686
Apache/1.3.22
Oracle 8i database with UTF8 characterset.
Heelp?
Previous Comments:
------------------------------------------------------------------------
[2002-09-27 10:55:29] [EMAIL PROTECTED]
I am experiencing the same problem.
PHP 4.2.2
Red Hat Linux 7.2
Apache 1.3.26
Unable to insert multi-byte strings into Oracle and select it back
out.
Using mbstring and oci8 functions.
Any progress on this one?
------------------------------------------------------------------------
[2002-07-23 05:09:59] [EMAIL PROTECTED]
I met this kind of problems too.
my database's character set is zhs16cgb231280, zhs16gbk,
can not work too. the output i got is "aa????bb????"
which should be "aaXXXXbbXXXX" (X present a 2-byte-chinese
char)
i set the NLS_LANG use SetEnv in httpd.conf of apache,
the NLS_LANG changed but he result is unchanged.
someone suggested that use "export NLS_LANG=xxxx" in
apachectl script file, i tried, but failed. all
"xxxx" except use charset us7ascii failed with an oracle
error ora-12705, "unacceptable char set".
------------------------------------------------------------------------
[2002-05-23 06:50:05] [EMAIL PROTECTED]
Can I just point out that I have used putenv, to set NLS_LANG in the
example, because I thought that the system-wide environment variable
$NLS_LANG was not being picked up. It is currently set to
"American_America.UTF8".
------------------------------------------------------------------------
[2002-05-23 05:34:35] [EMAIL PROTECTED]
Email typo in original post.. :-)
------------------------------------------------------------------------
[2002-05-23 05:32:37] [EMAIL PROTECTED]
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 this bug report at http://bugs.php.net/?id=17381&edit=1
