The Basics of Code Pages in DB2

You may also like...

8 Responses

  1. Ian Bjorhovde says:

    There are plenty of other issues, too:

    * On some Linux and UNIX systems you have to make sure that the appropriate language code pages have been installed with the operating system. You can check what languages are available using the `locale -a` command. Linux typically has UTF-8 codepages installed, but AIX often does not.

    * On Linux and UNIX systems, make sure you also look at the LANG environment variable, which controls what codepage you are using. The default value of this setting when you log in may not be Unicode (typically `en_US.UTF-8`, but also `EN_US.UTF-8` on AIX), so you may have to set this environment variable in your .profile. You can see all of your language-level settings by executing the `locale` command.

    * Even if you’ve got everything else set up, if the display font you are using is missing glyphs for various Unicode code points, you may see blanks or “garbage” on screen even when everything else is talking happily in UTF-8.

    • Ember Crooks says:

      I actually checked some of that first. LANG is particularly important, and was set to en_US.UTF-8 already in my environment. Good tips in this comment. For other readers, here is an example of executing the locale command:

      $ 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"
      LC_MESSAGES="en_US.UTF-8"
      LC_PAPER="en_US.UTF-8"
      LC_NAME="en_US.UTF-8"
      LC_ADDRESS="en_US.UTF-8"
      LC_TELEPHONE="en_US.UTF-8"
      LC_MEASUREMENT="en_US.UTF-8"
      LC_IDENTIFICATION="en_US.UTF-8"
      LC_ALL=
      
  2. Helmut Tessarek says:

    A few additional comments that might help with understanding conversion a little bit better or at least give you an idea how it works internally:

    DB2 codepage conversion always happens on the receiving side. In UTF8 databases there is one exception where data is not stored in UTF8, but in UTF16BE (there is also one exception to that).
    It also depends on how data is bound by the client application.
    Here are all the exceptions as test cases (client is using UTF16LE, database is UTF8):

    case 1a) client inserts a varchar (bound as wchar)
    CLI does the byte swapping and sends UTF16BE. server converts UTF16BE to UTF8

    case 1b) client inserts a graphic (bound as dbchar)
    data is sent as is – no conversion
    the assumption is that the dbchar value is always in big endian even on a little endian machine

    case 1c) client inserts a graphic (bound as wchar)
    CLI does the byte swapping and sends UTF16BE. no conversion at server

    case 2a) client selects a varchar (bound as wchar)
    server sends UTF8. client converts from UTF8 to UTF16LE

    case 2b) client selects a graphic (bound as dbchar)
    data is sent as is – no conversion
    the assumption is that the dbchar value is always in big endian even on a little endian machine

    case 3c) client selects a graphic (bound as wchar)
    server sends UTF16BE. CLI does the byte swapping to UTF16LE


    Helmut K. C. Tessarek
    DB2 Performance and Development
    IBM Toronto Lab

  3. Ananth Francis says:

    Hi,

    What value should I add in locale to display the hebrew character in AIX environment?
    When I used “locale -a” command, I have got the below reult.
    locale -a
    C
    POSIX
    EN_US.UTF-8
    EN_US
    en_US.8859-15
    en_US.ISO8859-1
    en_US

    Thank You!!!

  4. Kendra says:

    I can’t get past a SQL 01517 error. Windows 2008 R2 with DB2 LUW 10.5 with DB2CODEPAGE=1208 and Region/Language English. This server and database interacts with an Ubuntu Linux server where locale en_US.utf-8 and LANG=en_US.utf8 Any ideas what else I can check?

Leave a Reply

Your email address will not be published. Required fields are marked *