Hab ich das mit UTF 8 und Unicode richtig verstanden?
-
Hi
ich kenn das momentan nur von unserem Projekt her. Ist leider Java läst sich aber sicher was ableiten. In java sind ja alle Strings von haus aus Unicode. Beim einlesen von Dateien, die UTF-8 / UTF-16 codiert sind, musten wir einen passenden converter verwenden, der uns die dateien sauber eingelesen hat. sonst waren da plötzlich mehr zeichen in den texten als wir eigentlich wollten. meistens bei den zeichen, die in west/mitteleuropa nicht vorkommen.auch aufpassen bei der Datenbank. die sollte ihre strings auch in unicode ablegen. sonst können ggf zeichen durch ? oder andere platzhalter ersetzt werden.
gruss
-
Was für einen Converter habt ihr benutzen müssen? Man kann doch einen Textstream benutzen und das Encoding dafür angeben?
-
Was du bei UTF-8 beachten musst, dass es sich um einen multiplebyte Zeichensatz handelt. Also entsprichen die Zeichen nicht immer der gleichen Anzahl an Bytes. Also sind Funktionen, die sich darauf verlassen nicht mehr zu gebrauchen.
Hi,
das hört sich logisch an. Dann hoffe ich dass der Rest was ich geschrieben habe auch soweit korrekt ist, weil dazu nicht geäußert wurde. Bei den String Funktionen werde ich aufpassen und mir Testwerte ausgeben lassen. Das sollte kein Problem werden.
Philipp
-
Da die Dateien, die ich habe alle UTF-8 kodiert sind, brauche ich gar kein Unicode und kann ganz normal wie mit anderen Dateien damit Arbeiten.
Ich weiß nicht so ganz, wie ich diesen Satz verstehen soll, daher kann ich dir das nicht bestätigen.
-
Da die Dateien, die ich habe alle UTF-8 kodiert sind, brauche ich gar kein Unicode und kann ganz normal wie mit anderen Dateien damit Arbeiten.
Ich erhalte eine große Menge von XML Dateien, die alle UTF-8 kodiert sind. In diesen XML Dateien können teils auch fremdsprachige Textausschnitte wie z.B. russisch entalten sei.
Meine Anwendung soll die Daten, die ich aus dem XML gewinne managen. DIese werden dann in einer MySQL Datenbank gesichert. Zuerst hatte ich für meinen C++ Builder Unicode Komponenten installiert, damit ich die XML Daten richtig einlesen kann. Da ich jedoch mit gewöhnlichen Strings UTF-8 Daten einlesen kann, brauche ich jetzt diese Komponenten ja nicht mehr.D.h. ich kann mit normalen Strings die Daten einlesen, zusammenschneiden und dann in einer Datenbank ablegen. Unicode wird kein bissle benötigt, da die Daten ja alle UTF-8 kodiert vorliegen. Die Unicode Komponenten wüde ich meiner Meinung nach NUR benötigen, wenn ich die Texte korrekt in ihrer Sprache darstellen wolle, was jedoch uninteressant ist
Ich hoffe ich konnte mich nun etwas deutlicher Ausdrücken.
Beste Grüße
Philipp
-
UTF-8 ist Unicode.
-
Was er (imho) meint ist, dass wenn seine Anwendung nur Dateien einliest und den darin enthaltenen UTF-8/Unicode-Text nur in eine ebenfalls UTF-8/Unicode-Datenbank schreiben soll, dann muss seine Anwendung keine Unicode-"Intelligenz" haben, sondern kann auf stinknormalen Byte-Strings arbeiten, d.h. die Kodierung ist für die Anwendung vollkommen transparent.
-
-
MBCS-CITP schrieb:
kingruedi schrieb:
UTF-8 ist Unicode.
Sicher?
Sicher dass du das RFC gelesen hast?
http://www.ietf.org/rfc/rfc3629.txt schrieb:
The same set of characters is defined by the Unicode standard [UNICODE] (...)
ISO/IEC 10646 and Unicode define several encoding forms of their common repertoire: UTF-8, UCS-2, UTF-16, UCS-4 and UTF-32 (...)
UTF-8 is defined by the Unicode Standard [UNICODE].Heißt soviel wie: sollte klar sein, was kingruedi meint. UTF-8 verwendet Unicode bzw andersrum UTF-8 ist eine konkrete Umsetzung von Unicode.
-
Genau dass wollte ich wissen. Dann kann ich meine Anwendung nun ja in ruhe weiter bauen.
Besten Dank euch allen
Philipp
-
UTF-8 ist ein Algorithmus, der das Mapping vom UNICODE beschreibt. Deshalb ist UTF-8 auch keine Encoding-Table, sondern kann nur wie eine benutzt werden.
Der grosse Vorteil UFT-8 ist, dass er im Bereich des US-ASCII (00-7F) mit diesem deckungsgleich ist - und damit auch mit diesen niedrigen Bereich der ISO 8859-X Gruppe.
-
Optimizer schrieb:
Was für einen Converter habt ihr benutzen müssen? Man kann doch einen Textstream benutzen und das Encoding dafür angeben?
Ja das hab ich gemeint. Ich hab die Datei als byte stream aufgemachen, dann das entsprechende encoding angegeben und hab dann den string bekommen. Einfach nen Stringstream aufmachen war da leider nicht ( hab da noch dummerweise ne unterscheidung zwischen utf8 und 16 einbauen müssen ) ist jetzt auch etwas her. Ich wollt eigentlich nur sagen, das man beim einlesen von textdateien ggf drauf aufpassen muss das man das encoding mit angibt. da man sonst so schöne hässliche fehler hat die man denn erst festellt, wenn so h hässliche Zeichen mit irgendwelchen Hacken und Schnörkeln auftauchen.
gruss Termite
-
scrontch schrieb:
Was er (imho) meint ist, dass wenn seine Anwendung nur Dateien einliest und den darin enthaltenen UTF-8/Unicode-Text nur in eine ebenfalls UTF-8/Unicode-Datenbank schreiben soll, dann muss seine Anwendung keine Unicode-"Intelligenz" haben, sondern kann auf stinknormalen Byte-Strings arbeiten, d.h. die Kodierung ist für die Anwendung vollkommen transparent.
Gut, wenn er es so meint, dann sehe ich irgendwie nicht den Zusammenhang.
@Fragesteller: Ich kann auch UTF-16 kodierten Text als Bytefolge auffassen, aber was bringt mir das? Ich habe damit keine Logik gegeben, wie ich ein Zeichen auslesen kann. Ich kann auch ein Bitmap als Bytefolge auffassen und damit einen String benutzen, das gibt genauso einen Unsinn. Falls du das gemeint hast: nein! Du kannst selbstverständlich nicht einfach mit einem ANSI-String-Typ wie z.B. std::string hantieren, außer du machst nichts anderes, als den Text umzukopieren. Das kannst dann auch mit einem Bitmap und std::string machen. Sobald du irgendwelche sinnvollen Operationen vorhast, die über "ein char* an eine Bibliotheksfunktion übergeben" hinausgehen z.B. das Abschneiden des Strings nach dem n-ten Zeichen, hast du schon verloren.
MBCS-CITP schrieb:
UTF-8 ist ein Algorithmus, der das Mapping vom UNICODE beschreibt. Deshalb ist UTF-8 auch keine Encoding-Table, sondern kann nur wie eine benutzt werden.
Der grosse Vorteil UFT-8 ist, dass er im Bereich des US-ASCII (00-7F) mit diesem deckungsgleich ist - und damit auch mit diesen niedrigen Bereich der ISO 8859-X Gruppe.
Also wenn du schon so erbsenzählerisch bist, dann möchte ich gleich auch noch anmerken, dass die Formulierung "UTF-8 kann wie eine Encoding-Table benutzt werden" bei mir auf Unverständnis stößt. Eine Zeichentabelle mapped Zahlenwerte auf Zeichen, UTF-8 mapped Zahlenwerte auf Bytefolgen, macht also etwas anderes.
Termite schrieb:
Ja das hab ich gemeint. Ich hab die Datei als byte stream aufgemachen, dann das entsprechende encoding angegeben und hab dann den string bekommen.
Ist doch schön, wenn man sowas built-in hat.
-
Optimizer schrieb:
@Fragesteller: Ich kann auch UTF-16 kodierten Text als Bytefolge auffassen, aber was bringt mir das?
UTF-16-Strings enden aber nicht genau da, wo das erste Nullbyte ist. Das heisst, solange man keine Ein-/Ausgabe macht (dass man dafür eigene Funktionen braucht, war schon auf Seite 1 geklärt), kann man die str*-Funktionen weiterverwenden.
-
Strings müssen überhaupt gar nicht auf 0 enden. Das ist jetzt wieder eine andere Frage. Wenn ich eine Bibliotheksfunktion habe, die einen UTF-16 kodierten Text als char* (also als Bytefolge) erwartet, dann wird sie kaum das Ende annehmen, wenn auf einem ungeraden offset eine 0 steht. Viel mehr als den char* an eine Bibliotheksfunktion übergeben kannst du mit std::string oder std::wstring sowieso nicht machen, das ist das Problem.
