HOw to convert CSS file back into UTF-8?

Is there a a way to convert a css file that has been saved by accident in non UTF-8 format and now only shows up all on one line??

The question is simple and most people have encountered it at one time or another, but I can’t seem to find any answers or even discussions about what happens when it’s saved incorrectly and if there is a way to fix it or change it back…other than backups.

I’ve been designing for years and have luckily never done this before because I always keep good backups and procedures, but somehow, I don’t even know how, the file saved with all of the text on a single line! And of course the one time I’ve ever done this, and it’s on a file that I spent hours changing major CSS designs and somehow didn’t save a backup.

Also, what are all of the reasons for something like this happening, because I’ve never actually learned how it all works precisely and I would like to figure out what I did wrong. And to make sure I didn’t screw up any other files on a site in the past few days of work! I use Notepad ++ usually and know the differences of how Notepad, Wordpad, Notepad++ …and this file displays all in one line in all editors. This site is on a server I’ve never used before and I’m building in Wordpress which I rarely use. What are all the factors which might change the encoding down the line? (ie text editor, ftp software, server, cms, etc etc). I haven’t had this happen very many times so I just never learned it.

I usually begin my CSS file with: @charset “utf-8”; on the first line. Apparently this does not work if any other text, including notes, precedes it. Also, when saving or resaving the file in a good text editor, there should be an option to choose UTF-8 as opposed to ASCII. Ultra-Edit also offers the option to save UTF-8 without the byte-order mark (BOM) which can cause problems.

Also, have you tried rendering the contents of the file as text in a simple page of HTML (marked-up with the UTF-8 charset, of course)? If it is readable to the human eye, then I would copy and paste the content from the page into the original file and resave it with the UTF-8 option.

It’s not about UTF-8 or ASCII code. It’s all about Carriage Returns and Line Feeds or some combination thereof. If my memory is working tonight, PCs use CR/LF, I think Macs uses LF, and Unix/Linux uses CR. Transferring a text file between OS’s can invite a loss of formatting or altered formatting. Clicking the equivalent of a “Delete Line Breaks” button in a text editor can do the same thing. I’m sure there’s more. I don’t know of a way to restore deleted line breaks except from backup.

@Enver - I do know about encoding options in text editors and that’s usually when I screw this up, but what’s weird is I have had Notepad++ open for a really long time with other css files from other sites AND this site, but all are ok and open back up properly. Go figure.

As for your question…

“Also, have you tried rendering the contents of the file as text in a simple page of HTML (marked-up with the UTF-8 charset, of course)? If it is readable to the human eye, then I would copy and paste the content from the page into the original file and resave it with the UTF-8 option.”

I’m not sure what you mean by that. It sounds like you say to save it as .html with UTF-8, open it in a browser, then copy and past into a text editor and save as UTF-8? That didn’t sound like it would do anything, but I tried anyhow and it didn’t do anything. Maybe I mis-interpretted what you said?

ALSO, the css file has a “@media” at the beginning of it, could that make a difference? This is a client’s template I did not code from scratch.

I actually thought the same thing, but here’s what actually happened…

I had the file open in Notepad ++ editing, then uploading to the server. A few hours later I went back to edit the file again, but for some reason decided to download the most recent file from the server because I thought I may have edited the one on my computer and then decided not to go with the changes (I do that sometimes). So I wanted the exact file from the server. At this point, I usually backup the one on my computer (call it backup_delete_later or something) and then download the one from the server. But I just skipped the backup not thinking (probably because I’ve done this procedure countless times without error) and downloaded and over-wrote it. Opened it up and it was now all on one line.

So, it’s either the editor saved it that way or somewhere between the editing and uploading that messed up. What’s weird is that I had other css files open and editing as well and they’re all fine! That’s why I’m stumped and want to figure out what I did wrong so I don’t do it again. But more importantly, I not have a messed up file that will take me a very long time to sift through for changes, or redo all of the changes I made again (not fun because there were lots of changes sitewide so catching them all would be a pain).

My solution right now if I don’t hear anything better, is to use an editor that will create line breaks after every “}” so at least I can compare an older backup with the new code.

