Re: unicode special characters replacements

null@example.com (oakstreet1) — Tue, 24 Sep 2019 21:20:07 +0000

FrontAccounting escapes all values before storing them. If you are storing values directly, you should use the same escaping mechanism. It can create some serious problems if you have a limited char() or varchar() field and suddenly you can't fit a 10 character string in a 15 character field because the escaping expands some characters into 4.

Having said that, it's not going to change anytime soon, so you may have to adapt your code accordingly.

unicode special characters replacements

null@example.com (chem75) — Tue, 24 Sep 2019 19:00:37 +0000

The way fa insets/updates data in the database is by replacing certain special characters with their HTML entities equivalents. If I enter subscript 0,1,2, and 3, U+2080, U+2081, U+2082, U+2083, they are recorded as & 8320;, & 8321;, & 8322;, and & 8323;. If enter directly in the database they show as ? on both the screen and in the reports. superscript 0,1,2, and 3, U+00B0, U+00B1, U+00B2, and U+00B3, are recorded as unicode in the database; ³ is recorded as ³, and show correctly on the screen and the reports.

Is there an easy way to add the remaining 4-9 superscripts and 0-9 subscripts to the list so they show properly? Can you explain why the U+00B0, U+00B1, U+00B2, and U+00B3 values are recorded as unicode? I tried !@#$%^&*() with the result of !@#$%^& amp;*() so it appears that & is the only one being replaced by the html equivalent for the more common characters. The database is utf8mb4.

FrontAccounting forum — unicode special characters replacements

Re: unicode special characters replacements

unicode special characters replacements