I have a PostgreSQL database. It has a table which stores menu items(labels).These menu items are stored in English. is there any way to convert these stored items (100+) to Japanese language by using localization feature? because my customer box is UNIX with locale set to Japanese.
Reading between the lines, I'd say your database is in iso-8869-1 or WIN1252 encoding, which are 1-byte encodings for English languages.
If so, while you could transcode to a Japanese-specific encoding, they're mostly quite limited - both in their coverage of English (Roman) characters, and their coverage of Kanji/Hiragana. Japanese doesn't work wonderfully in a 1-byte encoding. Shift-JIS was an attempt to work around that, but it's an awful text encoding to work with and PostgreSQL will refuse to run with it.
Instead, convert the database to utf-8. This will support all your existing content and all new content. UTF-8 will work for any language.
To do so:
CREATE DATABASE mydb_new ENCODING 'UTF-8'
LC_COLLATE 'jp_JA.UTF-8' LC_CTYPE 'jp_JA.UTF-8';
then pg_dump the old database, and pg_restore to the new database. Afterwards you can rename the databases to swap them over.
All characters in latin-1 are valid in utf-8, so there won't be issues loading the dump.
You/your customer might need to generate/install the ja_JP.UTF-8 locale (if on Linux/BSD). How to do that is somewhat distro/platform specific.
Related
I am loading data into QlikView report from different sources, one of them is Sybase db. Seems like Sybase db is using ISO 8859-1 encoding, but there are also Russian characters there, and QlikView just don't display them properly.
I don't see the way to manually define encoding in Qlikview. Is there any?
I tried to specify cyrillic charset in ODBC settings, but it also doesn't help. Funny thing is ASE isql (tool to run queries on Sybase) there is no issue with encoding. Can I specify encoding when select stuff in Sybase?
Sounds like a charset conversion issue. My guess is that your isql has a charset conversion option enabled, but your qlikview session has not.
I have a database that has been created on a database server that was installed with "Default Locale" selected where asked for "Select the locale to be used by the new database cluster". It should have been set to a specific locale. Can I just change that afterwards, or do I have to create the database from scratch?
It affects the text encoding ("code page") chosen for the DB, as well as the collation (sort order) used for text.
Changing either requires that you dump the database, drop it, re-create it and restore a dump.
When creating the database you can specify a specific ENCODING, LC_CTYPE, LC_COLLATE etc to override the DB-system-wide defaults. You must use TEMPLATE template0 if you want to change the encoding when creating a DB.
The locale used when creating the cluster sets the locale of the template databases. This in turn affects the locale of any further databases you create in the cluster since they are initialized by copying a template database (if you don't specify another locale when creating the database - see below).
The locale affects aspects such as the collation and the encoding. Encoding is the way in which characters are encoded into bytes in the database.
You can specify a collation or encoding when creating a database, but only if creating the database from template0. See CREATE DATABASE
You cannot change the encoding of an existing database. You would have to dump and reload the database to get a different encoding.
I hope there is some person from Georgia who might be able to help with my setup.
I have problem with Georgian database with SQL Server 2008R2. SQL Server is set to have default locale General Latin 1. it is running on Windows 7 which is installed with default English language. I am using this server to work with English, German, Slovak, Russian, Hebrew and Latvian databases without any problem.
now, when i try to create database using Georgian_Modern_Sort_CI_AS collation then database is created successfully, database structure is created but later when i try to use it it fails with error "The Collation specified by SQL Server is not supported."
I noticed that on MSDN page related to collations https://msdn.microsoft.com/en-us/library/ms143508%28v=sql.105%29.aspx Georgian collation is marked with star. However I didn't found any description what this star means.
I checked regional settings in my Windows and I noticed that if I want to change system locale then Georgian is not available in the list. I can install Georgian as display language, but it made no change in available system locales anyway.
Any idea what should I do to be able to work with Georgian databases?
Ouch, not sure if this is good, but I found something in mssql 2005 that is saying there is no way for Georgian or Hindi and varchar :/
The last example returns 0 (Unicode) as the code page for Hindi. This example illustrates the fact that many locales, such as Georgian and Hindi, do not have c?code pages, as they are Unicode-only collations. Those collations are not appropriate for columns that use the char, varchar, or text data type, and some collations have been deprecated. For a list of available collations and which collations are Unicode-only, see Collation Settings in Setup in SQL Server 2005 Books Online.
resources:
https://technet.microsoft.com/en-us/library/bb330962(v=sql.90).aspx
When must we use NVARCHAR/NCHAR instead of VARCHAR/CHAR in SQL Server?
DO SOMEONE HAVE DIFFERENT WAY HOW TO AVOID USING NVARCHARs FOR GEORGIAN SCRIPT OR HINDI?
I have recently started using PostgreSQL for creating/updating existing SQL databases. Being rather new in this I came across an issue of selecting correct encoding type while creating new database. UTF-8 (default) did not work for me as data to be included is of various languages (English, Chinese, Japanese, Russia etc) as well as includes symbolic characters.
Question: What is the right database encoding type to satisfy my needs.
Any help is highly appreciated.
There are four different encoding settings at play here:
The server side encoding for the database
The client_encoding that the PostgreSQL client announces to the PostgreSQL server. The PostgreSQL server assumes that text coming from the client is in client_encoding and converts it to the server encoding.
The operating system default encoding. This is the default client_encoding set by psql if you don't provide a different one. Other client drivers might have different defaults; eg PgJDBC always uses utf-8.
The encoding of any files or text being sent via the client driver. This is usually the OS default encoding, but it might be a different one - for example, your OS might be set to use utf-8 by default, but you might be trying to COPY some CSV content that was saved as latin-1.
You almost always want the server encoding set to utf-8. It's the rest that you need to change depending on what's appropriate for your situation. You would have to give more detail (exact error messages, file contents, etc) to be able to get help with the details.
I had an application that used a Sybase ASA 8 database. However, the application is not working anymore and the vendor went out of business.
Therefore, I've been trying to extract the data from the database, which has Arabic characters. When I connect to the database and display the contents, Arabic characters do not display correctly; instead, it looks something like ÇáÏãÇã.
Which is incorrect.
I tried to export the data to a text file. Same result. Tried to save the text file with UTF-8 encoding, but to no avail.
I have no idea what collation the tables are set to. Is there a way to export the data correctly, or convert it to the correct encoding?
the problem was solved by exporting the data from the database using "Windows-1252" encoding, and then importing it to other applications with "Windows-1256" encoding.
When you connect to the database, use the CHARSET=UTF-8 connection parameter. That will tell the server to convert the data to UTF-8 before sending it to the client application. Then you can save the data from the client to a file.
This, of course, is assuming that the data was saved with the correct character set to begin with. If it wasn't, you may be out of luck.