UTF-8 BOM chars are being rendered on the page

[jlindenbaum]

Hi,

The 2.4 interface - without any alterations to config or similar - loads without problems.

The 2.4.1 interface - without any alterations to the config or similar - loads with ASCII preceeding the editor.

Here's my implementation:

<div id="newPostBox">

<?php include("./cn-fckeditor/fckeditor.php"); $fcke = new FCKeditor('content'); $fcke->BasePath = "./cn-fckeditor/"; $fcke->Create(); ?>

</div>

Here are the ASCII characters preceeding the interface. Contact me if you want a screenshot.



I am using the latest FireFox 2 and latest upgrades to IE 7 on XP SP 2 Professional.

Untested on different OS / in different browser.

Keep up the awesome work.

Regards, Johannes

[fredck]

Do you think you are able to attach a test case PHP page that shows us the problem? This thing seams to be related to the overall page structure, other that the encoding used to save it.

[fredck]

#286 is a DUP of this one.

[jlindenbaum]

Explanation will follow as comment by jlindenbaum

[jlindenbaum]

Here's the explanation for the overview.php

overview.php is part of our newest software development. The whole software is pre-alpha and will be released very soon as a beta under GPL / LGPL.

We, as usual, rely on FCKeditor as our wysiwyg editor, because hands down - it's the best.

Back to the poing. We are still using ISO instead of UTF-8 encoding. The file is included by a main file that includes / loads all other files. If you require that file I'll be pleased to post it.

[fredck]

It seams that the problem is that the fckeditor.php file contains the ​UTF-8 BOM since version 2.4.1. This is related to a bug on FCKreleaser.

As a quick fix, just save fckeditor.php without the BOM and probably things will start to work.

I'll be working to fix the FCKreleaser.

[bvanaerde]

Replying to fredck:

As a quick fix, just save fckeditor.php without the BOM and probably things will start to work.

When doing this, half of the characters are gone. Now it only shows "" instead of "". My guess is the BOM needs to be removed from another file too.

[bvanaerde]

When removing the BOM from fckeditor_php4.php (or fckeditor_php5.php, depends on which one you're using), all characters are gone.

[fredck]

Fixed with [226] and [227].

Click here for more info about our SVN system.

[fredck]

#310 is a DUP of this one.

[alfonsoml]

#344 has been marked as dup

[onpubco]

This bug appears to be back in the most recent subversion code, where the BOM (i.e.: ) is being rendered before the editor is rendered. This happens when using fckeditor.php to include fckeditor and when serving pages using latin1 encoding (my code is not UTF8 compatible, unfortunately).

[fredck]

Replying to onpubco:

This bug appears to be back in the most recent subversion code, where the BOM (i.e.: ) is being rendered before the editor is rendered. This happens when using fckeditor.php to include fckeditor and when serving pages using latin1 encoding (my code is not UTF8 compatible, unfortunately).

I've created a tool to check for UTF-8 BOM in PHP files at our trunk ([924]). The only file that was found was "_dev/releaser/fckreleaser.php". I've removed the BOM from that file too.

So, it seams that you are having a different issue.

[onpubco]

Fred, it looks like the UTF8 BOM is creeping in from fckeditor.html. If I re-encode this file from UTF-8Y to UTF-8 or latin1 then the problem goes away.

[onpubco]

Hi, the BOM also may be present in fckdialog.html or other code it's including.

[onpubco]

Wait, perhaps I was mistaken, I ran the fckreleaser.php script, and now it seems the BOM is no longer being outputted in the browser. I guess I shouldn't be trying to include the SVN code without first running fckreleaser.php. Sorry for any confusion this may have caused.

[fredck]

It is not a problem to have the BOM in .html files. You should be aware of .php files only.