TSQLConnection / Oracle / NSL_CHARACTERSET ändern

[tofse]

Hallo,
ich greife auf die Oracle Datenbank einer anderen Software zu. Dort sind Passwörter "verschlüsselt" hinterlegt.
Das wird gemacht, um den Benutzerstamm dieser Software als Basis für Eigenentwicklungen zu verwenden.
Der Algorithmus zum Verschlüsseln ist bekannt.

Nun das Problem: Wenn ich das Passwort per SQL auslese, kommt der verschlüsselt String zurück, funktioniert prima, außer das unverschlüsselte Zeichen ist ein Sonderzeichen.
In der Datenbank steht z.B. ÝÒåçÙç™, SQL liefert aber ÝÒåçÙç (an der letzten Stelle steht hier im Beispiel ein !)
Zunächst dachte ich, der Algorithmus hat einen Fehler, der sich bei den Sonderzeichen zeigt.
Das konnte ich aber widerlegen, denn es wird auch mit einem PHP Skript auf die Datenbank zugegriffen. Zunächst hatte ich das gleiche Phänomen, aber man kann in der Connection

Code:

oci_connect('user','pw','......','WE8MSWIN1252')

character_set angeben. Mit der richtigen Angabe für diese Datenbank hat es dann auch funktioniert. Also muss es daran liegen.

So, nun zur eigentlichen Frage :-D
Wie kann ich NLS_CHARACTERSET in Delphi (TSQLConnection) setzen???? Ich denke, damit wird es dann funktionieren.

Grüße
Christof

[p80286]

Vielleicht hilft Dir dies weiter?

Gruß
K-H

[tofse]

Leider nicht, da wird ja nicht gezeigt, wie es unter Delphi anzugeben ist.
Ich denke...hoffe...dass man es einfach in der Connection (ähnlich wie bei PHP) einfach mit angeben kann.

Ich hatte es schon mit ALTER SESSION versucht, aber da kam irgendwas mit nicht zulässig...

[EgonHugeist]

AFAIK funktioniert mit Oracle nicht so ohne weiteres.

Bei Oracle und FireBird muß man den Client-Characterset vor dem Connect wissen, da du erst alle Envirnonment-Variablen hinterlegen mußt.

function OCIEnvNlsCreate(var envhpp: POCIEnv; mode: ub4; ctxp: Pointer;
malocfp: Pointer; ralocfp: Pointer; mfreefp: Pointer; xtramemsz: size_T;
usrmempp: PPointer; charset, ncharset: ub2): sword; cdecl;

wäre hier die Lösung. Hast du Zugriff zum Code der Komponente?

CharSet WE8MSWIN1252 hat die ID 178.

Ich weiß, Zeos unterstützt das. Du könntest mit Zeos einen Export machen und dann danach alles im wieder importieren, da es sich hierbei einfach um ein Encodierungs-Problem zu handeln scheint..

Gruß Michael

[tofse]

oje, ich dachte das wäre so einfach wie in php :(
In SQL bin ich fit, aber das Ganze drum herum und DB Administration, da hab ich null Plan...

Dein Lösungsansatz wäre mir da zu hoch...

[shmia]

Wenn man verschlüsselte Passwörter in einer Datenbank, XML- oder Inifile speichert
sollte man unbedingt die binären Daten hexadezimal (Base16) oder Base64 kodieren,
damit man grundsätzlich den Problemen mit dem Zeichensatz aus dem Weg geht :!:

[tofse]

Danke für den Hinweis, aber das steht nicht zur Diskussion, da es sich um einen großen Softwareanbieter handelt, und wir darauf keinen Einfluss haben. Sind schon froh, dass wir den Algorithmus haben.

[jobo]

Du musst glaub ich "nur" NLS_LANG im OS Environment passend setzen, bevor(!) du connectest.

[p80286]

ok ich arbeite mit ADO aber verschlüsselte Passwörter habe ich auch schon ausgelesen. ggf ist die fehlerhafte Darstellung nur ein Darstellungsproblem?
Hast Du mal einen Hex-Dump Deiner Passwörter erstellt?

Gruß
K-H

[EgonHugeist]

Zitat:

Zitat von tofse (Beitrag 1194551)

oje, ich dachte das wäre so einfach wie in php :(

Ist es eigentlich auch, nur eben nicht mit der UnicodeIDE.

So, wie ich das sehe, brauchst du eine Komponente, mit welcher du den CharacterSet selber bestimmst und bei Bedarf sogar auf den nativen nicht-zu-UnicodeString(stimmt die XE-Compiler Angabe?), um dein Problem zu lösen.

Erst einmal würd ich sagen Finger weg von Ideen wie zu Laufzeit den CharacterSet ändern, wenn du eine UnicodeIDE benutzt:

Ich gehe mal davon aus, das die meisten Komponenten da gleich funktionieren: Stelle den vom Benutzer gewüschten CharacterSet ein, dann macht der Server(außer MsSQL) alle notwendigen Encodierungen und die DB-Zugriffs Komponente weiß, wie sie den vom Server erhaltenen Ansi-String(CP-WhatEver) zum UnicodeString mappt. Sollter der User den CharSet nicht angegeben haben, frage die DB danach und stelle die AnsiToUnicode und umgekehrt Functionen darauf ein, da ein Casten nur zufällig passende Resultate geliefert, wenn ServerCP <> DefaultCodePage. (auch ADO bleibt davon nicht verschont, tut es jedoch intern) Blablabla..

Wenn du den CharSet zur Laufzeit änderst, passt vielleicht der String, den du dir wünschst, jedoch ist es möglich, daß alle anderen Encodierungen totalen Stuß fabrizieren. (da die Componente noch immer den AnsiString mit CP-WhatEver erwartet)

Daher versuchs mal mit dem Vorschlag von jobo.:thumb:

Wenn dann alles nix hilft:

Lade Zeos7-Beta herunter und installiere die Komponente.
Benutze die TZConnection anstadt oder zusätzlich zu der TSQLConnection (kenne ich nicht :oops:)

TZConnection.ClientCodePage := 'WE8MSWIN1252';
TZConnection.UserName etc.....

Verbinde dich mit der DB.

Delphi-Quellcode:

var 
  ResultSet: IZResultSet;
  rs: RawByteString;
begin 
  with ZConnection1.DbcConnection.PrepareStatement('select CryptedField from deine.tabelle') do
  begin 
    ResultSet := ExecuteQueryPrepared;
    while ResultSet.Next do
      rs := ResultSet.GetBinaryStringByName('CryptedField'); //Ergebis ist der direkt von der DB gelieferten nicht encodierte String
    ResultSet.Close;
    ResultSet := nil;
    Close;
  end;
end;

Das funzt auf jeden Fall.
Kannst du damit etwas anfangen? Zeos läßt dem Benutzer in jeder hinsicht alle Freiheiten.

Gruß Michael