thank you - i am aware of this, but still wonder where the encoding on
my end goes wrong. it would be very helpful if the fuseki server would
log the input it receives for errors in the 'insert data' case. it does
show my input (as it is received) if i url-encode it (which is an error
with message and produces a copy of what is received). it does not show
this in the case of incorrect utf8 characters but this would be very
helpful to under stand where in the stack the problem lies. i will
experiment more.
do you have a suggestion for a simple "web sink to log"? could ntop be
used to capture the request and identify what is sent my end? any
suggestions on details how to?
than you a lot for your help!
andrew
--
em.o.Univ.Prof. Dr. sc.techn. Dr. h.c. Andrew U. Frank
+43 1 58801 12710 direct
Geoinformation, TU Wien +43 1 58801 12700 office
Gusshausstr. 27-29 +43 1 55801 12799 fax
1040 Wien Austria +43 676 419 25 72 mobil
On 03/28/2017 11:48 PM, Andy Seaborne wrote:
>
>
> On 28/03/17 22:05, Andrew U Frank wrote:
>> i found that encoding the literals in the requests as latin1 i do not
>> see errors and the triples are stored.
>>
>> is this intended behaviour? for now, i have a work around.
>>
>> i look forward to your analysis of the code? when i look at the java
>> error message, i sense that there is a encoding selected? is it UTF8 or
>> latin1?
>>
>> thank you for maintaining fuseki!
>>
>> andrew
>>
>>
> For some (not all) iso-8859-1/latin1 characters, sending and reading
> back as if it were UTF-8 works. Its the wrong character in the
> database ("�") but the reverse undoes the damage. This is not true of
> all of latin-1.
>
> Andy
