php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14353 can't set CP_UTF8 codepage
Submitted: 2001-12-05 18:18 UTC Modified: 2002-04-25 02:38 UTC
From: msisolak at yahoo dot com Assigned:
Status: Closed Package: COM related
PHP Version: 4.2.0 OS: Windows 2000
Private report: No CVE-ID: None
 [2001-12-05 18:18 UTC] msisolak at yahoo dot com
A call to create a COM object can pass the codepage as the third parameter and CP_UTF8 is a valid option.  If you use this, however, the object create fails.

The problem is in the php_char_to_OLECHAR and php_OLECHAR_to_char functions in com\conversion.c.  MSDN states that a call to WideCharToMultiByte with a codepage of CP_UTF8 must have a second parameter is 0, but these functions don't account for that.

How I fixed it (there may be a better way, but it works for me):

lines 764 and 760: change "MB_PRECOMPOSED | MB_ERR_INVALID_CHARS" to "codepage == CP_UTF8 ? 0 : MB_PRECOMPOSED | MB_ERR_INVALID_CHARS"

lines 784 and 790: change "WC_COMPOSITECHECK" to "codepage == CP_UTF8 ? 0 : WC_COMPOSITECHECK"

This fix is not well debugged, but it got me moving forward again.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-06 12:24 UTC] phanto@php.net
i'll review this
 [2002-04-23 11:22 UTC] msisolak at yahoo dot com
This is still an issue in 4.2.0.
 [2002-04-25 02:38 UTC] derick@php.net
Fixed in CVS
 [2002-05-13 14:53 UTC] msisolak at yahoo dot com
the patch that was made for 4.2.1RC is incomplete - the call to WideCharToMultiByte must have 0 as the second parameter is the codepage is CP_UTF8, but this patch sets it to MB_ERR_INVALID_CHARS instead (submitted to qa.php.net)
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun May 22 19:03:48 2022 UTC