ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68753
|
Tue Mar 6 15:08:23 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.
Stefan
Matej Sedej wrote: |
I see the same problem exists on this board as well. Actuall it appears only the attribute fields are affected. The č character was incorrectly written to the log file from the subject field above, but correctly from the body text below.
Matej Sedej wrote: |
Hello!
First of all, thank you for this great piece of software! For now it seems to perfectly cover our need to log very basic events, there was a setting for everything we wanted to set.
However we have one problem and that is the saving of the letter "č" (Slovenian) into the log files. That is unicode character U+010C and U+010CD https://unicode-table.com/en/010C/. When writing to the log file it is replaced with "Č" and "č". Is there a known fix for this?
Thank you and best regards,
Matej
|
|
|
68754
|
Tue Mar 6 15:29:38 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?
2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?
3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)
Thanks,
Matej
Stefan Ritt wrote: |
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.
Stefan
|
|
68755
|
Tue Mar 6 15:54:23 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file.
Stefan
Matej Sedej wrote: |
Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?
2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?
3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)
Thanks,
Matej
Stefan Ritt wrote: |
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.
Stefan
|
|
|
68756
|
Tue Mar 6 16:09:05 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.
Matej
Stefan Ritt wrote: |
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file.
Stefan
|
|
Draft
|
Wed Mar 7 15:15:27 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | So this is the result in the log file:
Opis: Test č Č
Attachment:
Encoding: HTML
========================================
<p>Test č Č body</p>
This is displayed as
Opis: Test č Č
Test č Č body
Stefan Ritt wrote: |
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file.
Stefan
Matej Sedej wrote: |
Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?
2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?
3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)
Thanks,
Matej
Stefan Ritt wrote: |
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.
Stefan
|
|
|
|
68762
|
Thu Mar 15 09:39:20 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:
red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.
orange sqare - This appears in translated menus and in the attribute "Prea" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.
pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.
I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.
Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej |
68763
|
Fri Mar 16 12:46:09 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
Matej Sedej wrote: |
To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:
red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.
orange sqare - This appears in translated menus and in the attribute "Prea" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.
pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.
I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.
Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej
|
|
68764
|
Fri Mar 16 14:12:04 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" | Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.
Stefan Ritt wrote: |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
|
|
|