Stringfunktionen substr() padr() padl() len()
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Stringfunktionen substr() padr() padl() len()
Hallo
in UTF8 belegen ja z.B. öäü in einem String 2 Bytes.
Zum Bespiel das Wort "Für"
Dafür stehen in Oem die Zeichen 70, 129, 114
in UTF-8 wird der String länger es stehen die Zeichen 70,195,188,114
Also in OEM ist die Länge des Strings 3 in UTF8 4 Zeichen
werden nun Strings gekürzt z.B. Padr( x,2 ) fehlt bei "Für" in UTF8 das 2.Zeichen des ü was beim Schreiben z.B. in Postgres zu einem Fehler führt.
Die Frage: Gibt es String Funktionen wie Len() Padr() usw. die den Zeichensatz berücksichtigen und z.B. für das Wort "Für" in UTF8 auch nur 3 nicht 4 zurückgeben?
Also die Anzahl druckbarer Zeichen. MIt UTF8 ist nichts mehr wie vorher, für ein Datenfeld von 4 Zeichen muss eigentlich mit 8 Zeichen gerechnet werden ....
Könnte das der Grund sein wieso uns Xbase++ auch kein kein UTF8 bietet?
Gruss Carlo
in UTF8 belegen ja z.B. öäü in einem String 2 Bytes.
Zum Bespiel das Wort "Für"
Dafür stehen in Oem die Zeichen 70, 129, 114
in UTF-8 wird der String länger es stehen die Zeichen 70,195,188,114
Also in OEM ist die Länge des Strings 3 in UTF8 4 Zeichen
werden nun Strings gekürzt z.B. Padr( x,2 ) fehlt bei "Für" in UTF8 das 2.Zeichen des ü was beim Schreiben z.B. in Postgres zu einem Fehler führt.
Die Frage: Gibt es String Funktionen wie Len() Padr() usw. die den Zeichensatz berücksichtigen und z.B. für das Wort "Für" in UTF8 auch nur 3 nicht 4 zurückgeben?
Also die Anzahl druckbarer Zeichen. MIt UTF8 ist nichts mehr wie vorher, für ein Datenfeld von 4 Zeichen muss eigentlich mit 8 Zeichen gerechnet werden ....
Könnte das der Grund sein wieso uns Xbase++ auch kein kein UTF8 bietet?
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Martin Altmann
- Foren-Administrator
- Beiträge: 16536
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 113 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: Stringfunktionen substr() padr() padl() len()
Moin Carlo,
hast Du Dir mal die aktuellen Videos auf Alaskas Youtube-Channel angeschaut? Sehr interessant, gerade auch im Hinblick auf Deine Frage.
Ist in der aktuellen Version wohl drin (wenn ich das richtig in Erinnerung habe).
Viele Grüße,
Martin
hast Du Dir mal die aktuellen Videos auf Alaskas Youtube-Channel angeschaut? Sehr interessant, gerade auch im Hinblick auf Deine Frage.
Ist in der aktuellen Version wohl drin (wenn ich das richtig in Erinnerung habe).
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Stringfunktionen substr() padr() padl() len()
Hallo Martin
Danke, ja die Videos habe ich jetzt gesehen.
Da wird jedoch von Unicode gesprochen aber ab wann und wie das geht habe ich nicht gefunden.
In der Xbase Hilfe gibt es z.B. UniCode2Str() da heist es klar: UTF-8 wird nicht unterstüzt! Nur UTF-16
Gruss Carlo
Danke, ja die Videos habe ich jetzt gesehen.
Da wird jedoch von Unicode gesprochen aber ab wann und wie das geht habe ich nicht gefunden.
In der Xbase Hilfe gibt es z.B. UniCode2Str() da heist es klar: UTF-8 wird nicht unterstüzt! Nur UTF-16
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Stringfunktionen substr() padr() padl() len()
Hallo Carlo,
und das halte ich für ein Problem. Sicher ist UTF-16 der Zeichensatz für Windows. Aber im Internet wird größtenteils UTF-8 verwendet. Also muß ich auch diese verarbeiten können. Zumindest müsste es Konvertierungsfunktionen geben. Von und nach UTF-8. Aber da muß man sich im Moment mit ot4xb behelfen. Oder wie ich mit alten Funktionen von Günter B. Die aber natürlich nur von und nach ANSI gehen, womit dann Zeichen verloren gehen.
Und leider spricht Alaska heute im Gegensatz zu Ankündigungen von Steffen von vor ein paar Jahren nicht mehr davon, die dbf Unicode-fähig zu machen. Alaska geht eindeutig weg von XbParts hin zu HTML, und von dbf hin zu SQL. Die bisherigen starken Eigenschaften von Xbase++ werden noch mitgeschleppt, aber nicht mehr weiterentwickelt. Dumm gelaufen.
Jan
und das halte ich für ein Problem. Sicher ist UTF-16 der Zeichensatz für Windows. Aber im Internet wird größtenteils UTF-8 verwendet. Also muß ich auch diese verarbeiten können. Zumindest müsste es Konvertierungsfunktionen geben. Von und nach UTF-8. Aber da muß man sich im Moment mit ot4xb behelfen. Oder wie ich mit alten Funktionen von Günter B. Die aber natürlich nur von und nach ANSI gehen, womit dann Zeichen verloren gehen.
Und leider spricht Alaska heute im Gegensatz zu Ankündigungen von Steffen von vor ein paar Jahren nicht mehr davon, die dbf Unicode-fähig zu machen. Alaska geht eindeutig weg von XbParts hin zu HTML, und von dbf hin zu SQL. Die bisherigen starken Eigenschaften von Xbase++ werden noch mitgeschleppt, aber nicht mehr weiterentwickelt. Dumm gelaufen.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Stringfunktionen substr() padr() padl() len()
Hallo Jan
Verlorene Zeichen sind nicht tolerierbar den diese führen bei Postgres zum Abbruch. (Befehle mit ungültigen Zeichen führen zum Befehlsabbruch)
UTF-16 ist mit Postgres nicht möglich.
Erneut eine Verfahrene Situation!
Gruss Carlo
Nein, bei weitem nicht. Desaster oder GAU trifft die Situation wohl wesentlich besser!und das halte ich für ein Problem
Verlorene Zeichen sind nicht tolerierbar den diese führen bei Postgres zum Abbruch. (Befehle mit ungültigen Zeichen führen zum Befehlsabbruch)
UTF-16 ist mit Postgres nicht möglich.
Erneut eine Verfahrene Situation!
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Stringfunktionen substr() padr() padl() len()
Carlo,
PostgreSQL kann kein UTF-16? Dann verstehe ich nicht, was Alaska da macht. Wenn die sich wegen des Windows-Zeichensatzes auf UTF-16 beschränken, und UTF-8 nicht verfolgen - wie soll das dann mit der so sehr propagierten PostgreSQL-Unterstützung laufen? Ich stecke da nicht tief genug drin, um da wirklich etwas produktives zu sagen zu können, aber das finde ich dann doch schon sehr merkwürdig.
Soll die dann mit ANSI gefüllt werden? Die Frage war rhetorisch gemeint
Das wäre doch mal eine Anfrage bei Alaska wert?
Jan
PostgreSQL kann kein UTF-16? Dann verstehe ich nicht, was Alaska da macht. Wenn die sich wegen des Windows-Zeichensatzes auf UTF-16 beschränken, und UTF-8 nicht verfolgen - wie soll das dann mit der so sehr propagierten PostgreSQL-Unterstützung laufen? Ich stecke da nicht tief genug drin, um da wirklich etwas produktives zu sagen zu können, aber das finde ich dann doch schon sehr merkwürdig.
Soll die dann mit ANSI gefüllt werden? Die Frage war rhetorisch gemeint
Das wäre doch mal eine Anfrage bei Alaska wert?
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Stringfunktionen substr() padr() padl() len()
Hallo Jan
Ja, Postgres kann kein UTF-16 siehe in der Liste https://www.postgresql.org/docs/9.6/sta ... ibyte.html
Wir überlegen nun alles zurück auf den Latin-1 Zeichensatz umzuschreiben. Und gut ist.
Jedes Produkt hat einen Lebenszyklus, meines, deines und auch Xbase von Alaska...
ich hoffe dass Xbase++ noch nicht EOL ist und ich dieses noch bis zur Rente einsetzten kann, nachdem ein Freund in New York war habe ich gemischte Gefühle ...
Gruss Carlo
Ja, Postgres kann kein UTF-16 siehe in der Liste https://www.postgresql.org/docs/9.6/sta ... ibyte.html
Ganz einfach --> Sie konvertieren UTF8 <--> UTF16 (Meine Vermutung)wie soll das dann mit der so sehr propagierten PostgreSQL-Unterstützung laufen?
Dazu habe ich leider die Zeit nicht. Alaskas Wege und Ideen werden für mich immer weniger nachvollziehbar, die Wege sind unergründlich......Das wäre doch mal eine Anfrage bei Alaska wert?
Wir überlegen nun alles zurück auf den Latin-1 Zeichensatz umzuschreiben. Und gut ist.
Jedes Produkt hat einen Lebenszyklus, meines, deines und auch Xbase von Alaska...
ich hoffe dass Xbase++ noch nicht EOL ist und ich dieses noch bis zur Rente einsetzten kann, nachdem ein Freund in New York war habe ich gemischte Gefühle ...
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- AUGE_OHR
- Marvin
- Beiträge: 12911
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Stringfunktionen substr() padr() padl() len()
UTF-16 ist eine Kodierung mit variabler Länge für Unicode-Zeichen (UTF-8).
wenn man nun jeweils 2 x UTF-8 mit UTF-16 "verarbeitet" wird das bis zu 150% schneller sein (theoretisch)
es ist so ähnlich wie bei 64bit API Functionen wo als "LoWord" und "HiWord" jeweils 32bit verwendet.
---
@ramses
ein Windows String wird üblicherweise mit CHR(0) beendet.
wenn man nun jeweils 2 x UTF-8 mit UTF-16 "verarbeitet" wird das bis zu 150% schneller sein (theoretisch)
es ist so ähnlich wie bei 64bit API Functionen wo als "LoWord" und "HiWord" jeweils 32bit verwendet.
---
@ramses
ein Windows String wird üblicherweise mit CHR(0) beendet.
Code: Alles auswählen
nLen := AT(CHR(0),cBuffer)
IF IsUnicode(cBuffer)
cBuffer := Unicode2Str(cBuffer)
ELSE
cBuffer := SUBSTR(cBuffer,1,nLen-1)
ENDIF
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Stringfunktionen substr() padr() padl() len()
Hallo Jimmy
leider nein Jimmy
UTF16 speichert jedes Zeichen als 16Bit Wert so wird das Wort "wo" als chr(119)+chr(0)+chr(111)+chr(0) gespeichert. 2 Zeichen 4 Bytes.
das zeigt dir auch: len(str2unicode("wo")) = 4 !
Dies lässt sich mit Postgres und vielen anderen Dingen nicht verwenden.
UTF8 speichert Zeichen bis chr(127) als 1 Byte erst die Sonderzeichen werden mit 2 oder mehr Bytes gespeichert, wobei die höchsten 3 Bits des ersten Bytes die Länge(Bytes) des Zeichens angeben.
Besonders bei UTF8 kann ein Text von 10 Zeichen zwischen 10-20 Bytes Speicher benötigen...... Du kannst nicht mehr einfach Padr(x,10) anwenden wenn du nur 10 Zeichen möchtest, dies schneidet nach 10 Bytes den Text ab. Dies könnten dann 5 ö's sein oder an 10 Stelle steht ein ö dann wird das erste Byte des UTF8 codierten ö Zeichens mitgenommen das 2 Abgeschnitten und der String ist ungültig.
UTF-16 gibts dann noch als BE oder LE kurz ein ganz schlechtes Format, einzig in der Eile besser zu handeln da Anzahl Zeichen * 2 = Anzahl Bytes ergibt.
Gruss Carlo
leider nein Jimmy
UTF16 speichert jedes Zeichen als 16Bit Wert so wird das Wort "wo" als chr(119)+chr(0)+chr(111)+chr(0) gespeichert. 2 Zeichen 4 Bytes.
das zeigt dir auch: len(str2unicode("wo")) = 4 !
Dies lässt sich mit Postgres und vielen anderen Dingen nicht verwenden.
UTF8 speichert Zeichen bis chr(127) als 1 Byte erst die Sonderzeichen werden mit 2 oder mehr Bytes gespeichert, wobei die höchsten 3 Bits des ersten Bytes die Länge(Bytes) des Zeichens angeben.
Besonders bei UTF8 kann ein Text von 10 Zeichen zwischen 10-20 Bytes Speicher benötigen...... Du kannst nicht mehr einfach Padr(x,10) anwenden wenn du nur 10 Zeichen möchtest, dies schneidet nach 10 Bytes den Text ab. Dies könnten dann 5 ö's sein oder an 10 Stelle steht ein ö dann wird das erste Byte des UTF8 codierten ö Zeichens mitgenommen das 2 Abgeschnitten und der String ist ungültig.
UTF-16 gibts dann noch als BE oder LE kurz ein ganz schlechtes Format, einzig in der Eile besser zu handeln da Anzahl Zeichen * 2 = Anzahl Bytes ergibt.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Stringfunktionen substr() padr() padl() len()
@Jimmy, UTF16 / UTF32 ist nicht variabel in der Länge sondern x2 bzw. x4 bei jedem Zeichen.
daher verwendet PostGreSQL INTERN und das Internet ja auch UTF-8
@ Rest
Aber laut der Seite - so zumindest verstehe ich das - ist die interne Speicherung UTF-8, der client kann haben was er will und mit UTF-8 oder Ansi oder UTF 16 / 32 sollte es keine Probleme geben,
das "sollte" die API transparent erledigen. Bei ODBC Zugriffen ist das z.B. definitiv so, das habe ich schon gemacht.
ABER um z.b. LEN(cUtf8String) einfach so nutzen zu können, wie ein len(cAnsiString), dafür müsste Xbase++ UTF8 als Datenformat unterstützen.
Das tut es aktuell nicht, daher verwende ich über ODBC den Treiber der mir ANSI Schnittstelle, es gäbe auch einen mit WideString (UTF16 !), soweit ich gelesen habe will Microsoft zu 32 bit UTF32 wechseln.
Aber die Treiber müssten das intern regeln.
Was Xbase++ einmal können wird ist völlig ungewiss, daher muss man das nutzen was es kann.
Bei meinen DLL Zugriffen verwende ich daher immer die Ansi Schnittstelle fals verfügbar. Bei QuickPDF war die zwischenzeitlich nicht mehr vorhanden.
Nur noch UTF8 Strings durften übergeben werden, daher musste ich (Version weiß ich nicht mehr) die Ansi Strings von Xbase++ mit ot4xb IN MEINER DER KLASSEN METHODE auf UTF8 umsetzen und die Rückgabe wieder zurück.
Wer eine solche Klasse schreibt muss das einfach berücksichtigen und richtig regeln.
Der normale Klassen Verwender erhält dann Ansi und liefert Ansi (oder OEM), alles andere ist nicht praktikabel !
daher verwendet PostGreSQL INTERN und das Internet ja auch UTF-8
@ Rest
Aber laut der Seite - so zumindest verstehe ich das - ist die interne Speicherung UTF-8, der client kann haben was er will und mit UTF-8 oder Ansi oder UTF 16 / 32 sollte es keine Probleme geben,
das "sollte" die API transparent erledigen. Bei ODBC Zugriffen ist das z.B. definitiv so, das habe ich schon gemacht.
ABER um z.b. LEN(cUtf8String) einfach so nutzen zu können, wie ein len(cAnsiString), dafür müsste Xbase++ UTF8 als Datenformat unterstützen.
Das tut es aktuell nicht, daher verwende ich über ODBC den Treiber der mir ANSI Schnittstelle, es gäbe auch einen mit WideString (UTF16 !), soweit ich gelesen habe will Microsoft zu 32 bit UTF32 wechseln.
Aber die Treiber müssten das intern regeln.
Was Xbase++ einmal können wird ist völlig ungewiss, daher muss man das nutzen was es kann.
Bei meinen DLL Zugriffen verwende ich daher immer die Ansi Schnittstelle fals verfügbar. Bei QuickPDF war die zwischenzeitlich nicht mehr vorhanden.
Nur noch UTF8 Strings durften übergeben werden, daher musste ich (Version weiß ich nicht mehr) die Ansi Strings von Xbase++ mit ot4xb IN MEINER DER KLASSEN METHODE auf UTF8 umsetzen und die Rückgabe wieder zurück.
Wer eine solche Klasse schreibt muss das einfach berücksichtigen und richtig regeln.
Der normale Klassen Verwender erhält dann Ansi und liefert Ansi (oder OEM), alles andere ist nicht praktikabel !
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Stringfunktionen substr() padr() padl() len()
Hallo Hubert
Ich verwende intern und soweit es für Web-Apps geht wieder ausschliesslich ANSI. Die Umstellung der Verarbeitung auf UTF8 ist vom Tisch.
Für Datatables, Script die nur UFT-8 verarbeiten können konvertiere ich dies halt auf UTF8 und zurück (Dank an ot4xb)
So gibt es auch keine Probleme.
Ein UTF? in Xbase müsste sowieso auschaltbar oder wählbar sein, denn es gibt ja auch Binäre Strings die keine "Texte" sind, keinen Bezug zu Zeichensätzen haben aber in Bezug von Länge usw. korrekt verarbeitet werden müssen.
Gruss Carlo
auf das bin ich nun auch gekommen.Was Xbase++ einmal können wird ist völlig ungewiss, daher muss man das nutzen was es kann.
Ich verwende intern und soweit es für Web-Apps geht wieder ausschliesslich ANSI. Die Umstellung der Verarbeitung auf UTF8 ist vom Tisch.
Für Datatables, Script die nur UFT-8 verarbeiten können konvertiere ich dies halt auf UTF8 und zurück (Dank an ot4xb)
So gibt es auch keine Probleme.
Ein UTF? in Xbase müsste sowieso auschaltbar oder wählbar sein, denn es gibt ja auch Binäre Strings die keine "Texte" sind, keinen Bezug zu Zeichensätzen haben aber in Bezug von Länge usw. korrekt verarbeitet werden müssen.
Gruss Carlo
Valar Morghulis
Gruss Carlo
Gruss Carlo