3. Bytes verstehen (Netzwerk)

Bytes verstehen (Netzwerk)

  • T

    Hallo,

    ich habe auch nach jahrelangem programmieren in C++ noch nicht wirklich alle Einzelheiten von Encoding bzw. Bytes verstanden...

    Ich bin gerade dabei, einen kleinen Webserver zur Übung zu implementieren und stehe nun vor dem Problem, dass ich entweder char oder wchar_t benutzen muss. Aber die send -Funktion akzeptiert ja nur char* bzw. unsigned char* .

    Meiner unqualifizierten Meinung nach, kann ich einfach meine Antwort auf einen Request mit std::wstring bzw. wchar_t erstellen und beim send -Aufruf dann casten. Aber gehen dort nicht Informationen verloren?

    Woher weiß der Webbrowser, dass er das ganze dann auch als UTF-8 ansehen muss? Ich meine, wenn die Header UTF-8 enkodiert sind, woher kann der Browser dann aus dem Header Content-[s]Encoding[/s]Type entnehmen, dass es sich um UTF-8 handelt? Versteht ihr was ich meine? Ein wenig das "Henne-Ei"-Problem.

    Und dann gibt es ja noch Little- oder Big-Endianess. Inwieweit muss ich so etwas beachten?

    Vielen Dank für eure Hilfe!

    0
  • C

    Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (auch C++0x und C++11) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • T

    wchar_t sollte man nie benutzen, weil unportabel und doofes Konzept. char ist für UTF-8 geeignet und das ist im Web die geeignete Kodierung.
    Ein HTTP-Header verwendet ASCII, also wieder char .
    send() nimmt char * , da könnte aber auch void * oder jeder andere Zeigertyp stehen. Es sendet reine Daten ohne bestimmte Kodierung.
    Endianness spielt hier keine Rolle.

    0
  • T

    TyRoXx schrieb:

    wchar_t sollte man nie benutzen, weil unportabel und doofes Konzept.

    Kannst du das näher Erläutern bzw. mir weitere Links schicken (oder einen Suchbegriff nennen)? Warum gibt es dann std::wstring ?

    TyRoXx schrieb:

    char ist für UTF-8 geeignet und das ist im Web die geeignete Kodierung.

    Wtf - ich dachte, dass char auf den aller meisten Systemen nur 1 Byte hat. Wie soll da ein UTF-8 Zeichen reinpassen?

    TyRoXx schrieb:

    Ein HTTP-Header verwendet ASCII, also wieder char .

    Endlich mal eine ordentliche Aussage. Warum finde ich so was klares nie im Web?

    TyRoXx schrieb:

    send() nimmt char * , da könnte aber auch void * oder jeder andere Zeigertyp stehen. Es sendet reine Daten ohne bestimmte Kodierung.

    Mhh, okay... Also muss ich mir es quasi so vorstellen, als ob char gewählt wurde, um Bytes zu repräsentieren. Korrekt?

    TyRoXx schrieb:

    Endianness spielt hier keine Rolle.

    Warum eigentlich nicht? Normalerweise ist so etwas bei Netzwerkprogrammierung doch wichtig, oder nicht?

    0
  • B

    theliquidwave schrieb:

    TyRoXx schrieb:

    Endianness spielt hier keine Rolle.

    Warum eigentlich nicht? Normalerweise ist so etwas bei Netzwerkprogrammierung doch wichtig, oder nicht?

    Nur, wenn Du so etwas machen willst:

    ...

int x;

...

send(sock, (char *)&x, sizeof(int), 0);

    Weil auf Systemen mit unterschiedlicher Endianness die Bytes der Ganzzahltypen in unterschiedlicher Reihenfolge im Speicher liegen.
    Solange Du lediglich Zeichen herumschickst, ist Endianness irrelevant.

    0
  • T

    Ah, ich verstehe. Weil hier ja das Encoding zuständig ist 🤡
    Danke für die Erläuterung!

    0
  • Mod

    theliquidwave schrieb:

    TyRoXx schrieb:

    char ist für UTF-8 geeignet und das ist im Web die geeignete Kodierung.

    Wtf - ich dachte, dass char auf den aller meisten Systemen nur 1 Byte hat. Wie soll da ein UTF-8 Zeichen reinpassen?

    Genau das ist doch der Trick an UTF-8: Die Zeichen werden als normale 8-Bit chars codiert, bei Bedarf nimmt man eben mehrere davon für ein einzelnes Zeichen. Vorteil ist, dass man an Programmen nicht viel (oder idealerweise überhaupt nichts) ändern muss. Wenn sie mit char-Ketten umgehen können, dann können sie auch UTF-8. Nachteil ist, dass die Länge einer Zeichenkette in Byte nicht mehr (unbedingt) der Länge in Zeichen entspricht, was einiges verkompliziert und Programme, die hiervon ausgehen, funktionieren nicht mehr.

    http://en.wikipedia.org/wiki/Utf-8

    0
  • T

    Hört sich für mich ziemlich nach Rumgefrickel an.
    Wieso verwende ich nicht gleich wchar_t ? Da habe ich doch die Garantie, dass es immer gleich lang ist. Probleme ergeben sich dann doch erst gar nicht? Oder hat es andere Nachteile? (Speicherplatzverbrauch mal außen vorgelassen)

    0
  • M

    theliquidwave schrieb:

    Wieso verwende ich nicht gleich wchar_t ? Da habe ich doch die Garantie, dass es immer gleich lang ist.

    wchar_t ist keine Codierung, genau wie char keine ist. Und gleich lang ist das auch nicht überall, die Länge von wchar_t ist nämlich nicht standardisiert.

    0
  • ?

    Jahrelang irgendwas machen bedeutet nicht automatisch dass mein ein Profi oder Experte ist, wo dieser Unsinn immer herkommt 🙄

    0
  • T

    frickli schrieb:

    Jahrelang irgendwas machen bedeutet nicht automatisch dass mein ein Profi oder Experte ist, wo dieser Unsinn immer herkommt 🙄

    Wie gut, dass ich das nie behauptet habe 🤡

    Danke für die Erklärungen 😉

    0
  • C

    theliquidwave schrieb:

    wchar_t ? Da habe ich doch die Garantie, dass es immer gleich lang ist.

    Die Garantie hast du nicht.

    Wenn ich mit nicht irre, ist wchar_t auf Windows 2 Byte groß. Windows benutzt aber utf-16, also hast du auch bei wchar_t das Problem, dass nicht jedes Zeichen in einen wchar_t passt. Bei utf-16 gibt es Zeichen, für die zwei aufeinanderfolgende wchar_t benötigt werden.

    0
  • K

    Wenn du ein wenig Englisch kannst, hier wird vieles gut erklärt:
    http://www.joelonsoftware.com/articles/Unicode.html

    0
Anmelden zum Antworten