![]() ![]() Client/Server Character Set Conversions Server Character Set Template0 | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | Postgres | hlinnaka | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | Korean | hlinnaka | EUC_KR | ko_KR.euckr | ko_KR.euckr | Japanese | hlinnaka | UTF8 | ja_JP.UTF8 | ja_JP.UTF8 | +-+-+-+-+-Ĭlocaledb | hlinnaka | SQL_ASCII | C | C |Įnglishdb | hlinnaka | UTF8 | en_GB.UTF8 | en_GB.UTF8 | Name | Owner | Encoding | Collation | Ctype | Access Privileges You can see it by using the psql -l option or the \l command. The encoding for a database is stored in the system catalog pg_database. When copying any other database, the encoding and locale settings cannot be changed from those of the source database, because that might result in corrupt data. Notice that the above commands specify copying the template0 database. Another way to accomplish this is to use this SQL command: CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0 This will create a database named korean that uses the character set EUC_KR, and locale ko_KR. You can specify a non-default encoding at database creation time, provided that the encoding is compatible with the selected locale: createdb -E EUC_KR -T template0 -lc-collate=ko_KR.euckr -lc-ctype=ko_KR.euckr korean If no -E or -encoding option is given, initdb attempts to determine the appropriate encoding to use based on the specified or default locale. You can use -encoding instead of -E if you prefer longer option strings. Sets the default character set to EUC_JP (Extended Unix Code for Japanese). Initdb defines the default character set (encoding) for a PostgreSQL cluster. In most cases, if you are working with any non-ASCII data, it is unwise to use the SQL_ASCII setting because PostgreSQL will be unable to help you by converting or validating non-ASCII characters. ![]() Thus, this setting is not so much a declaration that a specific encoding is in use, as a declaration of ignorance about the encoding. No encoding conversion will be done when the setting is SQL_ASCII. When the server character set is SQL_ASCII, the server interprets byte values 0-127 according to the ASCII standard, while byte values 128-255 are taken as uninterpreted characters. The SQL_ASCII setting behaves considerably differently from the other settings. ![]() For example, the PostgreSQL JDBC driver does not support MULE_INTERNAL, LATIN6, LATIN8, and LATIN10. Not all client APIs support all the listed character sets. (On Windows, however, UTF-8 encoding can be used with any locale.) For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. It can be overridden when you create a database, so you can have multiple databases each with a different character set.Īn important restriction, however, is that each database's character set must be compatible with the database's LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings. The default character set is selected while initializing your PostgreSQL database cluster using initdb. All supported character sets can be used transparently by clients, but a few are not supported for use within the server (that is, as a server-side encoding). The character set support in PostgreSQL allows you to store text in a variety of character sets (also called encodings), including single-byte character sets such as the ISO 8859 series and multiple-byte character sets such as EUC (Extended Unix Code), UTF-8, and Mule internal code. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |