Het laden van Unicode-tekens met Oracle SQL Loader (sqlldr) resulteert in vraagtekens

Ik probeer gelokaliseerde strings te laden van een unicode (UTF8-gecodeerd) csv met behulp van SQL Loader in een oracle-database. Ik heb allerlei combinaties geprobeerd, maar niets lijkt mij het resultaat te geven waarnaar ik op zoek ben, wat betekent dat speciale Griekse karakters zoals (Δ) niet omgezet worden naar Î "of ¿.

Mijn tabeldefinitie ziet er als volgt uit:

CREATE TABLE "GLOBALIZATIONRESOURCE"
(
    "RESOURCETYPE" VARCHAR2(255 CHAR) NOT NULL ENABLE,
    "CULTURE"      VARCHAR2(20 CHAR) NOT NULL ENABLE,
    "KEY"          VARCHAR2(128 CHAR) NOT NULL ENABLE,
    "VALUE"        VARCHAR2(2048 CHAR),
    "DESCRIPTION"  VARCHAR2(512 CHAR),
    CONSTRAINT "PK_GLOBALIZATIONRESOURCE" PRIMARY KEY ("RESOURCETYPE","CULTURE","KEY") USING INDEX TABLESPACE REPSPACE_IX ENABLE
)
TABLESPACE REPSPACE; 

Ik heb de volgende configuraties geprobeerd in mijn controlebestand (en eigenlijk elke permutatie die ik kon bedenken)

load data
TRUNCATE
INTO TABLE "GLOBALIZATIONRESOURCE"
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(   
    "RESOURCETYPE" CHAR(255), 
    "CULTURE" CHAR(20), 
    "KEY" CHAR(128), 
    "VALUE" CHAR(2048), 
    "DESCRIPTION" CHAR(512)
)

load data
CHARACTERSET UTF8
TRUNCATE
INTO TABLE "GLOBALIZATIONRESOURCE"
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(   
    "RESOURCETYPE" CHAR(255), 
    "CULTURE" CHAR(20), 
    "KEY" CHAR(128), 
    "VALUE" CHAR(2048), 
    "DESCRIPTION" CHAR(512)
)

load data
CHARACTERSET UTF16
TRUNCATE
INTO TABLE "GLOBALIZATIONRESOURCE"
FIELDS TERMINATED BY X'002c' OPTIONALLY ENCLOSED BY X'0022'
TRAILING NULLCOLS
(   
    "RESOURCETYPE" CHAR(255), 
    "CULTURE" CHAR(20), 
    "KEY" CHAR(128), 
    "VALUE" CHAR(2048), 
    "DESCRIPTION" CHAR(512)
)

Met de eerste twee opties worden de Unicode-tekens niet gecodeerd en worden ze gewoon als omgekeerde vraagtekens weergegeven.

Als ik de laatste optie, UTF16, kies, krijg ik de volgende foutmelding hoewel al mijn gegevens in mijn velden veel korter zijn dan de opgegeven lengte.

Field in data file exceeds maximum length

Het lijkt erop dat elke mogelijke combinatie van ctl-bestandsconfiguraties (zelfs het instellen van de bytevolgorde op klein en groot) niet correct werkt. Kan iemand een voorbeeld geven van een configuratie (tabelstructuur en CTL-bestand) die unicodegegevens correct uit een csv laadt? Alle hulp zou zeer op prijs worden gesteld.

Opmerking: ik ben al naar http://docs.oracle .com/cd/B19306_01/server.102/b14215/ldr_concepts.htm , http://docs.oracle.com/cd/B10501_01/server.920/a96652/ch10.htm en http://docs.oracle.com/cd/B10501_01/server.920/a96652/ch10.htm .

