Invalid multibyte sequence in argument

I'm getting this error as well when accessing admin_menu->README.txt

Not sure if it's confined to that specific function.

I am getting this warning when trying to restore a backup with the Backup & Migrate module.

I'm seeing this on IIS too, accessing a URL like http://example.com/?q=%e3h

Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1572 of C:\Users\user\Documents\My Web Sites\D7 MySQL\includes\bootstrap.inc).

Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain() (line 1572 of /var/www/drupal/includes/bootstrap.inc).

Getting this error testing an ldap connection. The connection succeeds, but this error is also generated.

Ubuntu 11.10 (GNU/Linux 3.0.0-12-server x86_64)
Apache/2.2.20 (Ubuntu)
Apache API Version 20051115

I am also experiencing this same issue. One thing I noticed is that my first OU inside of my root DN has a space. Example: ou=drupal users . When doing the test without any special characters (other than the commas between attributes) I was unable to successfully validate the user test. I WAS able to connect though.

By putting each attribute item in quotes, I was able to successfully connect AND the validation of a user was confirmed. Although now I see this same invalid multibyte sequence error that other users are posting about. I haven't found a way to connect and validate without the quotes. I even tried single tic marks ( ' ) instead of traditional quotes and the test wouldn't even allow me to connect.

Here is an example of the full DN string I am using that DOES work (but throws the warning)...
ou="drupal users",ou="employees",dn="intranet",dn="company",dn="com"

Again - the test DOES connect and DOES validate the user, but also presents the lovely red warning.

On a possibly related note, I used the same DN string on the the TEST LDAP QUERY on the Queries tab and, not only is it successful and displays results of all groups and users for my entire domain, I also get ZERO errors or warnings. Code error perhaps?

Thanks in advance!

I have the same error as reported in #4.

I have the same issue in version 7.14. I had no such issues before updating to 7.14.

I have a multilanguage site and the error seems to show up only when I'm viewing or editing nodes with language Simplified Chinese (zh-hans). I have no errors when viewing nodes with other languages such as English or Finnish.

Unlike to others here I don't have any ldap related modules on my site. So far I'm clueless what is causing the error and I'm not sure where to start debugging to find the reason to this.

Does anyone have any ideas?

This seems to be affecting me on titles of nodes.

We are in the process of launching a new site, and while waiting for translations I updates Drupal to 7.14. So I have no experience with previous versions.

When loading a title such as "Estándares de Recopilación de Datos", I will get a white screen with the following errors:

Additional uncaught exception thrown while handling exception.
Original

PDOException: in dblog_watchdog() (line 154 of Ddblog\dblog.module).
Additional

PDOException: in locale() (line 713 of locale\locale.module).

WHen I back out from the error, I see the following Drupal-generated errors:

    Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1572 of includes\bootstrap.inc).
    PDOException: in dblog_watchdog() (line 154 of dblog\dblog.module).
    Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1572 of includes\bootstrap.inc).
    Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1572 of includes\bootstrap.inc).

I note that the node is saved with the correct title; it seems to be only when the node is displayed that the error is generated. For example, I can go to the Content admin view, edit the node, remove the non-english characters and save the node. The node then displays correctly.

This error does not occur with non-english characters in the Menu title field; just the node title.

So far my work-around has been to remove the characters from the title. This is going to be OK until I get to the Russian translation :P

I am using Drupal 7.14 on Windows Server 2003 (IIS 6). PHP version 5.2.17 using Zend CE. MySQL version 5.5.20.

#393538: Document that check_plain() can issue PHP messages on invalid UTF-8 input

I have same problem in persian language,
the easiest way is disabling dblog module.

The solution
PHP multibyte string functions must be used, see in the PHP reference Multibyte String Functions.

Use mb_substr() instead of substr().
Use the u modifier for regex such as preg_match().

Multibyte problems with UTF-8 can be quite tricky as the may occur only sporadic since UTF-8 is for western countries mostly singlebyte.

view this link

I receive this message since updating to Drupal 7.16.

I fixed it like this:

- open includes/bootstrap.inc

in line 1571 find:

function check_plain($text) {
  return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
}

Replace with:

function check_plain($text) {
  if (!mb_detect_encoding($text, 'UTF-8', true)) {
        $text = mb_convert_encoding($text, 'UTF-8', 'ISO-8859-1');
  }
  return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
}

from here: http://social.msdn.microsoft.com/Forums/en-US/sqldriverforphp/thread/6a1...

Updating to drupal 7.17 and the issue re-appeared. i re-applied the above fix from #13 and the error has vanished again.

#13 fixed my issue but I tracked it down to custom code (auto setting of menu access key on multilingual site) and fixed at source instead of patching core.

Thanks for the info, Guy.

I think I may have the same issue somewhere in my custom modules.
Could you explain a little more how you managed to track the issue?

Thanks

Hi @tecjam I have put a break point inside the if condition you added in #13 to see what was calling the check_plain() with a non utf-8 string. If you don't use a step debugger you can use a back trace something like

function check_plain($text) {
  if (!mb_detect_encoding($text, 'UTF-8', true)) {
        var_dump(debug_backtrace());
        $text = mb_convert_encoding($text, 'UTF-8', 'ISO-8859-1');
  }
  return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
}

if you get lots of calls to this you should maybe write it to the log or exit execution on the first hit.

This showed me what code was calling it.
Hope this helps

I've tracked down two of the little blighters.

They hide in the list returned by country_get_list(). To wit:

    'CW' => $t('Curaçao'),

and

    'BL' => $t('Saint Barthélemy'),

(Note I took this from .../includes/iso.inc where the list is actually generated, hence the $t)

That's a cedilla in Curacoa and eacute in Saint Barthelemy.

If one uses the 'countries' built-in option list on a webform you will generate two htmlspecialchars warnings each time the form is rendered.

I use hook_countries_alter() to replace the cedilla and eacute and for the existing webforms, hook_form_alter().

The webform is fairly straightforward when one realises that the form definition is buried slightly deeper than normal, so in my case I have code like:

<?php
function xxxxxx_form_alter(&$form, &$form_state, $form_id) {
  static $webfmpfx = 'webform_client_form_';
  if (strncmp( $webfmpfx, $form_id, strlen( $webfmpfx ) )) return;

  if (isset($form['submitted']['country']['#options'])) {
    $country = &$form['submitted']['country']['#options'];
    if (!empty($country['CW'])) $country['CW'] = t('Curcao');
    if (!empty($country['BL'])) $country['BL'] = t('Saint Barthelemy');
  }
}
?>

and

<?php
function xxxxx_alter_countries_alter( &$countries ) {
	static $t = null;
	static $changes = array(
		'BL' => 'Saint Barthelemy',
		'CW' => 'Curacao',
	);

	if (empty( $t )) $t = get_t();
	foreach ($changes as $code => $name) {
		if (!empty( $countries[$code] )) $countries[$code] = $t( $name );
	}
 }
 ?>

If one is feeling energetic one can update the webform_component table and modify the serialized data in the "extra" column. Just remember that the cedilla and eacute are two bytes and when replace by a single 'c' or 'e' the count needs to be reduced by two (in my case from 3447 to 3445) otherwise one gets unserialization failures when it comes time to render the form.

Hope this helps someone.

I had the same problem too. #12 solved my problem.

#13 fixd the problem for me - is it a candidate for a patch?

replace drupal check_plain() with this version

function check_plain($text) {
	return htmlspecialchars(mb_convert_encoding($text, "UTF-8", "auto"), ENT_QUOTES, 'UTF-8');
}

Issue state since #9 is closed (duplicate), because it is a duplicate of:
#393538: Document that check_plain() can issue PHP messages on invalid UTF-8 input
If anybody wants to contribute, please do it there.

I get sometimes this error:

 Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain()
(line 1567 of /drupal/includes/bootstrap.inc).

I use the suggestion form #13 and I did a patch.... works for me.

Thanks!