Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Does not render UTF-8 correctly #209

Closed
ghost opened this issue Feb 15, 2019 · 7 comments
Closed

Does not render UTF-8 correctly #209

ghost opened this issue Feb 15, 2019 · 7 comments

Comments

@ghost
Copy link

ghost commented Feb 15, 2019

This template:

<!doctype html>
<html>
<head>
<title>Index</title>
</head>
<body>
↰ ..
</body>
</html>

results in:

↰ ..

Even trying to explicitly set the charset to UTF-8 fails:

let body = render_template(&filepath)
            .respond_to(&request)?
            .replace_body(actix_web::Body::Empty);
        Ok(HttpResponse::Ok()
            .content_type("text-html; charset=utf-8")
            .body(body))
@zzau13
Copy link
Contributor

zzau13 commented Feb 16, 2019

The problem is in the implementation of actix_web. Try that template in this example, https://github.com/djc/askama/blob/master/testing/tests/actix_web.rs, and recomment, please.

@djc
Copy link
Owner

djc commented Feb 17, 2019

I'm skeptical that Askama is the problem here, since it has tests to make sure it handles UTF-8 correctly (though not specifically the Actix-Web test). Also, I don't know what your render_template() snippet is supposed to do, but it does not look like that's using Askama.

@ghost
Copy link
Author

ghost commented Feb 21, 2019

Here's a quick example:

#[derive(Template)]
#[template(path = "chart.html")]
struct ChartTemplate<I>
where
    I: IntoIterator<Item = DataPoint> + ::serde::Serialize,
{
    data: I,
}

#[derive(Serialize)]
struct DataPoint {
    x: f64,
    y: f64,
}

impl From<(f64, f64)> for DataPoint {
    fn from((x, y): (f64, f64)) -> Self {
        DataPoint { x, y }
    }
}

fn stream_chart_page(
    data: impl IntoIterator<Item = DataPoint> + serde::Serialize,
) -> BackendResult<impl Responder<Item = HttpResponse>> {
    Ok(ChartTemplate { data })
}

@djc
Copy link
Owner

djc commented Feb 21, 2019

That doesn't actually show any string contents...

@ghost
Copy link
Author

ghost commented Feb 27, 2019 •
edited by ghost
Loading

The test passed, but the issue is how Firefox interprets the content type. It has to be text/html; charset=utf-8 for it to display the correct characters. This appears to be correct behavior from first pass:
https://www.w3.org/International/articles/http-charset/index

Default behavior with askama is to only show text/html. It looks like this is because of mime_guess - askama uses its output to override actix_web's default, but mime_guess doesn't include a charset:

impl<T: super::Template> TemplateIntoResponse for T {
        fn into_response(&self) -> Result<HttpResponse, Error> {
            let rsp = self
                .render()
                .map_err(|_| ErrorInternalServerError("Template parsing error"))?;
            let ctype = get_mime_type(T::extension().unwrap_or("txt")).to_string();
            Ok(HttpResponse::Ok().content_type(ctype.as_str()).body(rsp))
        }
}

Looks like mime_guess is possible of providing a charset with the mime_type from a cursory look at the API:
https://docs.rs/mime_guess/2.0.0-alpha.6/i686-pc-windows-msvc/mime_guess/struct.Mime.html

I'm guessing this doesn't happen here due to it only having the extension and not the file content? But in this case I think askama templates are explicitly UTF-8, so you could probably add it.

It looks like regardless you can work around this by setting a <meta charset="utf-8"/> tag in the HTML, but this obviously isn't desirable.

@djc
Copy link
Owner

djc commented Feb 27, 2019

Providing mime_guess with UTF-8 charset sounds about right, can you do a PR?

@spease spease mentioned this issue Mar 10, 2019
Closed
@vallentin
Copy link
Collaborator

Closing, as it was fixed in #219.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@djc @zzau13 @vallentin