Your database may be using UTF8, but if your clients are anything like ours (windows), they are probably connecting with the client charater set set to:

NLS_LANG=JAPANESE_JAPAN.JA16SJIS

Which means the Oracle client is translating the characters to UTF8 when it sends them to the database and back to SJIS when it retrieves them. Windows still doesn't have a decent UTF8 IME for Japanese, at least according to our Japanese users.

For my Japanese web interface, I connect to the database using the same NLS_LANG setting, and treat the data as binary data. Oracle gives me SJIS data, perl doesn't change it, and the clients get the SJIS characters they are expecting.

If you really are using UTF8 on the client, you should be able to connect with your client character set as NLS_LANG=(whatever).UTF8 and get UTF8 from the database. But I would make darn sure that your clients really doing that. (Everyone here said we were using UTF8(*), but when I checked the actual windows machines, they were using JA16SJIS, WE8ISO8859P1, and other local character sets(**) on the clients.)

Endnotes

(*) Your server is probably using UTF8 as the character set, which is important because Oracle can translate any other character set to UTF8 and back losslessly. But your client character set is probably whatever your client systems can display most easily.

(**) Additional cautions on Oracle client character sets: the NLS_LANG environment variable is the only way to set it, and there can only be one character set per client process. I have to start completely separate apache servers in order to handle multiple client character sets.