BC 15 SAAS Instream Encoding

Hallo Zusammen,

ich habe aktuell ein kleines Problem bezüglich des Encodings in einer BC15 SAAS Lösung.
Es geht um das Einlesen einer .txt Datei im Windows "Ansi-Format". Hierbei werden Sonderzeichen wie "ß","Ä" usw. in BC15 als nicht anzeigbares Zeichen "?" angezeigt.
Da ich in der SAAS Umgebung mit Streams arbeiten muss, finde ich keine Möglichkeit ein Encoding mitzugeben. Ich nutze den CSV-Buffer zum einlesen.

Quellcodeausschnitt zum Import:

Code:

UploadIntoStream('Please chose a .txt import file', ImportFolder, 'txt files (*.txt)|*.txt', ImportFile, FileInstream);
        CSVBuffer.DeleteAll();
        CSVBuffer.LoadDataFromStream(FileInstream, ';');
        IF CSVBuffer.FindSet() then
            repeat
                if (CSVBuffer."Field No." = 2) then
                    ORVProtelCustomerImport.Init();
                case CSVBuffer."Field No." of
                    2:
                        begin
                            ORVProtelCustomerImport."Customer No." := FORMAT(DeleteBadChars(CSVBuffer.Value), 20);
                            IF Cust.Get(ORVProtelCustomerImport."Customer No.") then
                                ORVProtelCustomerImport."Customer exists" := true
                            else
                                ORVProtelCustomerImport."Customer exists" := false;
                        end;
                    4:
                        ORVProtelCustomerImport.Name := Format(DeleteBadChars(CSVBuffer.Value), 100);
                    5:
                        ORVProtelCustomerImport."Name 2" := Format(DeleteBadChars(CSVBuffer.Value), 50);
                    ...


In der Funktion DeleteBadChars entferne ich die " " aus den Strings und habe dort auch schon versucht eine ANSI2ASCI Umwandlung zu machen. leider auch erfolglos:

Code:

local procedure DeleteBadChars(TextP: Text) CleanText: Text
    begin
        CleanText := DelChr(TextP, '=', '"');
        CleanText := Ansi2Ascii(CleanText);
        EXIT(CleanText);
    end;

    procedure Ansi2Ascii(_String: Text[250]) _Output: Text[250];
    begin
        // Converts from ANSI to ASCII
        EXIT(CONVERTSTR(_String, 'óÚÔõÓÕþÛÙÞ´¯ý’µã¶÷ž¹¨ Íœ°úÏÎâßݾ·±Ð¬‡Š«Œ‹“”‘–—¤•ËÈÊš›™',
                                'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®ÁÂÀÊËÈÍÎÏÌÓßÔÒÚÛÙ'));
    end;

Hat noch jemand ne Idee, wie ich z.B. gleich beim Stream das Encoding mitgeben kann?
Danke und Gruß

Einlesen in Blob mit Codeunit "Temp Blob".
https://demiliani.com/2019/09/17/dynami ... ppens-now/

Alternativ gehen noch die bekannten Funktionen der TempBlob-Tabelle, die ist zwar als Obsolete Pending markiert, hat aber in BC 15 ja nun doch noch vermutlich 12 Monate Schonfrist bis zur Entfernung, und dieser Bug sollte da auch behoben sein.

Danke schonmal für die Antwort, Kowa.
Du meintest im Prinzip über die Codeunit so:

Code:

       
    tempblob: Codeunit "Temp Blob";

    begin
        tempblob.CreateInStream(FileInstream, TextEncoding::Windows);
        UploadIntoStream('Please chose a .txt import file', ImportFolder, 'txt files (*.txt)|*.txt', ImportFile, FileInstream);
        CSVBuffer.DeleteAll();
        CSVBuffer.LockTable();
        CSVBuffer.LoadDataFromStream(FileInstream, ';');
        IF CSVBuffer.FindSet() then


bzw. über die Tabelle so:

Code:

        tempblob: Record TempBlob temporary;

    begin
        tempblob.blob.CreateInStream(FileInstream, TextEncoding::Windows);
        UploadIntoStream('Please chose a .txt import file', ImportFolder, 'txt files (*.txt)|*.txt', ImportFile, FileInstream);
        CSVBuffer.DeleteAll();
        CSVBuffer.LockTable();
        CSVBuffer.LoadDataFromStream(FileInstream, ';');
        IF CSVBuffer.FindSet() then


