- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
hallo zusammen,
wir verwenden die sas-version 9.04.01M6 inkl. dem modul "sas/access interface to pc files".
in einer work.tabelle haben wir die textvariable "krankheiten" die auch umlaute beinhalten. diese werden in sas alle ordentlich dargestellt. z.b. "Rückgradverkrümmung"
nach dem export dieser work.tabelle nach stata werden nun diese umlaute nicht mehr vernünftig dargestellt.
z.b. "R�ckgradverkr�mmung"
ich verwende diesen befehl:
proc export data= work.tabelle1
outfile= "C:\temp\test.dta"
dbms=STATA
replace;
run;
dies habe ich schon ohne erfolg versucht:
filename exprt "C:\temp\test.dta" encoding="utf-8";
outfile=exprt
es kommt die meldung:"Disk Write Error"
was müsste man machen, damit die umlaute in der textvariablen der stata datei korrekt angezeigt werden?
vielen dank für eure hilfe.
gairon
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
Zuallererst wäre es mal interessant zu wissen, wie das im SAS kodiert ist. Dazu eine neue Variable mit hex-Format und doppelter Länge erzeugen:
data test;
input krankheit $80.;
length krankheit2 $160;
krankheit2 = put(krankheit,$hex160.);
datalines;
Rückgratverkrümmung
;
run;
Encoding für ein spezielles Outfile-Format im proc export macht keinen Sinn, weil die DBMS= Option bereits alles erledigen muss.
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
hallo,
laut "proc options" ist bei uns in sas dies eingestellt "ENCODING=WLATIN1"
hier das ergebnis ihres scripts:
Rückgratverkrümmung 52FC636B677261747665726B72FC6D6D756E6720202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020
wenn sie nun ihre tabelle "test" nach stata mit dem modul exportieren, dann erhalten sie "R�ckgratverkr�mmung" in der stata-datei.
gruss
gairon
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
Dann kann es sein, dass STATA ein Problem mit herkömmlicher Single-Byte Kodierung hat. Um das zu testen, sollte man folgendes ans STATA "füttern":
data test;
length test $24;
test = input('00C400D600DC00E400F600FC',$hex24.); /* Unicode precomposed */
output;
test = input('00410308004F03080055030800610308006F030800750308',$hex48.); /* Unicode decomposed */
output;
test = input('C384C396C39CC3A4C3B6C3BC',$hex24.); /* UTF-8 */
output;
run;
Enterprise Guide hat dabei ein Problem, das richtig darzustellen, aber im Grunde sind alle drei Sätze jeweils "ÄÖÜäöü".
Wahrscheinlich wird es notwendig sein, SAS mit Session-Encoding UTF-8 zu starten, um die Daten schon im SAS richtig zu haben.
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
danke, habe ihr script ausgeführt. nach dem export sind in stata die ersten 2 zeilen leer, nur die 3. zeile wird mit "ÄÖÜäöü" ordentlich angezeigt.
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
@Gairon schrieb:
danke, habe ihr script ausgeführt. nach dem export sind in stata die ersten 2 zeilen leer, nur die 3. zeile wird mit "ÄÖÜäöü" ordentlich angezeigt.
Dann wird es wohl notwendig sein, die ganze SAS-Umgebung mit utf-8 Encoding zu fahren.
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
Die "R�ckgradverkr�mmung" fremde karakter sind in utf-8 angedeutet as replacement karakter.
Mit Wlatin1 geht es um einzele-byte nur die decimal order karakter 32 - 127 sind gleich in utf-8.
utf-8 benuts 1-4 bytes für eine karakter. Klar ist das die transcoding zwischen die unterschiedliche encodings nicht gut gegangen is.
Das einfachste wurde ein sas session utf-8. Eguide ist utf-8 aber nicht die sas-session.
https://blogs.sas.com/content/sgf/2017/05/19/demystifying-and-resolving-common-transcoding-problems/
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
Dann wird es wohl notwendig sein, die ganze SAS-Umgebung mit utf-8 Encoding zu fahren.
leider kann/darf ich das sas-system in unserem haus nicht umstellen, was aber notwendig wäre, da viele user die daten nach stata umwandeln müssen.
ich habe mich jetzt dazu entschlossen, das problem in stata wie folgt zu beheben.
clear
unicode encoding set latin1
cd <pfad der stata-datei>
unicode translate "<dateiname>.dta"
ich habe gerade den ersten test abgeschlossen und es sieht ganz gut aus.
vielen dank an alle.
gruss
gairon
- Als neu kennzeichnen
- Lesezeichen
- Abonnieren
- Stummschalten
- RSS-Feed abonnieren
- Kennzeichnen
- Anstößigen Inhalt melden
Es ist immer sinnvoll, die gesamte Softwareumgebung im Unternehmen konsistent zu halten, also entweder alles in wlatin1 oder utf-8. Sobald die Quellsysteme (Datenbanken, SAP, was auch immer) UTF Daten enthalten, sollte auch das gesamte Data Warehousing UTF verwenden.