Exporting Unicode Data from SQL Developer Data Grid to CSV: A Practical Guide

The Problem

When working with international customer data, you often need to pull a result set from Oracle into a flat file for reporting or migration. The built‑in Data Grid export can do this, but if you don’t pick the right settings the output can end up garbled – accented letters vanish, Chinese characters become �, and emojis turn into question marks.

Why Export Matters

Exporting to CSV keeps downstream tools (Excel, Power BI, another RDBMS) happy and preserves the exact byte sequence of your data. For global applications, that means no loss of meaning when a French name or a Japanese address is moved between systems.

Getting Started

Requirements:

• Oracle SQL Developer 20.2 or newer (desktop client only)
• Connection to an Oracle Database 12c+ or Autonomous Database
• JVM with at least 512 MB heap (adjust -Xmx if you export >100k rows)

Step‑by‑Step Export

1. Run a query that contains Unicode. For example:

SELECT 'Café' AS name,
       '北京' AS city,
       '😊' AS emoji
FROM dual;

1. Right‑click the result grid. The context menu appears only when the grid is fully populated.
2. Choose Export → CSV.
3. In the Export Wizard:
• Delimiter: comma (default) or semicolon if your locale uses comma as decimal separator.
• Include column headers: ticked (recommended).
• Character Set: select UTF‑8. The default is the OS locale, which can corrupt non‑ASCII data.
• File name: exported_unicode.csv (or any path you prefer).
4. Click Next → Finish.
5. SQL Developer writes the file synchronously. If the session drops, the file may be incomplete; keep a copy of the query for re‑run.

Verifying Unicode Integrity

Open the CSV in a UTF‑8 aware editor (Notepad++, VS Code, or less -R on Linux). You should see:

name,city,emoji
Café,北京,😊

Alternatively, import the file back into a temporary table to confirm round‑trip fidelity:

CREATE TABLE temp_import (name VARCHAR2(100 CHAR), city VARCHAR2(100 CHAR), emoji VARCHAR2(10 CHAR));
SQL> 
-- Use SQL Developer’s “Import Data” wizard, set encoding to UTF‑8.

Trade‑offs & Limits

• Memory usage: Large exports (hundreds of thousands of rows) can exhaust the client’s JVM heap. Increase -Xmx if you hit java.lang.OutOfMemoryError.
• Session timeouts: The export is synchronous; if the Oracle session times out mid‑write, the file will be truncated.
• Feature scope: Only the Data Grid view supports this export. Query Result tabs that use pagination or PL/SQL block results cannot be exported via the UI.
• Web SQL Developer: The web version lacks the export dialog; you must use the desktop client.

Actionable Takeaways

• Always set Character Set to UTF‑8 when exporting multilingual data.
• For very large result sets, consider splitting the query or increasing JVM memory.
• Keep a copy of the SELECT statement to re‑run if the export is interrupted.
• Validate the CSV in a UTF‑8 editor before downstream consumption.

With these steps, you can reliably export any Unicode‑rich result set from Oracle SQL Developer to a portable CSV file, preserving data integrity across systems.