oder?

Beides funktioniert leider nicht.
Sonderzeichen werden immer noch als "?" dargestellt.
Das Encoding wird anscheinend ignoriert oder in der Funktion wird ein neuer Instream initialisiert?

hast du mal ein anderes Encoding als "Windows" genommen?

Ähnlicher Fall mit Workaround hier:
https://github.com/microsoft/AL/issues/2538
Wenn ich den Kommentar von Alexandru Toader dort richtig verstehe, funktioniert das mit dem Webclient bei SaaS-Betrieb gar nicht mehr wie bisher.

@sweikelt
ja hab ziemlich alle Encodings durchprobiert, keine Änderung.
Ich denke aber auch "Windows" müsste das richtige Encoding sein.

@Kowa
Der Workaround den Wert in nen Outstream zu schreiben und dann nochmal in nen Instream hat leider auch nicht funktioniert.
Im CSVBuffer kommen die Sonderzeichen nicht korrekt an...

Es kann doch nicht sein, das ich in einem englischen Server keine deutschen Sonderzeichen mehr einlesen kann??
Zumal es sich hierbei um eine SAAS Lösung handelt.

Es kann doch nicht sein, das ich in einem englischen Server keine deutschen Sonderzeichen mehr einlesen kann??

Mit Englisch oder nicht hat das m.E. gar nichts zu tun. Codepage "Windows" ist ja nur eine ungenaue Umschreibung dafür, dass es sich um Nicht-Unicode-Datei handelt, und dafür gibt es ja nicht nur eine Codepage, sondern viele, bei uns in Westeuropa 1252. Womit sollte ein Server für globalen SaaS-Betrieb da laufen, der gleichzeitig mehrere Regionen abdecken soll? Solange keine neuen Einstellmöglichkeiten für den Tenant dazu kommen, wird die Vorabumwandlung der Datei in Unicode da wohl die einzige Lösung sein.
Aber ich würde empfehlen, das bei Github oder Yammer mal gezielt zu thematisieren. Die derzeitige Situation ist natürlich alles andere als praxisgerecht.

Ich hatte mich bzgl. des englischen Servers auf den Beitrag von Alexandru Toader aus deinem Link bezogen. Er redet da von "English Encoding":

Hi @podgaard ! I think the documentation is outdated. The part about If you set the text encoding to Windows, you can import and export text files that are based on the Windows codepage on the user’s computer. only applies if the user is running the Windows client. If the user is using the web-client and you set the text encoding to Windows, the server's default encoding is used, which is English.

Er sagt ja, dass der WebClient das Encoding des Servers nutzt. Darauf hat man ja aber in einer Microsoft SAAS-Umgebung aktuell keinen Einfluss, korrekt?
Das heißt ich kann nur hoffen das Microsoft hier etwas ändert, ansonsten kann ich keine ANSI-Dateien mit deutschen Sonderzeichen korrekt einlesen....
Wie kann den eine Umwandlung von ANSI nach Unicode in der Praxis aussehen? Müsste man dann jede Datei vorher durch einen Converter laufen lassen?

P.S.:
Einen Beitrag bei Yammer habe ich bereits erstellt und ich bin am Überlegen auch ein Ticket dafür bei MS aufzumachen.

Er redet da von "English Encoding":

Ich weiß, aber so etwas gibt es eigentlich gar nicht mehr. Das gab es mal ab 1963 in Form von US-ASCII als 7-Bit-Codepage (20127), also mit lediglich 127 Zeichen und ohne jegliche Sonderzeichen anderer Sprachen. Alles jenseits der Stelle 128 wird dann zum Fragezeichen.

Was spricht den dagegen, die Datei vorher von OEM nach UTF8 zu konvertieren? Oder, noch besser, der Quelle nahezulegen, zum Datenaustausch ein solides Format zu nutzen, welches dem Namen auch gerecht wird ;~)

Ich habe mittlerweile eine Rückmeldung von dem Microsoft Support erhalten.

