You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Mark Hissink Muller <XM...@kombit.dk> on 2020/02/25 15:08:24 UTC
Encoding problem when retrieving result from QueryEngineHTTP
Hi all,
I am trying to solve an encoding problem between a Java client, which is a Spring Boot server application that runs on Windows, and a rdf4j-server running on Tomcat 8 on Ubuntu 18.04 LTS.
I should retrieve correct data with Danish characters (e.g. "Fælles forståelse") from the server, but instead I get the ASCII-interpretation ("Fælles forstÃ¥else").
I've observed the following:
- The client application generates a Model with the correct UFT-8 encoding.
- The client application correctly inserts model in the server via the Atomgraph InsertDataBuilder and RDFConnectionFactory.connect(postUrl); insertConnection.update(insertRequest).
- The rdf4j-server then contains the correct context, as I can see in the rdf4f-workbench. (The presentation of the data in the workbench seems ASCII/ has garbled Danish characters, but when I double-click to edit the data and a form opens, I can see that the characters are represented correctly.)
But when I then query the repository from my client application again, I retrieve ASCII (or it seems), instead of the correct UTF-8 encoded data.
I use the following straightforward approach for the SELECT query:
Query query = QueryFactory.create(queryString);
QueryEngineHTTP qexec = QueryExecutionFactory.createServiceRequest(getEndpoint(), query);
ResultSet resultSet = qexec.execSelect();
while (resultSet.hasNext())
{
QuerySolution querySolution = resultSet.next();
resultMapper.processQuerySolution(querySolution);
...
}
I could not find a way to force the QueryExecutionFactory or QueryEngineHTTP to interpret the returned ResultSet as UTF-8.
Does anyone have a solution or idea how to address this...? Much appreciated.
Kind regards, Mark
Re: Encoding problem when retrieving result from QueryEngineHTTP
Posted by Andy Seaborne <an...@apache.org>.
On 25/02/2020 15:08, Mark Hissink Muller wrote:
> Hi all,
>
> I am trying to solve an encoding problem between a Java client, which is a Spring Boot server application that runs on Windows, and a rdf4j-server running on Tomcat 8 on Ubuntu 18.04 LTS.
>
> I should retrieve correct data with Danish characters (e.g. "Fælles forståelse") from the server, but instead I get the ASCII-interpretation ("Fælles forstÃ¥else").
Looks like ISO-8859
>
> I've observed the following:
> - The client application generates a Model with the correct UFT-8 encoding.
> - The client application correctly inserts model in the server via the Atomgraph InsertDataBuilder and RDFConnectionFactory.connect(postUrl); insertConnection.update(insertRequest).
> - The rdf4j-server then contains the correct context, as I can see in the rdf4f-workbench. (The presentation of the data in the workbench seems ASCII/ has garbled Danish characters, but when I double-click to edit the data and a form opens, I can see that the characters are represented correctly.)
Unclear.
>
> But when I then query the repository from my client application again, I retrieve ASCII (or it seems), instead of the correct UTF-8 encoded data.
How are you displaying that in your application?
Are you running on MS Windows?
>
> I use the following straightforward approach for the SELECT query:
>
> Query query = QueryFactory.create(queryString);
> QueryEngineHTTP qexec = QueryExecutionFactory.createServiceRequest(getEndpoint(), query);
> ResultSet resultSet = qexec.execSelect();
> while (resultSet.hasNext())
> {
> QuerySolution querySolution = resultSet.next();
> resultMapper.processQuerySolution(querySolution);
> ...
> }
>
> I could not find a way to force the QueryExecutionFactory or QueryEngineHTTP to interpret the returned ResultSet as UTF-8.
Jena applies HTTP content negotation.
If you can provide a public URL, I'll look at the HTTP request.
Otherwise, please get the HTTP headers (use curl or wget)
>
> Does anyone have a solution or idea how to address this...? Much appreciated.
>
> Kind regards, Mark
>