Recent

Author Topic: Problems with conversion from UTF8  (Read 452 times)

Ever

  • Jr. Member
  • **
  • Posts: 77
Problems with conversion from UTF8
« on: January 11, 2025, 04:09:39 am »
Greetings
I present the situation:
I have a MySql 8 database in UTF8mb4 on Windows, which has a product inventory table.
I have another database in Firebird in ISO8859_1 in 32 bits where I store the same product inventory table.
It is designed this way because the billing by obligation must be done in 32 bits for reasons of communication with the fiscal printer (the supplier only delivers a dll that works in 32 bits to send information to the device).
I designed a program that passes the information from one database to the other to be able to operate the billing module, but I find the inconvenience that I cannot properly convert from UTF8mb4 to ISO8859_1. It does not correctly pass the letters with accents. First image.
I tried to design the Firebird database in UTF-8, visually everything looks correct but it stores the data with garbage and when trying to do a search I cannot find the information. Second image.
Any suggestions that can help me overcome this problem?
« Last Edit: January 11, 2025, 04:11:56 am by Ever »

robert rozee

  • Full Member
  • ***
  • Posts: 197
Re: Problems with conversion from UTF8
« Reply #1 on: January 11, 2025, 12:35:45 pm »
there will be a set of characters that can be encoded in UTF8mb4, and another set of characters that can be encoded in ISO8859_1. while there will be many characters that are common to both sets, there will be some that can only be represented in one or the other.

one approach would be to store each string in multiple formats: ASCII (without accents), UTF8mb4, and ISO8859_1. then you can do searches on the ASCII version of any given string, while 1) presenting the user on-screen with the UTF8mb4 string and 2) when printing sending the ISO8859_1 to the "fiscal printer" (i have no idea what a 'fiscal' printer is).

the easiest way to introduce this sort of change is to NOT perform any conversions initially, instead arranging the user front-end so that whenever it encounters a field with one or more encodings missing, the user is prompted to enter the missing one(s) manually. while generating a degree of additional work for the user initially, over a period of time the number 'missing fields' will slowly decline.

to what extent does this sort of solution solve your problem?


cheers,
rob   :-)

Ever

  • Jr. Member
  • **
  • Posts: 77
Re: Problems with conversion from UTF8
« Reply #2 on: January 11, 2025, 03:53:55 pm »
Thank you for your response. In my country, a fiscal printer issues invoices for the tax collection agency, recording the issued documents in an internal memory for later audits.

 

TinyPortal © 2005-2018