Es wurde bestätigt, dass das Grundproblem darin besteht, dass die CSV-Buffer Function "InitializeReaderFromStream" als Default immer UTF 8 benutzt, auch wenn der Input Stream ein anderes Encoding nutzt.
Sie könnten eine überladene Funktion hinzufügen um ein anderes Encoding mitgeben zu können, aber dann könnte es ggf. weitere Probleme geben da die Interpretation des Windows /ANSI Encoding von der Codepage des Servers abhängt, die nicht unbedingt mit der des Clients übereinstimmt...

Es wurde mir daher geraten die .CSV Dateien im UTF-8 Format einzulesen. Ich versuche jetzt herauszufinden, ob die Gegenseite UTF-8 kann.
Kennt ansonsten jemand ne Lösung wie man ANSI Dateien automatisiert nach UTF-8 konvertieren kann?

Hallo,

Kennt ansonsten jemand ne Lösung wie man ANSI Dateien automatisiert nach UTF-8 konvertieren kann?

irgendwas das man um: system.text.encoding.convert herum gestrickt hat, und das auf dem lokalen Arbeitsplatz läuft.

Gruß Fiddi

Was ich mir noch vorstellen könnte, dass man nen Addin zum hochladen der Files entwickelt und Javascript das encoding machen lässt.

Der von MS empfohlene Weg lautet: Azure Function (ich hatte das Thema beim Q&A nach einer Session am Freitag bei den TechDays angesprochen).
Wenn man das gut genug macht, kann man auch einen Pull Request für die System Application einreichen. Geld gibt es dafür aber keins, wenn der akzeptiert wird , nur Ruhm und Ehre .
Umwandlung von ANSI ist ja eher noch ein einfacher Fall, in der Praxis kommen z.B. auch Dateien mit japanischen Schriftzeichen mit Shift-JIS-Codepage, die man vorher auch erst in Unicode umwandeln muss, wobei UTF-8 bei asiatischen Sprachen nicht sehr beliebt ist, weil da bis zu 3 Byte pro Zeichen benötigt werden, und daher eher UTF-16 Verwendung findet.

Lokal kann man das zweite Skript hier zusammen mit dem Dateipfad auf die Datei anwenden.

Hallo,

ich bin mir nicht sicher, ob im Falle von ANSI eine Azure- Funktion funktioniert. Da die ANSI- Kodierung durch den lokalen Client bestimmt wird.

Ein anderes Problem ist der Unterschied beim Einlesen von CSV- Dateien, die deutsche Interpretation von CSV müsste eigentlich SSV (Semicolon Separated Values) heißen und nicht CSV (Comma Separated Values).

Gruß Fiddi

Da die ANSI- Kodierung durch den lokalen Client bestimmt wird.

Deswegen würde ich diesen Teil in der Funktion immer flexibel halten, man kann also die Codepage der Quelle mit angeben.
Das von der Codepage des Clients abhängig zu machen bzw. darauf zu beschränken, war schon immer zu kurz gesprungen. Die Probleme gehen sonst schon los, wenn man Dateien aus PL, CZ usw. erhält, weil dort Zentraleuropa 1250 statt Westeuropa 1252 als Codepage Verwendung findet.

Wenn man die OS-Einstellungen des Clients wirklich abfragen würde wollen, könnte dessen Codepage dann als Zeichensatz der Quelle einspringen, wenn man hier nichts als Parameter angibt.

Wir laden ne Datei von nem FTP Server mit ner Azure function runter, die Datei liegt auch im ANSI vor und wir wandeln diese direkt in UTF-8 um.

Aber wie gesagt - für den hier vorliegenden Fall würde ich einfach ne Javascript Upload Funktion zur Verfügung stellen und dies dann direkt in den richtigen Zeichensatz konvertieren..
zum Beispiel mit: https://github.com/polygonplanet/encoding.js
und anschließend an NAV übergibt

@Ted:
Das funktioniert nur, wenn dir bekannt ist, mit welcher Codepage dieses "Ansi" codiert ist, denn Ansi aus DE ist ein anderes als PL.

Deshalb benötigst du für eine gute "User Experience" die Codepage des hochladenden Clients, und nicht die des Servicetiers. Da nützt dir auch kein Javascript.

Das Problem ist ein ähnliches wie das mit der CSV- Datei, die keine eindeutige Definition hat.

Gruß Fiddi