2
Wat is de database-tekenset? Ervan uitgaande dat de database Unicode ondersteunt, welke tool gebruikt u om de gegevens te bevragen en wat zijn de NLS-instellingen van de klant? Weet je zeker dat de client en de querytool de Griekse tekens ondersteunen die je probeert te laden? Heeft u de functie DUMP gebruikt om te bepalen of de gegevens in de database juist zijn gecodeerd?
toegevoegd de auteur Justin Cave, de bron
@philirabin - Dat betekent dat uw database-tekenset Unicode niet ondersteunt. Als u datatypes NVARCHAR2 gebruikt (ervan uitgaande dat uw nationale tekenset Unicode ondersteunt), moet u ervoor zorgen dat al uw downstreamtoepassingen NVARCHAR2 gegevenstypen ondersteunen. Het gebruik van de nationale tekenset in plaats van de database-tekenset zorgt voor een behoorlijke hoeveelheid complexiteit.
toegevoegd de auteur Justin Cave, de bron
In welke taal (talen) en framework (s) bouwt u uw applicaties? De complexiteit is meestal afhankelijk van de talen en kaders. Bouwt u een nieuwe applicatie? Is dit een nieuwe database? Of globaliseert u een gevestigde applicatie?
toegevoegd de auteur Justin Cave, de bron
Ik ontdekte het probleem na veel vallen en opstaan. Ik ben overgestapt naar NVARCHAR2 als mijn databasekolomtype en CHARACTERSET UTF8 in mijn besturingsbestand dat de unicodetekst perfect verwerkt.
toegevoegd de auteur philrabin, de bron
Kun je uitleggen wat die complexiteiten zijn? En om u wat achtergrondinformatie te geven, gebruiken we deze tabel als vervanging voor resx-bestanden. We bouwen een app met meerdere tenants en elke client heeft zijn eigen strings geconfigureerd en kan variëren tussen clients en talen. Met andere woorden, ClientX-> SectionTitle-> French kan anders zijn dan ClientY-> SectionTitle-> French.
toegevoegd de auteur philrabin, de bron

4 antwoord

Je moet ervoor zorgen dat de volgende personages hetzelfde zijn:

  1. db-tekenset
  2. dump bestandstekenset
  3. de client van waaruit u de import uitvoert (NLS_LANG)

Als de client-side-tekenset anders is, probeert oracle tekenconversies uit te voeren naar de oorspronkelijke db-personageset en dit levert mogelijk niet altijd het gewenste resultaat op.

1
toegevoegd
Kan iemand uitleggen wat deze personageset is en hoe een bepaalde tekst te herkennen aan welke personageset het toebehoort?
toegevoegd de auteur Kashif Khan, de bron

Gebruik MS Office niet om de spreadsheet op te slaan in unicode .csv. Gebruik in plaats daarvan OpenOffice om op te slaan in unicode-UTF8 .csv-bestand. Voeg vervolgens in het bestand voor laderbesturing "CHARACTERSET UTF8" toe voer Oracle SQL * Loader uit, dit geeft me de juiste resultaten

1
toegevoegd

Je hebt twee problemen;

  1. Tekenset.

Answer: You can solve this problem by finding your text character set (most of time notepad++ can do this.). After finding character set, you have to find sqlldr correspond of character set name. So, you can find this info from link https://docs.oracle.com/cd/B10501_01/server.920/a96529/appa.htm#975313 After all of these, you should solve character set problem.

  1. In contrast to your actual data length, sqlldr says that, Field in data file exceeds maximum length.

Answer: You can solve this problem by adding CHAR(4000) (or what the actual length is) to problematic column. In my case, the problematic column is "E" column. Example is below. In my case I solved my problem in this way, hope helps. LOAD DATA CHARACTERSET UTF8 -- This line is comment -- Turkish charset (for ÜĞİŞ etc.) -- CHARACTERSET WE8ISO8859P9 -- Character list is here. -- https://docs.oracle.com/cd/B10501_01/server.920/a96529/appa.htm#975313 INFILE 'data.txt' "STR '~|~\n'" TRUNCATE INTO TABLE SILTAB FIELDS TERMINATED BY '#' TRAILING NULLCOLS ( a, b, c, d, e CHAR(4000) )

1
toegevoegd

Er is een reeks tekensetcodering die u in het besturingsbestand kunt gebruiken tijdens het laden van gegevens van de sql-lader.

Voor Griekse karakters geloof ik dat de West-Europese tekenset de slag zou moeten slaan.

LOAD DATA
CHARACTERSET WE8ISO8859P1

of in het geval van MS-woordinvoerbestanden met slimme tekens probeer het besturingsbestand

LOAD DATA
CHARACTERSET WE8MSWIN1252
0
toegevoegd