recently (perhaps after upgrade to latest Drupal version, maybe after FileField module update - not sure...), i've started to see this in Drupal's logs:
htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /var/www/html/drupal6/includes/bootstrap.inc on line 840.

CentOS release 5.5 (Final)
Drupal 6.17
MySQL 5.0.77
PHP 5.2.10

How to fix it?

#45 bootstrap.patch588 byteslordzik
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch bootstrap_45.patch.
[ View ]
#42 bootstrap.patch606 byteslordzik
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in bootstrap_44.patch.
[ View ]
#14 Coupé.txt5 bytescraig_
#14 file_handle_utf8_filenames.patch519 bytescraig_
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in file_handle_utf8_filenames_0.patch.
[ View ]


lordzik’s picture


Chi-Yu’s picture

I encountered the same problem with CCK file upload fields and the problem seems to be related to special characters in filenames. This only seems to happen when the filenames of the images I'm trying to upload contain German Umlauts like in "logo_groß.png".

lordzik’s picture

Project:Drupal core» FileField
Version:6.17» 6.x-3.5
Component:base system» Code

Let's try on FileField project...

quicksketch’s picture

Generally I'd suggest installing Transliteration to fix problems with URL-unsafe characters. Could you provide steps to reproduce the problem?

quicksketch’s picture

Status:Active» Postponed (maintainer needs more info)
lordzik’s picture

Attach (using FileField) a file which name is like zażółćgęśląjaźń.pdf and try to browse that node and download this file.

I'll try a module you suggested.


quicksketch’s picture

Version:6.x-3.5» 6.x-3.6

I can't reproduce this problem in FileField 3.6. I've tried using both private and public files, but they both work fine. I'll need instructions on how to reproduce from a clean Drupal install.

quicksketch’s picture

You should also check that you have the multibyte PHP extension enabled on your server, since if you're going to be dealing with UTF-8 characters it's rather important that you have it enabled.

noahterp’s picture

This error has occurred for me when the URL alias contained special characters like curly apostrophes (’) or horizontal ellipses (…) -- pathauto doesn't appear to catch those. So in addition to the other suggestions above, just try to stick with regular Latin characters.

lordzik’s picture

I have php-mbstring installed and properly detected by Drupal.
I still see error in dblog when i view pages where filenames contains polish fonts.
For now, i will attach files again so Transliteration module will replace them.


Lukas von Blarer’s picture

The same error occured when i tried to import exif data from a image which contains umlauts. has anyone fixed this error?

skat’s picture


craig_’s picture

Version:6.x-3.6» 6.x-3.7
Status:Postponed (maintainer needs more info)» Needs review

I was finding the same behavior described, but when using the Drag & Drop upload module. Tracked this down through the layers and found that the problems I was having was the inconsistency of how the file system returns the filename to drupal (non unicode), and how drupal then proceeds to render, expecting unicode.

There are a number of places that call functions for getting file data, but if I patch it at the time it is saved, it clears this message, allows theming, file name display in the form, and file deletion to happen normally again.

Attaching the one-line patch to /includes/file.inc [line: 553]
$file->filename = utf8_encode($file->filename);

And, a sample file for uploading with and without the patch applied.

craig_’s picture

new519 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in file_handle_utf8_filenames_0.patch.
[ View ]
new5 bytes


quicksketch’s picture

This seems like it's a fix that may be necessary only on certain configurations. Trying out the attached file, I had no problems with uploading or deleting the file on my machine. I'm also not real sure that using utf8_encode() is the right fix, or that we're doing that in the right place.

jan_v’s picture

How come this wasn't an issue in previous versions ? What has changed?

jan_v’s picture

The utf8_filenames patch of #14 did not work for me.

Adding $text = utf8_encode($text); in bootstrap.inc on line 840 (before the return value) did get rid of the errors, but it replaces the special characters that cause the error in the first place by binary gibberish.

So i think the string with special characters needs to be handled somewhere else.

ikeigenwijs’s picture


