Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Faceted Browser UTF-8 encoding issue #141

Open
jakubklimek opened this Issue · 14 comments

2 participants

@jakubklimek

Property and Object labels have a wrong encoding of international characters.
fct 1.13.56 in 7d38d12

See the second object of the last property (should be Březiněves, as it is when I click on it - the second screenshot)
image
http://ruian.linked.opendata.cz/resource/obce/554782

image
http://ruian.linked.opendata.cz/resource/katastralni-uzemi/614131

However, on the last page of http://ruian.linked.opendata.cz/resource/katastralni-uzemi/614131 (http://ruian.linked.opendata.cz/describe/?url=http%3A%2F%2Fruian.linked.opendata.cz%2Fresource%2Fkatastralni-uzemi%2F614131&p=1&lp=15&op=-1&last=&gp=1) the same characters are OK, which seems a bit strange:
image

@HughWilliams
Collaborator

Is this still an issue as I do not see the utf-8 encoding issues on your screenshots when I access the live pages on my browser ?

/Users/hwilliams/Dropbox/Screenshots/Screenshot 2014-03-09 13.29.35.png

@jakubklimek

I still have this issue when I access http://ruian.linked.opendata.cz/resource/obce/554782
image
in fct 1.13.57

@HughWilliams
Collaborator

Has anything changed in the Virtuoso Server instance as the page http://ruian.linked.opendata.cz/resource/obce/554782 , does not load with the corrupt characters as in your screenshot above:

screenshot 2014-06-22 21 37 44

@jakubklimek

No, but the texts are in Czech. So when I view it from here, they load because of my location I guess and they don't load for you. I think that adding &lang=cs to the url should do the trick.

@jakubklimek

@HughWilliams This is still happening, database here, dont forget the &lang=cs as you will not be autodetected to be in cs environment.

@jakubklimek

Plus, now it looks like this: (notice the font):
image which is probably the same bug as was fixed in a614876 however that was in sparql endpoint, in fct it is still there. However, only in some Chrome instances, which is weird.

@HughWilliams
Collaborator

@jakubklimek: What is the URL to load as assume it http://localhost:8890/resource/obce/554782 having setup the test database on http://localhost:8890 , but I get a 404 error:

Error HTTP/1.1 404 File not found
The requested URL was not found URI = '/resource/obce/554782'

@jakubklimek

@HughWilliams That is rewritten by Apache to form correct and resolvable Linked Data URIs. For your instance it will be http://localhost:8890/describe/?url=http://ruian.linked.opendata.cz/resource/obce/554782&lang=cs

@HughWilliams
Collaborator

Loading the page http://localhost:8890/describe/?url=http://ruian.linked.opendata.cz/resource/obce/554782&lang=cs , I do not see the UTF-8 encoding issue you report, see screen shot attached:

screen shot 2015-01-24 at 15 16 44

@jakubklimek
@HughWilliams
Collaborator

@jakubklimek: This looks like a browser rendering problem as if I view the source of the page I see:

title="Typ MOMC, na něž je statutární město rozčleněno">Typ MOMC, na něž...�sto rozčleněno

@jakubklimek

So the weird character is generated by browser?

Anyway, I have narrowed it down to an issue in combination with apache mod_proxy_html... I am using that to do the URI resolvablility. When I display the page directly via /describe/?url=... It looks like on your screenshot. However, when I use the resolvable uri via Apache, it is transcoded for no apparent reason - the output document is still utf-8 encoded, but all the special czech characters are destroyed. I am playing with Apache mod_proxy_html now but could not find a solution yet

@jakubklimek

OK, I found the solution and tested it with a copy of the html page generated by fct. The issue is described here: http://serverfault.com/questions/559518/mod-proxy-html-garbles-non-ascii-characters

Could you add the missing <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> tag to fct generated XHTML output? When this is added there, mod_proxy_html detects the encoding correctly and does not destroy the characters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.