Unicode

rüdiger

also UTF-8 soll ja ziemlich gut sein, nur ist die Unterstützung zur Zeit noch nicht so weit

Daniel E.

Original erstellt von Mr. N:
Ich möchte euch mal zu eurer Meinung zu Unicode befragen.

Das Gleiche wie ASCII, nur größer. Hört sich irgendwie nach Lernresistenz an, scheint aber vorerst mal einige Problemfälle zu erschlagen.

Von der C++-Standard-Library wird UCS-2 (ich glaub aber auch UTF-32 theoretisch) richtig unterstützt, und UTF-8 ... nunja.

Wie meinen? Quelltexttechnisch? UCS-2 führt dazu, dass Du 8-Bit-cleane Dateien vor jedes Byte ein Nullbyte reinstopfst. Damit fühlt sich mit 'char' (das ja per Definition ein Byte ist) ziemlich seltsam an (Nullterminierung). Damit fünktionieren dann viele Programme nicht mehr so, wie vorher. Ist das das, was Du dir unter »richtig unterstützt« vorstellst?

Wie findet ihr die Problematik mit UTF-16?

Ich habe mich damit (noch) nicht befasst, was genau ist das Problem? Die spezifizierte Bytereihenfolge?

Mr. N

> Das Gleiche wie ASCII, nur größer. Hört sich irgendwie nach Lernresistenz an, scheint aber vorerst mal einige Problemfälle zu erschlagen.
  Jo.

>> Von der C++-Standard-Library wird UCS-2 (ich glaub aber auch UTF-32 theoretisch) richtig unterstützt, und UTF-8 ... nunja.

> Wie meinen? Quelltexttechnisch? UCS-2 führt dazu, dass Du 8-Bit-cleane Dateien vor jedes Byte ein Nullbyte reinstopfst. 
  Ne. Nich quelltext-technisch. Library-technisch, mann.
> Damit fühlt sich mit 'char' (das ja per Definition ein Byte ist) ziemlich seltsam an (Nullterminierung). 
Damit fünktionieren dann viele Programme nicht mehr so, wie vorher. 
  Ich meine ja auch std::wchar_t!
> Ist das das, was Du dir unter »richtig unterstützt« vorstellst?
  Ähm... naja, kommt davon, wenn man sich zu undeutlich ausdrückt :rolling_eyes:

>> Wie findet ihr die Problematik mit UTF-16?

> Ich habe mich damit (noch) nicht befasst, was genau ist das Problem? Die spezifizierte Bytereihenfolge? 

  Nein. Das Problem, dass die momentanen ca. 100000 Zeichen nicht in UTF-16 passen und die Situation mit UTF-16 daher die selbe ist wie mit UTF-8. 
Lediglich in UTF-32 gilt, dass ein Buchstabe immer gleich groß ist. 
  www.unicode.org    ist da eine recht umfangreiche Informations-quelle

[ Dieser Beitrag wurde am 04.05.2003 um 14:19 Uhr von Mr. N editiert. ]

Daniel E.

Original erstellt von Mr. N:
Das Problem, dass die momentanen ca. 100000 Zeichen nicht in UTF-16 passen und die Situation mit UTF-16 daher die selbe ist wie mit UTF-8.

Ägypten? Sowohl mit UTF-8 als auch mit UTF-16 kann das UCS darstellen. Die Verfahren kannst Du nachlesen (RFC 2279 und RFC 2781).

Was ist also das Problem? Dass die Repräsentation (1 oder 2 mal 16 Bit für UTF-16) von dem Wert abhängt? Auf Quelltextebene hast Du eben nur deinen unicode_t, der bei der Ein-/Ausgabe umgeformt wird.

Mr. N

Original erstellt von Daniel E.:
Was ist also das Problem?

Das Problem ist, dass Funktionen wie strlen nicht mehr trivial sind.

Blue-Tiger

*dummFrag*

ich dachte immer Unicode == Unicode, wo ist der Unterschied zwischen den ganzen Dingern?

Mr. N

Original erstellt von Blue-Tiger:
ich dachte immer Unicode == Unicode, wo ist der Unterschied zwischen den ganzen Dingern?

unicode sind nur die zeichen. ihre genaue numerische darstellung ist streng genommen nicht unicode, aber unicode definiert verschiedene darstellungen, darunter die modernen: utf-8, utf-16, utf-32

Shade Of Mine

Original erstellt von Mr. N:
Das Problem ist, dass Funktionen wie strlen nicht mehr trivial sind.

char_traits<WhatEver>::length(str);

???

Marc++us

Original erstellt von Mr. N:
Das Problem ist, dass Funktionen wie strlen nicht mehr trivial sind.

wcslen(str)

Immer noch trivial.

Hauptproblem ist, daß wir alle gelernt haben strlen oder strcpy bereits mit der C-Milch einzuschlürfen, weil eben niemand ab Beginn sagt nimm lieber wsclen und wcscpy, und verzichte grundsätzlich auf char.

Ein relativ simples Unicode-Programm wird daher für den normalen Entwickler durch die völlig unbekannten Funktionsnamen und die neuen Typen leichter unlesbar. Ist aber Gewöhnungssache.

#include <string.h>
#include <stdio.h>

int main()
{
   wchar_t string[80];
   wcscpy( string, L"Hello world from " );
   wcscat( string, L"strcpy " );
   wcscat( string, L"and " );
   wcscat( string, L"strcat!" );
   wprintf( L"String = %s\n", string );

   return 0;
}

@Marc++us: Wozu is denn das 'L' vor den String-Konstanten?

Daniel E.

damit man keine Stringliterale vom Typ char vondern wchar_t hat.

Original erstellt von Mr. N:
Das Problem ist, dass Funktionen wie strlen nicht mehr trivial sind.

Das Programm arbeitet idR weiterhin mit Zahlen, die bijektiv auf Zeichen abgebildet sind. Die Codierung, zB UTF-8, kommt erst dann ins Spiel, wenn das Programm mit seiner Umwelt interagiert (Ein- und Ausgabe).

Mr. N

Original erstellt von Marc++us:
wcslen(str)
Immer noch trivial.

Aber das ist eben nicht UTF-8. In meinem aktuellen Projekt (das leider nur schleppend vorankommt, aber immerhin), verwende ich ja komplett wchar_t. Unnötigerweise ;).