ikeigenwijs’s picture

patch did not work for me.
kind regards

Mike at techtir’s picture

I see this recently also (many times last night from

Location http://www.techtir.ie/index.php+%28200+ok%29+ACCEPTED++++++++++Result:+%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0%ED%FB+%E4%E0%ED%ED%FB%E5+x_fields.txt;%E7%E0%F0%E5%E3%E8%F1%F2%F0%E8%F0%EE%E2%E0%EB%E8%F1%FC+%28%E2%EA%EB%FE%F7%E5%ED+%F0%E5%E6%E8%EC+%F2%EE%EB%FC%EA%EE+%F0%E5%E3%E8%F1%F2%F0%E0%F6%E8%E8%29;

Referrer  http://www.techtir.ie/index.php+%28200+ok%29+ACCEPTED++++++++++Result:+%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0%ED%FB+%E4%E0%ED%ED%FB%E5+x_fields.txt;%E7%E0%F0%E5%E3%E8%F1%F2%F0%E8%F0%EE%E2%E0%EB%E8%F1%FC+%28%E2%EA%EB%FE%F7%E5%ED+%F0%E5%E6%E8%EC+%F2%EE%EB%FC%EA%EE+%F0%E5%E3%E8%F1%F2%F0%E0%F6%E8%E8%29;

Message htmlspecialchars(): Invalid multibyte sequence in argument in /hsphere/local/home/logik123/techtir.com/includes/bootstrap.inc on line 857.

Also if I click on http://www.techtir.ie/admin/reports/search_engine_referers I get the errors

    * warning: htmlspecialchars(): Invalid multibyte sequence in argument in /hsphere/local/home/logik123/techtir.com/includes/bootstrap.inc on line 857.
    * warning: htmlspecialchars(): Invalid multibyte sequence in argument in /hsphere/local/home/logik123/techtir.com/includes/bootstrap.inc on line 857.
    * warning: htmlspecialchars(): Invalid multibyte sequence in argument in /hsphere/local/home/logik123/techtir.com/includes/bootstrap.inc on line 857.
    * warning: htmlspecialchars(): Invalid multibyte sequence in argument in /hsphere/local/home/logik123/techtir.com/includes/bootstrap.inc on line 857.

Then it does show the usual sort of list:

20 Aug 2010 - 16:12 node/1001268 www.google.ie Tree satellite receivers on one dish more channels
20 Aug 2010 - 16:00 book/export/html/1001273 www.google.com.ar dvb-t active deflector
20 Aug 2010 - 15:47 howto/align_sat_dish www.google.co.uk how to align a satellite dish for 16 east
20 Aug 2010 - 15:46 howto/align_sat_dish www.google.co.uk how to align a satellite dish for 16 east
20 Aug 2010 - 15:44 howto/align_sat_dish www.google.co.uk how to align a satellite dish for 16 east
20 Aug 2010 - 15:23 node/1003431 www.google.nl jal multitasking


downunder_al’s picture

Priority:Normal» Major

I got the same issue with Drupal 6.17 on my live box running:
Apache/2.2.14 (Ubuntu)
MySQL 5.1.41

I applied the patch ( $text = utf8_encode($text); at line 840, as per #17) and the error went away, but I also got binary gibberish instead of punctuation.

When I upgraded to 6.19, the error returned again (only at bootstrap.inc line 857).

(FWIW I notice that the bootstrap.inc in 6.19 is different to 6.17. Perhaps someone has had a try at fixing this?)

However, when I ran the same build on my dev setup - Windows XP - testing on both PHP 5.2.9-2 and PHP 5.2.10, Apache 2.2.11, MySQL 5.1.36 I do NOT get the error, and it generally works fine, which leads me to suspect that the problem might be to do with different implementations of PHP?

Interestingly, if you google "invalid multibyte sequence in argument in bootstrap.inc on line 857" you get lots of sites showing up with this error.

Currently I have hidden the error message from non-logged-in people, on the grounds that I'd rather have my authorised users ask me about the message than have stupid binary gibberish on the screen.

I'm not sure if it is to do with filefield - surely bootstrap.inc must be part of the core? (forgive my ignorance if I'm wrong - I'm not a php developer, so I haven't looked all that much into this at a code level)

I have upgraded this to major because there seems to be a lot of sites with the same problem.

Again, I wonder if this is to do with a conflict between PHP implementations?

openmode’s picture

I got a similar issue with Drupal 6.19:

Server web Apache
PHP 5.2.11
MySQL 5.0.88
HTML Purifier Library 4.1.1
Libreria Unicode Estensione Mbstring per PHP

The error is in page Site building - Blocks after upgrade from Drupal 6.17:
warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /var/www/html/..../includes/bootstrap.inc on line 857.

tengoku’s picture

hi... i have this error and googling around found this issue


hope that helps.

suscribing also ;)

