Binmode STDOUT

DocShoe

Beschreib doch bitte mal genau, was du erreichen möchtest. Was erwartest du, und was ist das aktuelle Ergebnis? Soweit ich verstanden habe verhält sich dein Code auf dem Zielsystem anders als auf dem Testsystem, aber wie macht sich der Unterschied bemerkbar?

firefly

@_ro_ro sagte in Binmode STDOUT:

@DocShoe

mit write wird das auch nichts das habe ich schon probiert. Das Problem ist, wie gesagt nur lokal auf Win 10. Ich sehe das übrigens auch daran, daß Inhalte einer <textarea> anders ankommen wenn das HTML nicht im Binmode rausgeht. Das war aber auch schon immer so und mit Perl kein Problem generell den Binmode zu setzen.

MFG

Öhm kann es sein, dass der text in utf-8 codiert ist? Denn das funktioniert unter windows nicht by default.
Dort wird nicht utf-8 für std::cout verwendet sondern eine ANSI Kodierung. Bzw. das "Terminal" (cmd.exe, powershell und co) interpretieren die Daten in der eingestellten ANSI Kodierung.

_ro_ro

@DocShoe sagte in Binmode STDOUT:

Beschreib doch bitte mal genau, was du erreichen möchtest. Was erwartest du, und was ist das aktuelle Ergebnis? Soweit ich verstanden habe verhält sich dein Code auf dem Zielsystem anders als auf dem Testsystem, aber wie macht sich der Unterschied bemerkbar?

Ganz einfach: Lokal (Win10) sind Grafiken und PDF-Dateien kaputt und die Zeilenumbrüche bei mehrzeiligen Eingaben in eine <textarea> werden falsch umgesetzt. Serverseitig passiert das nicht, weil das OS generell den binmode setzt.

Ich habe jetzt eine ganz banale Lösung damit ich meine Hauptdatei nicht ändern muß vor dem Deployment:

#include "binmode.c" 

