Bug:

[bigdamidea]

Describe the bug

Describe the bug
That's TENNESSEE LIVIN' OUTFITTERS — complete, trailing "S" and all (Len=27, ending in 53=S), with 0x92 being the smart apostrophe. The data in Oracle is perfectly correct. This is my "Outcome A," not B.

Do NOT run the UPDATE
The UTL_I18N repair statements I gave would corrupt this good data — the column already holds clean WE8MSWIN1252 bytes. Skip them entirely. Nothing in the database needs fixing.

What's actually broken
The corruption happens when the data is read, not where it's stored. Something in your client/driver/export path is taking the single‑byte 1252 data and reinterpreting each pair of bytes as one UTF‑16 character:

54 45 → U+5445 → 呅 (should be "TE")
4e 4e → U+4E4E → 乎 (should be "NN")
That's exactly why the plain SELECT shows Chinese but DUMP (which returns an ASCII description) shows the correct bytes. It's a client character‑set / NLS_LANG mismatch, not a data problem.

The fix — NLS_LANG on the reader/exporter
NLS_LANG's charset should describe what encoding you want the client to receive; Oracle then converts the stored WE8MSWIN1252 automatically. Set it on whatever process pulls the data (SQL Developer, SQL*Plus, your ETL/CSV export job, the app):

You want UTF-8 output (recommended for CSVs / modern tools):

NLS_LANG = AMERICAN_AMERICA.AL32UTF8

→ Oracle converts 0x92 ' to proper UTF-8, accents come through clean

Or if your tool/OS is natively Windows-1252:

NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252
Set it as an environment variable (or in SQL Developer: Preferences → Environment → Encoding, and check the connection's NLS settings). The moment the client stops misreading the bytes as UTF‑16, TENLIVOUT1 returns as text, not glyphs.

Bonus: everything we "lost" is actually intact

To Reproduce
Steps to reproduce the behavior:
Run any Query against the Oracle table

Expected behavior
"呅乎䕓卅䔠䱉噉互⁏啔䙉呔䕒" was returned, ACTUAL value in Oracle is "TENNESSEE LIVIN’ OUTFITTERS"

Screenshots
If applicable, add screenshots to help explain your problem.

Additional details
Enter any additional details we should know about.

Product

SQLPro Studio

App version

Version 2026.87 (Build 111212)

Platform

macOS

Installation source

App Store

[hankinsoft]

Hi. Could you run these and send the output?

• Column type (find the offending column):

SELECT column_name, data_type, char_used FROM user_tab_columns WHERE table_name = 'YOUR_TABLE';

• Database and national charset:

SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

• A DUMP of that column, noting whether it is VARCHAR2 or NVARCHAR2:

SELECT DUMP(your_column, 1016) FROM your_table WHERE ...;

If the column is NVARCHAR2 / NCHAR, the stored bytes are not valid UTF-16 for that text (single-byte 1252 data sitting in a 2-byte national column), which points to how the data was loaded rather than the query. If it is a plain VARCHAR2, then we are mislabeling its charset and I can fix that directly in the driver.

Cheers