downunder_al’s picture

I wonder if it is to do with different operating systems? My windows box works fine, my ubuntu live server doesn't.

For the time being I have hidden the error messages away in the logs so at least it doesn't alarm people.

@tengoku I saw that as well, but it doesn't seem to have a solution in the bug (unless I am going blind, which is always possible...)

mwangi’s picture

the error also shows up if you have an apostrophe in your url.

this can be caused by pathauto - check the contents of the fields feeding to the url

Anticosti’s picture

For me the error on line 857 dissapeared after uninstalling the Case Tracker Module (casetracker-6.x-1.0-beta8)
Hope this may help...

pixelpreview’s picture

I don't have tracker module installed
but I have this message too but for me it's the line 840 in drupal 6.18
in the check_plain function
these function doesn't exist in precedent version of drupal 6.17 --> 6.18
I have on my server the PHP Version 5.2.14

function check_plain($text) {
  static $php525;

  if (!isset($php525)) {
    $php525 = version_compare(PHP_VERSION, '5.2.5', '>=');
  // We duplicate the preg_match() to validate strings as UTF-8 from
  // drupal_validate_utf8() here. This avoids the overhead of an additional
  // function call, since check_plain() may be called hundreds of times during
  // a request. For PHP 5.2.5+, this check for valid UTF-8 should be handled
  // internally by PHP in htmlspecialchars().
  // @see http://www.php.net/releases/5_2_5.php
  // @todo remove this when support for either IE6 or PHP < 5.2.5 is dropped.

  if ($php525) {
   --------------->>>>>>>>> return htmlspecialchars($text, ENT_QUOTES, 'UTF-8');

vanvemden’s picture

Got this error when customizing the user-picture.tpl.php file. Used the following code and the error occurred:
<?php print theme('imagecache', 'profile_mini', $account->picture, $alt, $title, $attributes); ?>
The error was gone when I set empty values for undefined variables:

$alt = '';
$title = '';
$attributes = '';

Hope this helps.

etomilin’s picture


quicksketch’s picture

Priority:Major» Normal
Status:Needs review» Postponed (maintainer needs more info)

I personally don't think this is an issue with FileField. I'll need information on how to reproduce this issue from a fresh Drupal install, otherwise I'll probably close this issue.

Shane Birley’s picture

I would agree. I have seen this error here and there and the issue seems to revolve around core.

Shane Birley’s picture

Actually, let me correct myself here. I just said "core" but what I mean is CCK (which I associate with being a "core" contrib module).

xandeadx’s picture


timurek’s picture

Same problem here, using charcters ")" and "(" in file name.

xamount’s picture

I have this same problem and I think it relates to the check_plain and with accents in the URL. Not too sure. Definitely something to do with accents.

I do not have cck enabled.

I have made a replica of my site on a differrent server with the only difference being a new version of php and there error is no longer there.

So I get the error in php version 5.2.10 but I do not get the error in php version 5.3.1

Multibyte Support is enabled on both servers in php.

clafrancis’s picture


quicksketch’s picture

Category:bug» support
Status:Postponed (maintainer needs more info)» Closed (won't fix)

As stated by multiple users (especially the "I do not have cck enabled."), this is not an issue with FileField, please look elsewhere for help on this issue.

darkdim’s picture

MaxMendez’s picture

also solved my problem

openmode’s picture

Solution posted by darkdim for me don't fix the problem with Drupal 6.22:

PHP 5.2.11
MySQL 5.0.88

The error is in administration page "Site building - Blocks" (other languages ex:it):

warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /var/www/html/..../includes/bootstrap.inc on line 857.

Heine’s picture


The warning you get telling you about the invalid byte sequence is just that; an invalid byte sequence was passed to check_plain. The warning itself is not a bug.

The actual problem is that somewhere along the line, a non-utf8 encoded string was used as if it was utf-8 encoded.

This might be because you scrambled your database, because you saved a tpl.php file with the wrong encoding (damn you Eclipse!) or because the filesystem returns a filename in whatever encoding it feels like.

_THIS_ issue is about files.

craig_ and downunder_al : what filesystem do you use?

lordzik’s picture

Project:FileField» Drupal core
Version:6.x-3.7» 6.22
Component:Code» file system
Status:Closed (won't fix)» Active
new606 bytes
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in bootstrap_44.patch.
[ View ]

I've put this thread back to Drupal core. Not sure if "file system" Component is a right place (correct me if i'm wrong).
(probably) related case:
I've just tried the solution from #1 of that case and i've get rid of the warning!

I've check PHP's manual about htmlspecialchars http://php.net/manual/en/function.htmlspecialchars.php and:
"For the purposes of this function, the charsets ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent, provided the string itself is valid for the character set, as the characters affected by htmlspecialchars() occupy the same positions in all of these charsets."
If all of this 7 encodings are "effectively equivalent" and by default (if charset is ommited) ISO-8859-1 is used, then perhaps it is best to get rid of manual charset selection?

lordzik’s picture

Status:Active» Needs review

Status:Needs review» Needs work

The last submitted patch, bootstrap.patch, failed testing.

lordzik’s picture

Status:Needs work» Needs review
new588 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch bootstrap_45.patch.
[ View ]

Status:Needs review» Needs work

The last submitted patch, bootstrap.patch, failed testing.

Heine’s picture

The patch in #46 would output invalid bytesequences causing XSS issues in IE6.

The warning is a symptom, not a cause. See also #41.

Heine’s picture

Let me highlight the salient part of the quote:

"For the purposes of this function, the charsets ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent, provided the string itself is valid for the character set, as the characters affected by htmlspecialchars() occupy the same positions in all of these charsets."

This is why we use the charset parameter, because we do not know.

lordzik’s picture

Status:Needs work» Needs review

Well, i can live with hypothetical XSS issue. In that particular case it's better than complaining users...

I can only hope that someone will dig deeper and solve the problem :)

Heine’s picture

Status:Needs review» Needs work

It is not hypothetical and I cannot live with it :)

See SA-2008-006 - Drupal core - Cross site scripting (UTF8)

Please do not obstruct fixing the _actual_ problem by treating symptoms.

Please provide steps to reproduce and information on the filesystem in use.

iamatallone’s picture


DTB’s picture

The past have met with this error, but never found the cause of failure ...
Now, I sat down, and step by step tracing the code, but this did not lead solution. I tried to dump out the last of the values ​​of variables .. and got the bug (in my code) A possible source of error, if the UTF8 encoded text using their own code, and you know get a cut of the word-length, such as 255 and to the substr() function is used instead of the mb_substr. This is BIG ERROR, because it may have to halve the two-byte characters for the function, and is a known fault.
SOLUTION: Always use the mb_substr() function!

Heine’s picture

Status:Needs work» Postponed (maintainer needs more info)
timurek’s picture


my findings are completely different. I use Views for export products from my shop. The View uses "remove HTML tags" for product description (and it is necessary). When there is an HTML entity used in product description (i.e. & nbsp ; or any other entity) then there is empty string returned by view, or - worst case - i got error 500.

backtrace follows:

Does anyone have any idea?


gandhiano’s picture

Issue tags:+file encoding

Comment #41 - the issue is related with the files themselves, helped me in fixing this error, which appeared while editing a theme file (fourseasons template.php) using the Theme Editor module.

After converting the file to utf-8, the error was gone and the file was editable. Maybe this helps other people too, although I doubt it's the solution for all the problems reported within this issue.

owice’s picture

Hi all,

Good work and think from all ..... hats down for your efforts.

I think that the problem is "operating system" related problem because of the following:

I have a website for my department and there is many sections here and I need to upload many files for each one. So I use CCK with filefield using "attach file" method. When I started uploading files, files names in the list was written as question marks (instead of each letter there was a question mark) in the "list" of files - who is using Attach file method will understand me!- so I started to try solving this problem. Because my website is over network, I went to the server and edit the "regional settings" for the system och I forget to tell you that my language is Arabic so the files was Arabic named. So after changing the regional settings on the server a more strange problem appeared ... the files names disappeared. They are listed without name !!!!. I stopped there and think again how to solve the problem. I went to my pc and change the regional setting also. Just after that I faced the problem ... I meant the warning appeared.

Am I say something must not to say? I am sorry before anyone blame me ;)

Also subscribe :)