int main(){
   binmode();
...

Und in der Datei serverseitig ist die Funkktion hohl. Lokal steht drin

#include <fcntl.h>
void binmode(){
    setmode(STDIN_FILENO, O_BINARY);
    setmode(STDOUT_FILENO, O_BINARY);
}

Und so sieht das Ergebnis lokal ganz genaus aus wie beim Provider. Ich muss nur aufpassen daß ich die Datei binmode.c nicht aus Versehen hochlade.

MFG

_ro_ro

@firefly

Nee, mit UTF-8-kodierten Texten gibt es generell keine Problems. Die werden einfach so rausgegeben wie sie reinkommen, egal ob User-Input oder aus meinen Dateien. Auch in der cpp-Hauptdatei stehen utf-8-kodierte Literale, ein cout << "Fritz Müller"; wird natürlich nur utf-8-kodiert ausgegeben wenn die .cpp Datei auch als utf-8-kodiert gespeichert wurde (was bei mir selbstverständlich der Fall ist).

MFG

Demo UTF-8 in C++:
http://rolfrost.de/form.chtml

DocShoe

Ok, dann versuche ich nicht, das weiter zu verstehen.

Du kannst aber sowas bauen, wenn der Code nur für Windows-Plattformen ausgeführt werden soll (entsprechendes Makro prüfen, heißt das bei dir _WINDOWS oder anders):

#ifdef _WINDOWS
   #include <io.h>
   #include <fnctl.h>
#endif


void set_file_binary_mode()
{
#ifdef _WINDOWS
   _setmode( _fileno( stdin  ), _O_BINARY  );
   _setmode( _fileno( stdout ), _O_BINARY );
#endif
}

Edit: Quelltext nach MS-Doku angepasst

_ro_ro

@DocShoe sagte in Binmode STDOUT:

Ok, dann versuche ich nicht, das weiter zu verstehen.

Du kannst aber sowas bauen, wenn der Code nur für Windows-Plattformen ausgeführt werden soll (entsprechendes Makro prüfen, heißt das bei dir _WINDOWS oder anders):
#ifdef _WINDOWS
   #include <fnctl.h>
#endif


void set_file_binary_mode()
{
#ifdef _WINDOWS
   _setmode( STDIN_FILENO, O_BINARY );
   _setmode( STDOUT_FILENO, O_BINARY );
#endif
}

Gute Idee!!!

Danke!!

PS: _WIN32

Finnegan

@_ro_ro sagte in Binmode STDOUT:

@DocShoe sagte in Binmode STDOUT:
   _setmode( STDOUT_FILENO, O_BINARY );
Gute Idee!!!

Und? Funktioniert das? Irgendwie habe ich solche Tools bisher nur für Linux geschrieben, aber es wäre gut, wenn sowas dann ohne viel Aufwand auch unter Windows laufen würde. Diese Datenverarbeitungs-Pipelines, die man damit via Kommandozeile zusammenstöpseln kann sind ja schon extrem praktisch:

cat file | tool1 | tool2 | tool3 > processed_file

Schlangenmensch

@_ro_ro Verstehe ich dein Anliegen richtig, dass du das Gif als Binary direkt ins HTML schreiben möchtest? Ich würde mutmaßlich, das Gif in eine extra Datei schreiben und die Datei ins HTML einbinden.

Deine Lösung gefällt mir persönlich nicht. Das scheint irgendwie speziell auf die beiden Systeme mit denen du arbeitest zugeschnitten zu sein ohne das du garantieren kannst, dass das auf einem dritten System jetzt auch funktioniert.

Was du sonst versuchen kannst, ist, durch den String zu iterieren und aus einzelnen Chars ein std::bitset machen und das mit to_string() dann konvertieren.

Wo ich gerade nach Binary Darstellungen von Bildern in HTML google, willst du das wirklich als Binary darstellen? Ich finde nur Base64 encodierte ASCII String representation, aber ich bin in Webtechnologien auch echt schlecht.

_ro_ro

@Schlangenmensch sagte in Binmode STDOUT:

@_ro_ro Verstehe ich dein Anliegen richtig, dass du das Gif als Binary direkt ins HTML schreiben möchtest?

Nein. Und es geht ja auch nicht nur um Grafiken oder PDF oder Zip-Dateien oder sonstige Binaries die nach stdout sollen, sondern auch darum eine HTML-<textarea> im Binmode auszuliefern, da ansonsten die Zeilenumbrüche der Eingaben falsch gesendet werden bei einem Submit via POST. Also einen generellen binmode.

Wo ich gerade nach Binary Darstellungen von Bildern in HTML google, willst du das wirklich als Binary darstellen? Ich finde nur Base64 encodierte ASCII String representation, aber ich bin in Webtechnologien auch echt schlecht.

Jeder Webserver sendet Grafiken als Binary, ein Request like <img src="/red.gif"> weist bspw. den
Webserver an, diese Datei im DOCUMENT_ROOT zu lesen und als Binary via HTTP zu senden.

MFG

DocShoe

@Schlangenmensch sagte in Binmode STDOUT:

...
Was du sonst versuchen kannst, ist, durch den String zu iterieren und aus einzelnen Chars ein std::bitset machen und das mit to_string() dann konvertieren.
...

Das Problem scheint zu sein, dass unterschiedliche Streams zum Lesen und Schreiben der Daten benutzt werden. Wenn die Datei im Binär-Modus gelesen wird landet sie 1:1 im Speicher, beim Schreiben in die Standardausgabe ersetzt das std::cout Objekt unter Windows LF durch CR+LF, was die Binärdaten zerstört (btw: Da hätte ich von @_ro_ro auch gerne mal zwei kurze Hex-Dumps gesehen, die das Problem zeigen). @_ro_ro sucht eine Möglichkeit, diese automatische Übersetzung zu deaktivieren. Das Verhalten steckt iwo im std::cout Objekt, und da hört mein Wissen auf. Ich weiß nicht, ob man das durch das Benutzen einer eigenen locale oder stream_buf steuern kann, da müssen jetzt Leute her, die sich damit auskennen

Edit:
Hab mir mal die MSVC Implementierung auf github angeschaut, da werden std::cinund std::cout über einen filebuf um stdin und stdout gebaut. Zusammen mit der _setmode Funktion bedeutet dass, dass das Verhalten schon in stdin und stdout steckt und unter C++ vllt überhaupt nicht bekannt ist und damit auch nicht verändert werden kann, sondern nur die zu Grunde liegenden stdin und stdout Objekte.

_ro_ro

@DocShoe

die von mir beschiebenen Effekte treten nur unter Win32 auf. XP ging sogar soweit, Dateien spontan zu verändern wenn nicht explizit im BINARY-Mode (sysopen call) darauf zugegriffen wurde. Und als ich vor 10 Jahren mal einen Parser für den grottigen Enctype multipart/form-data in C geschieben habe, musste ich auch feststellen daß C unter Windows per Default keinen Binmode stdin/stdout kennt. der also explizit gesetzt werden muss. In Perl ist das eine Zeile binmode STDOUT und gut isses.

Offensichtlich entwickelt Ihr nicht unter Win32.

MFG

DocShoe

@_ro_ro sagte in Binmode STDOUT:

@DocShoe
Offensichtlich entwickelt Ihr nicht unter Win32.

Steile These

Schlangenmensch

@_ro_ro Hm, irgendwie verstehe ich deine Architektur noch nicht. Du baust in C++ dein HTML zusammen, schreibst das in die Konsole, und liest das dann von da aus mit einer anderen Software ein, die dann die Webseite ausliefert?

Ich frage, weil ich nie auf die Idee gekommen wäre, eine Datei nach std::out zu schreiben

@_ro_ro sagte in Binmode STDOUT:

Offensichtlich entwickelt Ihr nicht unter Win32.

Doch, professionell momentan sogar ziemlich ausschließlich. Aber ich schreibe keine Dateien in die Konsole, hängt dann ja auch noch davon ab, welche Konsole verwendet wird und wie die die Daten interpretiert.

_ro_ro

@Schlangenmensch

Ein CGI-Programm liest von STDIN und schreibt nach STDOUT. Das ist alles was ein CGI-Programm können muss

Guck Dir mal den Standard CGI/1.1 an.

MFG

DocShoe

@Schlangenmensch

Bei CGI Anwendungen sind cin/cout keine Konsolenstreams, sondern umgeleitete Streams des Webservers. Der leitet seine STDOUT Ausgaben in STDIN der Anwendung um und liest über sein STDIN die Daten, die die CGI Anwendung in ihren STDOUT schreibt. Das hat mit der DOS-Konsole unter Windows nichts mehr zu tun, sondern ist ein IPC Mechanismus

(Webserver-Anwendung::stdout) => (CGI::stdin) => (CGI::stdout) => (Webserver-Anwendung::stdin)

_ro_ro

@DocShoe

Genau und als kleine Ergänzung: Die Idee hinter CGI/1.1 ist, einen Layer zu schaffen der HTTP von der Anwendung trennt.

MFG

wob

Und die Antwort auf @_ro_ro ist: geht nicht in Standard-C++, sondern ist "implementation dependent".

Siehe https://isocpp.org/wiki/faq/input-output#binary-mode-for-cin-cout

Hier hat jemand dasselbe gefragt: https://stackoverflow.com/questions/5654067/how-to-make-cout-behave-as-in-binary-mode und die Lösung ist im Prinzip die, die du oben schon nutzt.

Schlangenmensch

@_ro_ro sagte in Binmode STDOUT:

Mein CGI/c++ entwickle ich auf Windows 10

Ah, erste Zeile mitlesen hilft.

Dein "Production System" ist aber ein Linux, richtig? Ist zwar nicht die Lösung des geschilderten Problems, aber ich würde es dann wohl erstmal mit dem Windows Subsystem for Linux probieren um auf einer produktionsnahen Umgebung zu entwickeln.

Ich habe auch mal kurz nach CGI Libraries gegoogelt, die scheinen vor allem FastCGI zu implementieren und damit das Problem zu umgehen.

_ro_ro

@Schlangenmensch

CGI's entwickeln heißt plattformunabhängig entwickeln. Es ist also egal ob man das auf Win32 oder Sun/OS oder Linux tut. Produktionsnah heißt nur, daß man in seiner Entwicklungsumgebung dasselbe Ergebnis bekommt. So sehe ich das und diese Haltung haben alle Unternehmen unterstützt für die ich gearbeitet habe. Was ja auch gar nicht anders umgesetzt werden kann. So habe ich Perl/CGI's entwickelt die auf Sun/Solaris, auf FreeBSD, Debian, IBM AIX und Win32 laufen mussten. Was nicht zuletzt auch einem heterogenem Campus-Netzwerk geschuldet war.

MFG

Schlangenmensch

@_ro_ro Mit nativen Programmiersprachen ist "Crossplattform" aber nicht unbedingt trivial. Es gibt Dinge, die sind OS abhängig, ist gibt Dinge die sind eventuell Compiler Abhängig und so weiter. Du hast jetzt eine Macro Überprüfung ob das ganze auf Windows oder Linux läuft und scheinst damit das korrekte Verhalten zu erziehlen. Was passiert, wenn du das auf einem anderen System kompilierst, weißt du aber nicht.
Ich habe mich mit Perl nicht intensiv beschäftigt, ich würde aber vermuten, dass dir da viel der Interpreter abnimmt.

Produktionsnah bedeutet für mich, dass sich die Systeme ähneln, insbesondere was Compiler und Betriebssystem betrifft, und ich nicht auf Entwicklungs und Produktionsumgebung unterschiedlichen Code ausführe damit es da nicht zu unerwarteten Überraschungen kommt.