Consider the possibility that this is a font issue, and not an encoding issue. Every font used to display a character has an index, but not every index in a given font has a graphical glyph to render it. I would try to convert the characters to hex first and see if something in the viewing is simply not rendering a character that is there...a basic string length test. If the character really is UTF-8 then it is always a single byte and the database should not care...treating that character as a particular font is when things go bad. I had some similar strange issues in DocBook. Changing default fonts solved them. The case was that illustrating a directory tree used some box drawing symbols which showed up fine in my terminal, and copy and paste into the editor also showed up well...but the generated PDF and HTML output was missing the character (it was substituted with a "missing character" symbol). The problem was that those indices into my terminal font had a different glyph than Times-Roman and Helvetica, which the PDF and HTML output used...Times-Roman and Helvetica do not have the box drawing characters (the index exists, the glyph does not). Switching to DejaVu and DejaVu Sans caused the character to show up again. During the entire set of events of transferring and viewing those characters, including things like mouse copy and paste, what font is used in cases where font is relevant? ----- Original Message -----From: Ingo Wolfmayr <[email protected]>To: '[email protected]' <[email protected]>Sent: Fri, 31 Mar 2017 09:39:22 -0000 (UTC)Subject: Special char
Hi everybody, I have a question regarding special chars: Environment: Ofbiz trunk, Mysql 5.6Entity Engine: collate="utf8_unicode_ci", jdbc-uri="jdbc:mysql://localhost/ofbiz_test?autoReconnect=true&characterEncoding=UTF-8" I have the following strings:1) Käse2) Akrapovič The first one is working. The second becomes Akrapovi? Both strings work in the online demo. Does anyone has an idea what I may do wrong? Best regards,Ingo
