ID: 40664
Comment by: vincent at eal dot com
Reported By: fjortiz at comunet dot es
Status: Assigned
Bug Type: COM related
Operating System: Win32
PHP Version: 5.2.1
Assigned To: wez
New Comment:
Any update on this bug? I still have the problem with PHP 5.2.3 and the
changelog does not indicate any fix in 5.2.6.
It is very annoying to have a nice patch standing there still with no
one to commit it to CVS.
Previous Comments:
------------------------------------------------------------------------
[2007-08-15 08:36:07] [EMAIL PROTECTED]
Assigned to the maintainer.
------------------------------------------------------------------------
[2007-07-25 14:28:09] ameoba32 at gmail dot com
i found this bug too, so code is like this:
$word = new COM("Word.Application", null, CP_UTF8);
$word->Visible = true;
$doc = $word->Documents->Add();
$word->Selection->TypeText( "UTF8 text here, russian in my case" );
In word appears "Normal text " + garbage.
can this be fixed in CVS ? i have to compile php on win32 by myself ;)
------------------------------------------------------------------------
[2007-05-28 15:07:30] [EMAIL PROTECTED]
Unfortunately the extension is currently unmaintained, so I don't think
anybody is going to commit your patch in the nearest future.
------------------------------------------------------------------------
[2007-05-23 11:51:16] fjortiz at comunet dot es
Any updates about this?. I'm showing you the code so fix the issue.
Please tell me what else you may need to carry this into the main tree.
TIA
------------------------------------------------------------------------
[2007-02-28 11:38:27] fjortiz at comunet dot es
Description:
------------
when converting a UTF-8 encoded, multibyte string (Russian for
example), to a COM string, a wrong number of bytes are allocated, thus
creating the COM string with junk bytes at the end.
For example, when I pass my COM-based ADODB driver a 5-letter word in
Russian, I get at destination a 10 (5*2) characters string, the first 5
are the right Russian chars and the rest 5 are junk characters.
This was also explained for 4.4.2 in bug #37899
Actual result:
--------------
this is solved patching two files:
\ext\com_dotnet\com_variant.c, function php_com_variant_from_zval, line
156:
156,157c156
< V_BSTR(v) = SysAllocString((char*)olestring);
---
> V_BSTR(v) = SysAllocStringByteLen((char*)olestring,
> Z_STRLEN_P(z)
* sizeof(OLECHAR));
\ext\com_dotnet\com_olechar.c, function php_com_string_to_olestring:
37d36
< uint unicode_strlen;
39,40c38,44
< unicode_strlen = MultiByteToWideChar(codepage, (codepage == CP_UTF8
?
< 0 : MB_PRECOMPOSED | MB_ERR_INVALID_CHARS), string, -1, NULL,
0);
---
> if (string_len == -1) {
> /* determine required length for the buffer (includes NUL
terminator) */
> string_len = MultiByteToWideChar(codepage, flags, string, -1,
> NULL,
0);
> } else {
> /* allow room for NUL terminator */
> string_len++;
> }
42,44c46,48
< if (unicode_strlen > 0) {
< olestring = (OLECHAR*)safe_emalloc(sizeof(OLECHAR),
unicode_strlen,
0);
< ok = MultiByteToWideChar(codepage, flags, string, -1, olestring,
unicode_srlen);
---
> if (strlen > 0) {
> olestring = (OLECHAR*)safe_emalloc(sizeof(OLECHAR), string_len,
0);
> ok = MultiByteToWideChar(codepage, flags, string, string_len,
olestring, string_len);
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=40664&edit=1
