Firebird Chinese Character set problem malformed string problem

FB defaults to building a library with the none character set, which is not really any character set, which handles strings as binary streams (arrays). Because of the character encoding reason, sometimes we want to look for "% King%" maybe some of the results are not the king of the data (sort is the same, perhaps the data order is a little weird). In addition, in character storage, the database does not have any validation of the string (we know that the character set's checksum is a correctness check), which causes the saved string to include any encoding (which seems to satisfy the need for flexibility), The problem is that when you take out a string, you don't know its character set, which can cause incorrect restores to appear garbled. None is not a question of fear. White Cat Black Cat pragmatism is also very pragmatic to the system and developers. Just understand the potential problems and how to solve them. FB's database character set does not seem to be changing. So you might want to see if the high version solves the problem or write yourself a data migration tool that guides data in two different character set databases. Simplified Chinese windows is the default file and the input encoding is GBK. But if your program is web-style or has a Linux client situation is slightly more complicated, because the Web and Linux in Chinese may be UTF encoding, which will result in garbled or incorrect query results. If the database is set to GBK, the database side verifies the output in Chinese, rejects the UTF character input (malformed string), and also gives you a timely reminder that the encoding needs to be set correctly. How to set up the encoding has two parts: 1, database character encoding. This is relatively simple, set up the library statement. 2, the database Client connection code selection. This is related to the way you choose to connect. such as Java jdbc:firebirdsql://localhost//home/databases/sample.gdb?lc_ctype=gb2312 The connection is encoded by telling the server that the client's string is encoded. So the simplified Windows client is GB2312/GBK, but if your database settings are none there is no need to tell the server.

Malformed String

If you have this error, it usually means the "client is not able to transform" the string you wrote to the character set Acceptable to the Firebird server. Here's a short explanation how this works:

In your client program, your type in some text, which be then shown on the screen. This text has the same character set like the rest of your environment. Typically it is UTF8 on Linux, and various win-xxxx charset on Windows (WIN-1252 in Western Europe, WIN-1250 in eastern Eu Rope, etc.).

Your Client tool should then transliterate this to the connection character set of Your Firebird Connection, and the Fireb IRD server transliterates that to the character set of the actual columns when it stores the string into the database. If your client tool is isn't ' smart ' enough to doing the transliteration, you should set the connection character set to being the Same as your environment character set. For example, if you are using isql and have a west-europe Windows, you should type this at the beginning of your isql On

SET NAMES WIN1252;

With this, the can even work with UTF8 databases while using isql. Some tools (like, for example, Flamerobin) are more advanced and does the needed for your, so you can use SOM e Other character set for connection (for example UTF8) without problems.