Das Notes Forum

Domino 9 und frühere Versionen => ND9: Entwicklung => Thema gestartet von: bikerboy am 14.02.20 - 09:03:57

Titel: [gepfuscht] Umlaute in einem HTTP-Request kommen auf der Gegenseite nicht an
Beitrag von: bikerboy am 14.02.20 - 09:03:57

Moin,

ich habe hier ein Problem, wenn ich aus einem Agenten heraus einen HTTP_Request sende. Das ganze läuft über die C-API. Wenn im Body Umlaute enthalten sind kommen die auf der Gegenseite nicht richtig an.

Ich habe dem Header schon den Content-Type : application/json ;charset=utf-8 mit gegeben, aber leider ohne Erfolg. Wenn ich mir den Request aus Notes geben lasse , habe ich im String auch meine Umlaute sauber drin. Der Inhalt kommt aus einem Stream, der eine Datei mit UTF-8 Codepage ausliesst. Mein Verdacht ist nun, dass er zwar mit UTF-8 ausliest, aber in meiner String Variable wieder mit was internen Arbeitet. Die Frage ist wie kann ich das nun umgehen?

Wenn ich die Gegenseite mit dem Tool Postman anspreche, arbeitet der Service wie gewüncht. Also muss Notes schuld sein! Bzw. ICH weil ich habe es ja programmiert, freue mich über Hilfe.

Gruss Robert

Titel: Re: Umlaute in einem HTTP-Request kommen auf der Gegenseite nicht an
Beitrag von: bikerboy am 14.02.20 - 14:04:50

Habe nun schon den Inhalt in ein MIMEItem aus dem Stream gelesen, ohne Erfolg.

Weiterhin habe ich gesehen, dass die C-API die ich verwende immer mit dem Suffix "A" ist.

Code

Note  The HttpSendRequestA function represents headers as ISO-8859-1 characters not ANSI characters. The HttpSendRequestW function represents headers as ISO-8859-1 characters converted to UTF-16LE characters. As a result, it is never safe to use the HttpSendRequestW function when the headers to be added can contain non-ASCII characters. Instead, an application can use the MultiByteToWideChar and WideCharToMultiByte functions with a Codepage parameter set to 28591 to map between ANSI characters and UTF-16LE characters.

Als ich die C-APIs aber auf den Suffix W geändert habe, komme ich gar nicht erst zu der stelle wo ich den Request absende, weil mir die entsprechenden Handles fehlen.

Anbei die Liste der verwendeten Apis :

Code

Declare Function xW32_InternetOpen Lib "wininet.dll" Alias "InternetOpenW"
Declare Function xW32_InternetConnect Lib "wininet.dll" Alias "InternetConnectW" 
Declare Function xW32_HttpOpenRequest Lib "wininet.dll" Alias "HttpOpenRequestW"
Declare Function xW32_HttpAddRequestHeaders Lib "wininet.dll" Alias "HttpAddRequestHeadersW"
Declare Function xW32_HttpSendRequest Lib "wininet.dll" Alias "HttpSendRequestW"
Declare Function xW32_InternetReadFile Lib "wininet.dll" Alias "InternetReadFile"

Ich hatte auch schon die A und W gemischt und konnte damit einen Request auslösen auf meinem anderen Server, allerdings hat er in dem Moment meinen Body komplett verschluckt, obwohl mein Log sagt, dass ich einen Moment vorher noch einen Body habe.

Titel: Re: Umlaute in einem HTTP-Request kommen auf der Gegenseite nicht an
Beitrag von: jBubbleBoy am 17.02.20 - 19:43:07

Hatte kürzlich den Fall in die andere Richtung, also eine Webseite führt ein Post-Request gegen einen LS-Agenten aus,
und da kamen Sonderzeichen falsch an. Eine Suche hat mich zu diesem Eintrag geführt:
https://domino-ideas.hcltechsw.com/ideas/IDEAAD-I-119

Bei Dir wird das Problem sein, dass LotusScript nicht wirklich mit Codepages umgehen kann und Notes hier auch keinen
Standard verwendet, was wahrscheinlich historisch bedingt ist.
In Notes kenne ich nur I/O Funktionen die Codepages unterstützen, also NotesStream oder der Befehl Open.

Mein Problem habe ich durch einen Java-Agenten gelöst, was auch in Deinem Fall wohl die Lösung sein wird oder
konntest Du dein Problem lösen?

Titel: Re: Umlaute in einem HTTP-Request kommen auf der Gegenseite nicht an
Beitrag von: bikerboy am 18.02.20 - 17:03:34

Ich hatte noch einen anderen Eintrag gefunden, der sich einen eingebaute convertierung wünscht.

Ich habe es nun ganz ganz schmutzig im LS Agenten gelöst. Ich "encodiere" die Sonderzeichen nun in den entsprechenden UTF-8 String also %C3%BC und setzte das auf der Gegenseite wieder um. Ich bin nicht glücklich damit aber in 2 Monaten fliegt der Agent wieder weg, weil wir dann den node.js direkt ansprechen. Bis dahin sollte einfach keiner auf die Idee kommen ein Yen-Zeichen zu nutzen.  ;)