UCS-2, UTF-8, UTF-16, UTF-32, WTF?

firefly

@DocShoe sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

Das sind keine Textdateien, sondern Binärdateien, die unter anderem auch Text enthalten. Du bist vermutlich noch bei deiner Textverarbeitung

Naja bis jetzt wurde von dir auch nie gesagt dass es sich um binär daten handelt, welche auch texte enthalten können.

hustbaer

@DocShoe sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

Das sind keine Textdateien, sondern Binärdateien, die unter anderem auch Text enthalten.

OK

Du bist vermutlich noch bei deiner Textverarbeitung.

Nönö. Dass du keine Textverarbeitung machst hatte ich schon verstanden. Nur dass heute die meisten Configfiles und auch sehr viele Datenfile Formate textbasiert sind. Und natürlich das was @firefly angedeutet hat: du hattest ja geschrieben dass da Texte drin stehen, und da hab ich dann automatisch Textfile gedacht. Heisst nicht dass du was falsch gemacht hast, nur zur Erklärung wieso ich Textfile angenommen hatte.

Der Dateiheader hat eine ASCII Signatur und unter anderem 4 uint für Major, Minor, Release und Build Version. Den Header kann ich also immer richtig lesen und anhand der Versionsnummer weiter entscheiden, wie Text behandelt wird (ANSI/UTF-8). Seh da kein Problem.

Ich auch nicht

*john 0

@DocShoe sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

@john-0
Ne, wchar_t hilft da nicht weiter, weil man bei UTF-16 ähnliche Probleme wie bei UTF-8 hat, nämlich dass ein sich Zeichen aus bis zu zwei wchar_t zusammensetzen darf. Bis Windows2000 hat Microsoft UCS-2 benutzt, dabei wurde jedes Zeichen mit genau 2 Byte kodiert.

Ich sehe gerade, dass UNIX/Linux und Windows wchar_t verschieden definieren . Nun denn, die Welt könnte so einfach sein, warum machen wir sie nicht komplizierter. Also, UNIX/Linux definiert wchar_t als UTF-32 (UCS-4 wurde als Name wohl beerdigt) sizeof(wchar_t)==4 und somit hat man damit immer feste Längen bei std::wstring. Ursprünglich hieß das ganze UCS-4 wurde dann aber mit UTF-16 kompatiblen gemacht und somit entstand dann UTF-32.

firefly

@john-0 sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

somit hat man damit immer feste Längen bei std::wstring

Mit der aussage wäre ich vorsichtig Aktuell mag 32Bit für alle aktuellen Unicode Zeichen reichen.
Da aber immer mehr Zeichen dem Unicode Standard hinzugefügt werden, wird irgendwann 32Bit nicht mehr reichen um alle Zeichen kodieren zu können.

*john 0

@firefly sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

Mit der aussage wäre ich vorsichtig Aktuell mag 32Bit für alle aktuellen Unicode Zeichen reichen.

Es sind ja keine 32Bit sondern deutlich weniger, aktuell wird nur bis 0x0010FFFF kodiert. Die ursprüngliche Version erlaubte noch Codes bis 0x7FFFFFFF. Das kann man gut in der RFC-2279 und RFC-3629 nachlesen.

hustbaer

@firefly sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

@john-0 sagte in UCS-2, UTF-8, UTF-16, UTF-32, WTF?:

somit hat man damit immer feste Längen bei std::wstring

Mit der aussage wäre ich vorsichtig Aktuell mag 32Bit für alle aktuellen Unicode Zeichen reichen.
Da aber immer mehr Zeichen dem Unicode Standard hinzugefügt werden, wird irgendwann 32Bit nicht mehr reichen um alle Zeichen kodieren zu können.

Der Unicode Codespace ist als 0 ... 0x10FFFF definiert. UTF-16 kann auch gar nicht mehr darstellen. UTF-8 streng genommen auch nicht, da Bytesequenzen die Codepoints > 0x10FFFF ergeben würden als ungültig definiert sind.

Trotz dem wir schon tonnenweise Müll (z.B. Emojis) reindefiniert haben und ein paar richtig dicke Dinger wie Han oder Hangul dabei sind, sind nichtmal 30% des Codespace verwendet.

Den Codespace zu erweitern wäre auch ein "breaking change". Man könnte auch sagen dass sich daran nie etwas ändern kann, weil das was man dann hätte nicht mehr Unicode wäre. Weiters könnten wir dann viele der existierenden Programme mit Unicode Support in the Tonne treten.

Also ich würde mir da keine grossen Sorgen machen.