owice’s picture

I forget to tell you the following points:

1) My warning is at different line


warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in E:\wamp\www\includes\bootstrap.inc on line 856.
warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in E:\wamp\www\includes\bootstrap.inc on line 856.
warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in E:\wamp\www\includes\bootstrap.inc on line 856.
warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in E:\wamp\www\includes\bootstrap.inc on line 856.


2) I am using:

Drupal 6.22
CCk 6.x-2.9
Filefield 6.x-3.1

3) Run on Server with Windows Server 2008 64-bit as operating system and (Wamp server 2.1) running with the following properties :
php 5.3.4
mysql 5.1.53
Apache 2.2.17

4) The warning just appears at uploading page.

owice’s picture

Now I returned regional settings as it was before and the warning disappeared, but the files names returned to be question marks "?????". So I think the problem is with operating system.

I am wondering if there is somebody tell me how windows pass files names to drupal ... I think if we figure this out it may help a lot :)

Hope to read something new soon :)

Smiling is my weapon ... please don't interfere :D :D :P

Thanks for reading

owice’s picture

when I uploaded a file with question mark name "?????.dwg" the following error happened and the file wasn't uploaded:

warning: rename(sites/default/files/projects_related_files_temp/????.dwg,sites/default/files/projects_related_files_temp/????.dwg) [function.rename]: No error in E:\wamp\www\modules\filefield_sources\sources\attach.inc on line 213.
warning: filesize() [function.filesize]: stat failed for sites/default/files/projects_related_files_temp/????.dwg in E:\wamp\www\modules\filefield\field_file.inc on line 155.
The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.


interestingaftermath’s picture


centas’s picture

Encountered same issue.

Using: Core 6.19

my issue was that I have had some weird characters in a country list in my own module, and it was causing the problem. Changed them to english letter substitutes.

Heine’s picture

#61 is not the same issue; This is about filenames, not improper encodings in other systems. To solve your issue: save the module file as UTF-8.

PepeMty’s picture


Today, after updating Print (with it's library TCPDF) and Conditional Fields I'm having four warnings, on a different line:

warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /home/.../xxx.com/includes/bootstrap.inc on line 856.

Only after updating something. I still have more testing to do.

Any ideas?

Andrew Schulman’s picture

Ugh, subscribing. Could someone please provide a summary for this issue? More than a year later, have we even determined yet what the cause of this problem is? Thanks, Andrew.

Heine’s picture

See #13 and #41

wolf29’s picture

My error is showing up at line 856, and when I attempt the fix to suppress the error message my site is just a white screen.
I am using the Atrium profile and the site is utterly fresh, on postgresql database.
The errors were present before I started activating modules. It appears to be still present in core

Drupal 6.22
Ubuntu 10.04

Floop’s picture

If it appears when searching, take a look at #987472: search.module doesn't consistently support multibyte characters . The problem is caused by the search module. Fixing the search module fixed the error for me.

By the way the error can be also suppressed with PHP settings instead of touching the core.

Heine’s picture

This issue is about charset-problems handling files, not search.

Heine’s picture

Title:htmlspecialchars() Invalid multibyte sequence in argument in bootstrap.inc on line 840» filenames are not always UTF-8 resulting in complaints from drupal_valid_utf8 or htmlspecialchars


bserem’s picture

I'm subscribing and keeping an eye to it.

A site that just got into my hands shows this in the watchdog:
Warning: htmlspecialchars() [<a href='function.htmlspecialchars'>function.htmlspecialchars</a>]: Invalid multibyte sequence in argument in check_plain() (line 1152 of /home/example/public_html/includes/bootstrap.inc).

My problem has to do with urls. I transliterated all files on the system. But the information/patches that come up from this thread might also sove the problem with the urls.
I am thinking of transliterating urls, but the client might disagree...

NancyDru’s picture

I got this during a 6.22 to 7.9 upgrade. The offending "file" appears to be a new, disabled module that I had in my D7 sites/all/modules folder. This file had a .info file with

name = Résumé Builder
description = Helps you create a résumé to get a job and/or display online.

Apparently French users are going to have a serious problem updating to 7.9. I changed "é" to "e" and the update proceeded just fine.

mama21mama’s picture

Priority:Normal» Major

This same error is happening me to me.

htmlspecialchars(): Invalid multibyte sequence in argument en /media/Disco160/www/blog.mamalibre.com.ar/includes/bootstrap.inc en la línea 856.

openmode’s picture

warning: htmlspecialchars(): Invalid multibyte sequence in argument in /var/www/html/drupal/includes/bootstrap.inc on line 856.

Page Block admin - language italian

PHP Version 5.3.3-7
Drupal 6.22

andyboutte’s picture


NancyDru’s picture

fledev’s picture

I can confirm that the patch which is removing the " , 'UTF-8' " at line 856 && 858 solved my problem with
" htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /var/www/professional.cotyprestige.de/htdocs/includes/bootstrap.inc in Zeile 856. "

maksim24’s picture

i applied the patch which is removing the " , 'UTF-8' " at line 856 && 858 and i am waiting the result

goose2000’s picture

Subscribing, have this issue with D6.24 recent logs are :

cron 02/15/2012 - 11:00pm Cron run completed. Anonymous
php 02/15/2012 - 10:44pm htmlspecialchars() [

mattyoung’s picture

The exact error message I got is:

warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /var/www/html/drupal-6.24/includes/bootstrap.inc on line 860.

Enter here so search can find this issue.

fugazi’s picture

same problem as in #79

cilefen’s picture

same problem as in #79

Drupal 6.24
PHP 5.3.3
CentOS 6.2

rogeriodec’s picture

I was having this same problem #79 with Node Import module and solved by doing the following:

  1. Open your CSV file with software Notepad++
  2. Format > Convert to UTF-8
  3. Save

That's all.

cweagans’s picture

Priority:Major» Normal

Support requests are never major or critical.

SiteFish’s picture

I just experienced the same problem with a page on my site. I tracked it down to a block view where I display the most recent posts with a link to the post. In this view, node titles are output as links using the link path and the alt text from the two preceding hidden attributes [path] and [teaser]. The hidden teaser attribute is trimmed to a maximum of 400 characters on word boundary and HTML tags are stripped. This had always worked fine in the past.

However, after upgrading the site yesterday, I got the warning:
htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in ... bootstrap.inc on line 860

After some initital search I concluded that the warning occurred whenever the teaser contained a character coded as a named entity, e.g. &auml; for ä. Since ckeditor replaces special characters with named entities, this could very well happen quite frequently, especially for non-English users.

Removing the alt text from the view solved the problem. However, as I wanted to keep the alt texts, I instead decided to replace all named entities with special characters not using ckeditor. This also solved the problem for me.

Here is a summary of my relevant updates:
Drupal core from 6.16 to 6.25,
views from 6.x-2.11 to 6.x-2.16 and
ckeditor from 6.x-1.1 to 6.x-1.11

I hope this information will help to shed som light on the underlying cause of the problem.

SiteFish’s picture

Unfortunately, this was only a temporary solution. If I write a new post without ckeditor and place a named character in the teaser, the view produces the same warning as before. Alas, I will have to remove the alt texts until there is a fix available.

hedac’s picture

I have this issue too

htmlspecialchars(): Invalid multibyte sequence in argument in .../includes/bootstrap.inc on line 860.

but I don't know why yet.. I don't know how to debug it... but the pages seems to render correctly. I wonder if it is better to ignore it.. but it is a mess in the log.

hedac’s picture

if tried enabling mbstring in php.ini like:

mbstring.internal_encoding    = UTF-8
mbstring.http_input = auto
mbstring.http_output          = UTF-8
mbstring.encoding_translation = On
mbstring.detect_order = auto

then I don't have more errors in the log... but on drupal status page it says: Error
Multibyte string input conversion in PHP is active and must be disabled. Check the php.ini mbstring.http_input setting. Please refer to the PHP mbstring documentation for more information.

Finally.. the patch at #45 works.

beto_beto’s picture

I have this issue too

warning: htmlspecialchars(): Invalid multibyte sequence in argument in C:\inetpub\vhosts\example.com\httpdocs\includes\bootstrap.inc on line 860.

Any Suggestion !!!

Zorkoff’s picture

In my case, the special characters were actually invalid. I had imported data from a .csv Excel sheet using node import. The problem was that Excel converted characters like ” (which is a Mac created character, not ", the PC created character) into characters like ヤ. To fix it, I opened the original Excel sheet in OpenOffice Calc and then used it to create my .csv import file. I then updated my data in phpMyAdmin. I also could have used Node Export and Node Import Update in 6 or Feeds in 7. But I did have the original data, before it was corrupted by Excel's conversion. If you are starting with invalid characters, you may have to export your data and do a "find and replace" for each special character before updating the data. Just use OpenOffice Calc to do it because it had no problems correctly interpreting special characters created by Mac or PC. I should have paid closer attention to node import's warning "Non UTF8 files are generally generated by MS Excel if you choose CSV format (which you must avoid!)."

Sepero’s picture

Title:filenames are not always UTF-8 resulting in complaints from drupal_valid_utf8 or htmlspecialchars» htmlspecialchars - Invalid multibyte sequence in argument
Version:6.22» 6.28
Component:file system» forms system
Issue tags:-file encoding

I also got the same error as #79
htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in /home/sites/penguintutorials.com/public_html/includes/bootstrap.inc on line 860.

Also this:
User Guest
Location http://www.site.com/user/register
Referrer http://www.site.com/user/register

Perhaps this means that someone is trying to register on my site with a non-UTF8 name or password?

Theodores’s picture

Issue tags:+file encoding

This worked for me on PHP 5.3 - simply change #860 of bootstrap.inc to read:

        return htmlspecialchars($text, ENT_QUOTES | ENT_IGNORE, 'UTF-8');

First I tried a custom error handler (to find content that needed editing to UTF-8) and used the 'flog' module to write that to my own log file:

  if ($php525) {
    $return=htmlspecialchars($text, ENT_QUOTES | ENT_IGNORE, 'UTF-8');
    return $return;
  return (preg_match('/^./us', $text) == 1) ? htmlspecialchars($text, ENT_QUOTES, 'UTF-8') : '';
function errorHandler($errno,$errmsg,$errfile) {
flog_it("htmlspecialchars error");

Realising that it was too much hassle to edit the content (and that it was just cut and pasted from Word, therefore mostly harmless) I simply set 'ENT_IGNORE' on htmlspecialchars as outlined above.