ThatJeffSmith

Non-English Character Display in Oracle SQL Developer

I get a variation on this question at least once a week, if not more frequently.

I’m from Israel, and the language on the databases is Hebrew. When I use the old and deprecated SQL*Plus (windows rich client) I can see the hebrew clearly, when I use the latest SQL Developer, I get gibberish.

This question appears on the forums about every week or so as well. So what’s the deal?

Well, it starts with a basic misunderstanding of NLS Client parameters. These should accurately reflect the language and locality setup on your LOCAL machine. DO NOT COPY what’s set in the database. The these parameters work together with the database so that information can be transferred back and forth correctly.

Having the wrong NLS parameters locally can be bad.

[ORACLE DOCS]Setting the NLS_LANG parameter properly is essential to proper data conversion. The character set that is specified by the NLS_LANG parameter should reflect the setting for the client operating system. Setting NLS_LANG correctly enables proper conversion from the client operating system character encoding to the database character set. When these settings are the same, Oracle Database assumes that the data being sent or received is encoded in the same character set as the database character set, so character set validation or conversion may not be performed. This can lead to corrupt data if conversions are necessary.

OK, so what are you supposed to do?

Set the Font!

9 times out of 10, this preference fixes the problem with display issues.

9 times out of 10, this preference fixes the problem with display issues.

Make sure you set a Font that supports the characters you’re trying to display. It’s as simple as that. This preference defines the font used to display characters in the editors and the data grids. If you have it set to a font that doesn’t have Hebrew character support – you’re not going to see Hebrew in SQL Developer.

A few years ago…wow, like 15 years ago, I learned that the Tohama Font is pretty Unicode-friendly.

Bad Font Selection

A Font that's not non-English friendly

A Font that’s not non-English friendly

Good Font Selection

Exact same text, except rendered with the Tahoma font

Exact same text, except rendered with the Tahoma font

Summary

Having problems seeing non-English text in SQL Developer? Check the font! And do not start messing with NLS parameters without talking to your DBA first.