Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add meta tag with charset information to application layout.

Previously, our default HTML would validate properly, but would generate
a warning: it doesn't declare a character encoding.

According to [the spec][encoding-spec], if you don't specify an
encoding, a 7 step algorithm happens, with a toooon of sub-steps. Or, we
could just actually specify it.

Since everything else in Rails assumes UTF-8, we should make sure pages
are served with that encoding too. This meta tag is the simplest way to
accomplish this.

More resources:

* http://blog.whatwg.org/the-road-to-html-5-character-encoding
* http://www.w3.org/International/tutorials/tutorial-char-enc/
* http://validator.w3.org/

[encoding-spec]: http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding
  • Loading branch information...
commit ba0407337e93c4ef55cef3472143f62e8a984a64 1 parent e7facb3
@steveklabnik steveklabnik authored
View
1  railties/lib/rails/generators/rails/app/templates/app/views/layouts/application.html.erb.tt
@@ -1,6 +1,7 @@
<!DOCTYPE html>
<html>
<head>
+ <meta charset="utf-8">
<title><%= camelized %></title>
<%- if options[:skip_javascript] -%>
<%%= stylesheet_link_tag "application", media: "all" %>

4 comments on commit ba04073

@jeremy
Owner
According to [the spec][encoding-spec], if you don't specify an
encoding, a 7 step algorithm happens, with a toooon of sub-steps. Or, we
could just actually specify it.

This makes it sound like adding the meta element bypasses the HTML5 charset determination. Rails already serves content using utf-8 charset, and that's checked before parsing the HTML.

For even quicker determination, use a UTF-8 BOM.

:-1: on this; it's not needed.

@steveklabnik
Collaborator

What do you mean by 'rails serves'? Wouldn't this be the webserver's responsibility? Or do you mean we add a header by default in the right place?

I prefer this way because there's less moving parts, but I can see how a reasonable person would disagree.

@nimf

I'm always adding this myself :+1:

@tenderlove
Owner

@steveklabnik Rails sends the encoding along with the content-type header back to the proxy. We default it to utf-8. However, if you override the content-type header all bets are off.

I'm reverting this because if someone sets the charset on the response (like you're currently supposed to do) to something other than utf-8, then this tag will be wrong.

One improvement I suggest that we make is to make the charset respect the external encoding settings. I'm not sure why we don't do that (it seems like a bug).

Please sign in to comment.
Something went wrong with that request. Please try again.