Hindi-String in FB-Datenbank?

[fehlerchen]

Hallo,

mir will es nicht gelingen, einen String aus Hindi-Worten in einer Firebird-Datenbank abzuspeichern.
Wenn ich die Zeichenkette
प्रभावित व्यक्ति को ताजा हवा में निकालें और अनियंत्रित श्वास की अनुमति दें।
direkt in ibExpert in ein String- oder UTF8- Datenbankfeld schreibe, wird dieses geschrieben als
पà¥�रà¤*ावित वà¥�यकà¥�ति को ताजा हवा में निकालें और अनियंतà¥�रित शà¥�वास की अनà¥�मति दें।

Diese Zeichenkette kann dann auch als RawByteString von Delphi aus in die Datenbank geschrieben werden.
Aber wie kann ich ihn mir selbst in Delphi aus dem originalen Hindi-String erzeugen, um die Datenbank zu befüllen?

Ein ähnlicher, aber nicht gleicher RawByteString ist folgendermaßen erzeugbar:
TmpTestString := 'प्रभावित व्यक्ति को ताजा हवा में निकालें और अनियंत्रित श्वास की अनुमति दें।'; // die Darstellung im Delphi-Text zeigt seltsame Darstellung mit zusätzlichen Abständen zwischen den Worten, die mir nicht erklärlich sind. - Kann man Delphi Optionen mitgeben, die bewirken, dass in der Delphi ide ebenso, wie hier im Forum dargestellt wird - mit nur einem Leerzeichen zwischen den Worten?
TmpRawByteString := Utf8Encode(TmpTestString);
SetCodePage(TmpRawByteString, 28591, False);

ATable.FieldByName(dq_Text).AsString := TmpRawByteString;
ATable.FieldByName(dq_TextUtf8).AsString := TmpRawByteString; // wirft Fehler malformed String -303



Der andere Weg, den Hindi-String direkt per Delphi in die Datenbank zu schreiben, führt beim UTF8-Feld zum Fehler 'Malformed String'.
Was muss ich denn beachten, damit ich auf einer gewachsenen Firebird-Datenbank mit ursprünglich charset NONE ohne MalformedString-Fehler zu arbeiten?
Zugegriffen wird auf die Datenbank mittels...:

object TheConnection: TFDConnection
Params.Strings = (
'Server=192....'
'Database=/....fdb'
'SQLDialect=1'
'Protocol=TCPIP'
'User_Name=...'
'Password=...'
'DriverID=FB'
'CharacterSet=UTF8')

Muss das CharacterSet noch anderswo oder anders gesetzt werden?

[Redeemer]

Zur Frage in der Mitte des Posts: Die Delphi IDE zeigt alle Buchstaben in der eingestellten Nichtproportionalschrift an, die verfügbar sind. Demnach ist das Leerzeichen immer so breit, wie ein nichtproportionales Leerzeichen eben ist. Hindi-Zeichen sind in Nichtproportionalschriften i.d.R. nicht enthalten.

[fehlerchen]

Danke, Redeemer.

Hier handelt es sich aber nicht um proportional- oder nicht-proportional dargestellte einzelne Leerzeichen.
Die Lücken, die größer sind, als die einzelnen Wörter (sieht man nur, wenn dieser Hindi-String in Quellcode der IDE eingefügt wird), sind mit dem jeweils vorhergehenden Wort verknüpft.
Versucht man, Teile davon herauszulöschen, dann ändert sich das vorstehende Wort mit.

Ich habe es auch nur erwähnt, weil es möglicherweise von Relevanz für mein eigentliches Problem ist, dass ich aus dem Hindi keinen ordentlichen String generiert bekomme, den ich in die Datenbank schreiben kann.

[hstreicher]

Hier wird nur das Charset der Verbindung gesetzt, es muss aber auch das Charset der entsprechenden Felder der Tabelle passen,
Charset none ist da die falsche Wahl damit weis weder die DB noch Delphi wie die Zeichen zu interpretieren sind, die Felder sollten UTF-8 sein

ggf muss man die Tabellen neu anlegen

und von SQL Dialect 1 sollte man sich auch verabschieden

welche FB Version wird verwendet ?

mfg Hannes

[fehlerchen]

Die DB wird treiberseitig ja mit utf8 angesprochen.
Eine Spalte der Tabelle wurde ergänzt, die ist utf8 - und so weit ich das weiß, wurde die Tabelle auch neu gebaut.

Muss da sonst noch was gemacht werden?

FB-Version muss ich morgen nachsehen.

Danke übrigens für die Antworten.
Ich suche seit Tagen nach einer Lösung und komme nicht weiter.

Wie macht es denn iBExpert, dass es eine Zeichenkette erzeugt, die speicherfähig ist?
Wenigstens das muss doch in Delphi auch gehen?

[DP-Maintenance]

Dieses Thema wurde am "03. Dec 2018, 21:22 Uhr" von "Luckie" aus dem Forum "Programmieren allgemein" in das Forum "Datenbanken" verschoben.

[jobo]

Zitat:

Zitat von fehlerchen (Beitrag 1420022)

Die DB wird treiberseitig ja mit utf8 angesprochen.
Eine Spalte der Tabelle wurde ergänzt, die ist utf8 - und so weit ich das weiß, wurde die Tabelle auch neu gebaut.

Also was nun? Generell arbeitet nur der Client mit UTF8, aber (immerhin) eine Tabellenspalte ist auch als UTF8 deklariert?

Auf welche dieser Spalten beziehen sich Deine Probleme?
Im Prinzip kannst Du natürlich Spalten einfach als Datencontainer, also Bytes/ Rawbytes betrachten. Das geht für Texte, Zahlen und Datumswerte. Je ausgiebiger Du das machst, desto weniger wird ein Standardsql Werkzeug die Daten richtig anzeigen.
Die Spaltentypen der DB und auch der Zeichensatz der DB haben schon ihren Sinn.

Am Ende braucht es im Programm natürlich auch den geeigneten "Stack" in den Komponenten, um Mulibyte Texte richtig anzuzeigen bzw. eingeben zu können. Das ist als letztes Glied ein Font, der die (alle) gewünschte/benötigten Zeichen darstellen kann.

[hoika]

Hallo,
wie sieht denn den DDL der Tabelle wirklich aus?
Welche DB-Zugriffskomponente benutzt Du, welche Daten-Typ hat ATable -> OK, FireDac;)
Welchen Datentyp hat deine String-Variable?