Re: Facing issue in using special characters

Поиск
Список
Период
Сортировка
От Gunther
Тема Re: Facing issue in using special characters
Дата
Msg-id c69d480d-89c4-f2c6-83bb-d0202785211b@gusw.net
обсуждение исходный текст
Ответ на Facing issue in using special characters  (M Tarkeshwar Rao <m.tarkeshwar.rao@ericsson.com>)
Ответы Re: Facing issue in using special characters  (Chapman Flack <chap@anastigmatix.net>)
Re: Facing issue in using special characters  ("Warner, Gary, Jr" <gar@uab.edu>)
Re: Facing issue in using special characters  ("Warner, Gary, Jr" <gar@uab.edu>)
Re: Facing issue in using special characters  ("Warner, Gary, Jr" <gar@uab.edu>)
Список pgsql-general

This is not an issue for "hackers" nor "performance" in fact even for "general" it isn't really an issue.

"Special characters" is actually nonsense.

When people complain about "special characters" they haven't thought things through.

If you are unwilling to think things through and go step by step to make sure you know what you are doing, then you will not get it and really nobody can help you.

In my professional experience, people who complain about "special characters" need to be cut loose or be given a chance (if they are established employees who carry some weight). If a contractor complains about "special characters" they need to be fired.

Understand charsets -- character set, code point, and encoding. Then understand how encoding and string literals and "escape sequences" in string literals might work.

Know that UNICODE today is the one standard, and there is no more need to do code table switch. There is nothing special about a Hebrew alef or a greek lower case alpha or a latin A. Nor a hyphen and en-dash or an em-dash. All these characters are in the UNICODE. Yes, there are some Japanese who claim that they don't like that their Chinese character versions are put together with simplified reform Chinese font. But that's a font issue, not a character code issue.

7 bit ASCII is the first page of UNICODE, even in the UTF-8 encoding.

ISO Latin 1, or the Windoze 123 whatever special table of ISO Latin 1 has the same code points as UNICODE pages 0 and 1, but not compatible with UTF-8 coding because of the way UTF-8 uses the 8th bit.

But none of this is likely your problem.

Your problem is about string literals in SQL for examples. About the configuration of your database (I always use initdb with --locale C and --encoding UTF-8). Use UTF-8 in the database. Then all your issues are about string literals in SQL and in JAVA and JSON and XML or whatever you are using.

You have to do the right thing. If you produce any representation, whether that is XML or JSON or SQL or URL query parameters, or a CSV file, or anything at all, you need to escape your string values properly.

This question with no detail didn't deserve such a thorough answer, but it's my soap box. I do not accept people complaining about "special characters". My own people get that same sermon from me when they make that mistake.

-Gunther

On 3/15/2019 1:19, M Tarkeshwar Rao wrote:

Hi all,

 

Facing issue in using special characters. We are trying to insert records to a remote Postgres Server and our application not able to perform this because of errors.

It seems that issue is because of the special characters that has been used in one of the field of a row.

 

Regards

Tarkeshwar

В списке pgsql-general по дате отправления:

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: Re: Do all superuser processes count toward superuser_reserved_connections?
Следующее
От: Alexandru Lazarev
Дата:
Сообщение: jsonb_set performance degradation / multiple jsonb_set on multiple documents