Tag Info

Hot answers tagged

7

The trick here is to realize that these characters that you see in the question with the "accents" aren't really the characters (i.e. "These aren't the droidscharacters you are looking for" ;-) ). The "accents" are various types of notations indicating things like: vowels (lines and dots that are typically under the letters) pronunciation (dots that are ...


5

Well, the trick is that a database can only specify which "locale" it is used for at creation time. When you create a database you either specify what you want by specifying the codeset, territory and collation (example CREATE DATABASE MYDB AUTOMATIC STORAGE YES ON '/data' DBPATH ON '/dbdir' USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM), or you let ...


3

After some trial and error, I've learned how and where to apply COLLATE: Converted lines like: SELECT SOMETHING FROM SOMEWHERE WHERE table_schema = given_database AND table_name = given_table AND index_name = given_index; To: SELECT SOMETHING FROM SOMEWHERE WHERE table_schema COLLATE utf8_unicode_ci = given_database AND table_name COLLATE ...


2

The solution isn't precisely the same but this question is where I originally found direction for a similar issue and the concepts there should take you where you want to go. MySQL has a BINARY character set and from all appearances, by converting through it, you can prevent MySQL from realizing what you're actually doing and being "too helpful." Test case ...


2

The encoding defines the very basic rules how characters are represented in binary format (like @a_horse explains in his comment). It should be mentioned that the server encoding has to match the client encoding for successful communication. Postgres can translate if necessary, there is a dedicated setting client_encoding for this. The locale is a superset ...


2

Another option, one which I've just learned, comes from the sqlcmd documentation. You need to set the codepage for sqlcmd to match that of the file encoding. In the case of UTF-8, the codepage is 65001 so you'd want: SQLCMD -S .\MSSQLSERVER08 -V 17 -E -i %~dp0\aqualogyDB.sql -o %~dp0\databaseCreationLog.log -f 65001


2

As from the comments, the problem is not exactly with the table or the way SQLCMD imports the special characters. Usually, problematic imports are related to the format of the script itself. Management Studio itself offers the option of saving with a specific encoding, which should solve the problem in the future. When saving a file for the first time (or ...


2

PostgreSQL 8.4 supports only one locales that is selected in installation time. You need to rerun initdb statement with different locales (but only one can be used) or you can migrate to 9.x version, that supports more locales.


2

psql detects the client_encoding from the LC_CTYPE variable in the environment; this falls back to LC_ALL and then LANG if unset. In the terminal you're launching psql from, run locale. e.g. $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" ...


2

know that I should migrate my database to utf8 to solve this problem, but for some reasons, I can not do that for the moment. In my case, I'd rather PostgreSQL saves my string removing characters it can not convert or for example replacing them with some symbol like "?" rather than throwing an error... PostgreSQL does not support this. It's ...


2

Is there a way to permanently configure this setting, either in the .pgpass file or anywhere else Yes there is: it's ~/.psqlrc (or %APPDATA%\postgresql\psqlrc.conf in Windows) See the manual for details: http://www.postgresql.org/docs/current/static/app-psql.html#AEN88713


1

I've used a Numbers table. There are any number of posts explaining what this is, why its useful and how to get one efficiently. I don't use any built-in functionality to convert accented characters to the non-accented equivalent. Instead I build a lookup list which you will populate with the conversions you require. You will have to use nvarchar and ...


1

Since the DB has both Engliah and Thai I decided to change the collation for the columns. ALTER TABLE books ALTER thai_title TYPE varchar(255) COLLATE "C";


1

On PostgreSQL 9.1 and newer, you can use the COLLATE qualifier on an operation to override the database's default collation. See the manual for information on collation support. E.g. SELECT a, b FROM mytable ORDER BY c COLLATE 'th_TH.UTF-8'; Note that PostgreSQL can't mix different collations, using a dynamic collation based on detected language. It ...


1

Thank you very much - I found the solution. First, the output encoding of the Oracle command line tools can be controlled by either the NLS_LANG environment variable (in my situation, a value of GERMAN_GERMANY.AL32UTF8 was needed) or through the registry by the key HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\NLS_LANG Thank you very much for all - I leave this ...


1

Have you tried the encode(data bytea, format text) with escape format?


1

You'll have to specify a character set of UTF8 on the table schema. See http://dev.mysql.com/doc/refman/5.5/en/charset-syntax.html Depending on your needs you can specify table defaults which then apply to all unspecified text columns (char/varchar/text) or you can specify on a per column level. You'll also need to have your applications to specify a ...


1

Client Encoding Mismatch is an error message from old versions of the PostgreSQL ODBC driver. You should go here: http://www.postgresql.org/ftp/odbc/versions/msi/ to get the most recent version and update your system. Also there are in fact two driver flavors that get installed: ANSI and Unicode. Presumably you need Unicode if you decided to switch to ...


1

A possible solution: Dump your table data with mysqldump or any other favorite tool Fix encoding in dump file using one of the utilities (there are plenty out there) Load data back


1

Mangled text encoding dumps are a pain to work with. The usual - and admittedly crude - solution is to run iconv on the SQL-format dump, with the -c flag to tell it to omit characters that are invalid in the target encoding. This is only viable if the origin database is supposedly in one primary encoding, and just has a bit of bad data here and there due ...


1

I suspect your database content may be in iso8859 or cp1252. If it were ascii, you would not run into problems importing it. You may be able to determine the coding by opening your dump with python. The following python3 tries encodings until it succeeds. It can be used to determine the file encoding. for enc in ('cp1252', 'utf8'): ...


1

The backslash \ is the default escape character in the (default) text format of COPY. The format you describe is recognized as (quoting the manual here) backslash sequences are recognized by COPY FROM ... \xdigits | Backslash x followed by one or two hex digits specifies the character with that numeric code .. which seems to be just as intended. ...


1

I found a solution, for everyone to know: Assuming that we put the xml field in a variable of type varchar(max) and then casting it to a variable of type XML (but not by using the CONVERT function, rather just by simple assignment), in the end the value of the newly created XML variable will be included in an insert query, by casting it back to ...



Only top voted, non community-wiki answers of a minimum length are eligible