Invalid Chars in activeTextArea

I have a form ( similar to the blog demo ) that displays a post. At some point I had copied and pasted text from a web page to display test data. The post entries with simple text display fine, but the ones I copied from the web pages do not - nothing is displayed. This is my standard form element:

<?php echo CHtml::activeTextArea($post,'Content',array('cols'=>100,'rows'=>20)); ?>

If I just echo the post value to the screen, the data is there and it shows up. There also doesn’t appear to be any html formatting in the text. At any rate, I know the data is in the array object. However, if I try to put the data into a static html textarea I get giant leading and trailing characters (not sure if they are valid spaces or not), even if I use the trim function.

<textarea rows="20" cols="100">


   data = trim($post->Content);

   echo $data;



When I do the above I have what appears to be leading and trailing spaces. I’ve tried several variations on creating my own trim function, including removing all spaces, but with no luck. I’m beginning the think that the spaces aren’t in the data at all but have more to do with something php is doing. Anybody seen this? I’d like to be able to use the Yii activeTextArea but I haven’t had any luck get it to work either and I’m not sure why it’s broken by the characters in the data. Any help would be appreciated.

After going through the characters one at a time I discovered what was causing the activeTextArea to not display the text. Not sure if this is a bug or by design but seemed to have stumbled across it accidently.

The character that was causing this was an extended ascii character 150 which is described as "En dash". 



This character was used as a dash character I copied off a web page from CNN I think.

At any rate replacing the 150 with a standard dash 45 fixed the problem with the activeTextArea. Still not sure about the extra leading and trailing spaces issue.

Have you tried this in different browsers? The textarea should be able to display en and em dashes without problem. I’ve tried without problem copying and pasting the text from the last paragraph of the following page into a textarea field, saving it, and redisplaying it:

The leading and trailing spaces have probably been caused by the way you have formatted your code. Anything between the textarea opening tag and the PHP opening tag, and anything between the PHP closing tag and the textarea closing tag will be displayed in the text area. For example:

<textarea rows="20" cols="100">*


        $data = "This &ndash; is an en-dash, and this &mdash; is an em-dash.";

        echo $data;



The above code will display the following:


    This – is an en-dash, and this — is an em-dash.    *

This is a safer way to display the same information:


    $data = "This &ndash; is an en-dash, and this &mdash; is an em-dash.";    


<textarea rows="20" cols="100">*<?php echo $data; ?>*</textarea>

The updated code will display:

*This – is an en-dash, and this — is an em-dash.*

Here’s some code that you can use to test the textarea without using Yii. This should help narrow down your problem. Enter it into a new PHP file called textarea.php:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

<html xmlns="" xml:lang="en" lang="en">


		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

		<meta name="language" content="en" />

		<title>Textarea Example</title>



		<form id="form" action="/textarea.php" method="post">

		    <p><label for="input">Enter text to be tested here:</label></p>

		    <textarea id="input" name="input" rows="20" cols="100">Enter text here</textarea>

		    <p><input type="submit" name="send" value="Send" /></p>

		    <p><label for="output">Your text will be output here:</label></p>

		    <textarea id="output" name="output" rows="20" cols="100"><?php if(isset($_POST['input'])) echo $_POST['input']; ?></textarea>




It’s quick and dirty, but it works. Copy and paste some text into the first textarea, press Send, and it will be displayed in the second textarea.


Thanks for the responses. I’m using IE 8. I didn’t check other browsers. Not that I love IE, but if it doesn’t work in IE then the majority of the people who hit my site are going to have the same problem. If you don’t have the problem then it may be IE, or Windows since I am using Win7 as my development box. Either way it is a peculiar problem. I also found another character that did the same thing. I didn’t check the code but it was a common replacement for a single quote like when you say John’s …

I did try the link and paragraph you sent me and it does the same thing. Do you think it could be SQLite ?

I’m going through my code to see if I changed something from the blog example that may have caused this. If nobody else has experienced this, then it’s got be something I’ve done.

Also, you were correct about the formatting of the textarea. Putting the statement all on one line fixed it.

Thanks for you help.

I don’t know much about SQLite, but it is possibly the root of the problem. Does your version support UTF8? Did you try the code snippet above, to determine if you encounter the same problem without Yii or SQLite?


Finally, got around to testing the code and it worked fine. So, what does this tell me… Doesn’t seem like a browser issue. Don’t think it is SQLite as the data is being captured in the database and retrieved. If I just echo the data out it displays properly. This probably also means that AR is not causing the problem. That pretty much only leaves CHtml activeTextArea. I’ll look further into this. If you come up with any more suggestions please post them.


I did some testing in the yii source code and the problem was in the CHtml.encode function. This function uses the PHP htmlspecialchars function to remove special characters. However, this function only works with UTF-8 encoded (or since that what I have my encoding set at that’s what php was using)characters and the problem character was an extended ascii character. So, I solved the issue by using a function to replace extended ascii codes with regular ascii codes, and then strip out whatever I missed. So, the issue seems to be resolved now. Thanks for everyones input.