I just looked back at the original CSS file and it’s not just @media at the top, the entire file is this…

@media screen {

  • { margin: 0; padding: 0; }
    html { background: #c8c862 url(…/images/bg.jpg); }
    etc etc etc…all css declarations here

} /* END print media */

Would that have anything to do with it? I can’t think of a reason why that would make any difference, but I’m not 100% certain

ftp can indeed cause the loss of line breaks. The text transfers should use a binary protocol, not ASCII. If ASCII, the eol can/will be lost, as I recall (it’s been quite a while <smile>). You should be able to find something about this on the web.

If the server defaults to an ascii transfer protocol instead of binary, then there is a risk that your editor or local ftp program may connect using ascii instead of binary, if there is no bom to instruct otherwise. I think that’s the possibility I remember. The text files need to have a real embedded BOM to assure success.

@awiserlife : I defer to ronpat’s suggestion about carriage returns. I’m sorry, I missed the fundamental point that your file seems to have had all of the carriage returns stripped. That said, a good text editor or IDE will offer options to correct the problem with a choice of DOS, Unix or Mac terminators. The Ultra Edit IDE that I mentioned above certainly offers the option in the ‘Save’ dialog whereas Notepad does not as far as I can tell from the version I have running on Windows XP. It would be a simple enough matter to replace the carriage returns in Ultra Edit using Find/Replace if they have been irrevocably lost in the transfer.

If the @charset “utf-8”; rule makes any difference at all, it will only do so if it precedes the @media rule. That is to say that it must be the very first line of the CSS file. I don’t believe that it would affect an @media rule following it on the next line. However, as ronpat pointed out, your problem isn’t to do with UTF-8 or ASCII encoding.

Note: It’s slightly beside the point and I am by no means an expert programmer but I would strongly suggest using an IDE rather than Notepad for editing HTML, CSS and code in general. The coloured syntax highlighting usually offered by a good IDE makes it much easier to see what is happening to the mark-up in files. You may not be aware how many fairly obvious errors you are overlooking when using a plain text editor like Notepad. Even a relatively straightforward CSS file can be messed up with an unterminated note.

Like Enver, if all else fails I would suggest a find and replace. So in the find box, type “}”, and in the replace box type “}” with a return or two after it.

@ronpat, that makes sense and probably what happened. I perhaps may have saved in ASCII instead for files during that time and when it transferred I happened to lose the info on that one transfer like you mentioned. It’s the only thing that would explain why this only happened to the one file and not all the other ones I was working on too. And I forgot to mention, a majority of the other files I was working on were actually for a different website with different server all together, or they were php files. This website in particular only has a few css files and I don’t recall if I changed any of the other ones when this happened. And now that I think about it, it’s possible this was the only file I uploaded because I was working in the backend of Wordpress for the php files. This is why I was asking about server specific differences. I may just try some files out on the server to see what happens.

@Enver, I’ll try the Ultra Edit IDE and see if I can find anything to fix it, but it looks like I’m going to go the find and replace way as it sounds like the file has lost all of it’s info. :confused:

@Enver, just an fyi, Notepad++ has everything you mentioned about the color coding and code help like many other web design editors. I really like it because it’s very straight forward, simple, opens and saves files well, has color coding, automatic indentation, and highlighting where you start and stop your tags is just great for making sure you get everything coded correctly. I don’t find any other additions than those to ever be of any use for me and usually come along with code-stripping or code “fixing” that usually creates more of a mess than help. I’ll check out the IDEs though and see how they are in comparison.

I’m glad you mentioned that. I couldn’t imagine putting the simple version on my PC to any good use whatsoever - from way back when I have terrible memories of using Notepad to edit pages and pages of HTML on Windows 98. If the more advanced version has everything you need then you probably don’t need to bother with an IDE. I guess I’ve just grown into using one over the years, despite the fact that I’ve only recently gotten into serious coding. The program I use doesn’t offer to fix anything (although I haven’t bothered trying to find whether or not it can be configured to do so) but it does have some useful features that I couldn’t work without these days. It’s also extremely fast and certainly very good for Find/Replace actions over whole batches of files and folders.