Sonderzeichen und latin1

[Friedhelm]

Moin,

welche Probleme könnten auftreten, wenn ich in meiner latin1 swedish codierten mysql-datenbank Einträge mit Sonderzeichen wie ¼,½,¾, ¿, À, Á, Â, Ã, Ä, Å, Æ, Ç, È, É, Ê, Ë, Ì, Í, Î, Ï, Ð, Ñ habe?

Oder ist es ganz und gar egal, auch solche Einträge zu haben?

Gruß, Fred

[suit]

welche Probleme könnten auftreten, wenn ich in meiner latin1 swedish codierten mysql-datenbank [...]

latin1_swedish_ci ist erstmal eine Sortierreihenfolge und hat mit der tatsächlichen Codierung der Daten oder der Verbindungscodierung nichts viel zu tun - gehen wir aber mal davon aus, dass auch an anderen Stellen Latin-1 Verwendet wird.

[...] Einträge mit Sonderzeichen wie ¼,½,¾, ¿, À, Á, Â, Ã, Ä, Å, Æ, Ç, È, É, Ê, Ë, Ì, Í, Î, Ï, Ð, Ñ habe?

Welche Probleme sollte es damit geben? Das sind hundsgewöhnliche Latin-1-Zeichen - und keineswegs "Sonderzeichen".

Oder ist es ganz und gar egal, auch solche Einträge zu haben?

Kein Problem - Gedanken würde ich mir eher um А Б В Г Д Е Ж З И Й К Л М oder Н machen - oder Millionen anderer Unicode-Zeichen, die sich mit einer 8-Bit-Single-Byte-Codierung nicht abbilden lassen.

Was spricht gegen UTF-8? Warum willst du Latin-1 Verwenden?

[Friedhelm]

Hi suit,

Welche Probleme sollte es damit geben? Das sind hundsgewöhnliche Latin-1-Zeichen - und keineswegs "Sonderzeichen".

Woran erkennst Du das?

Gedanken würde ich mir eher um А Б В Г Д Е Ж З И Й К Л М oder Н machen - oder Millionen anderer Unicode-Zeichen, die sich mit einer 8-Bit-Single-Byte-Codierung nicht abbilden lassen.

Und woran erkennst Du das?

Gibt es eine Tabelle, in der ich sowas nachsehen kann?

Was spricht gegen UTF-8? Warum willst du Latin-1 Verwenden?

Nein, im Gegentum. Es spricht nichts dagegen, aber solange ich da  nicht 100% weiß, was und wie ich es tun muss, will ich nicht wechseln.

Gruß, Fred

[suit]

Welche Probleme sollte es damit geben? Das sind hundsgewöhnliche Latin-1-Zeichen - und keineswegs "Sonderzeichen".

Woran erkennst Du das?

Weil ich weiß, welche Zeichen in Latin-1 enthalten sind :)

Aber du kannst auch gerne <http://de.selfhtml.org/inter/zeichenkodierungen.htm#iso8859_liste@title=selbst vergleichen>.

Gedanken würde ich mir eher um А Б В Г Д Е Ж З И Й К Л М oder Н machen - oder Millionen anderer Unicode-Zeichen, die sich mit einer 8-Bit-Single-Byte-Codierung nicht abbilden lassen.

Und woran erkennst Du das?

Weil ich weiß, dass kyrillische Buchstaben in Latin-1 nicht enthalten sind.

Gibt es eine Tabelle, in der ich sowas nachsehen kann?

Siehe oben - in der Suchmaschine deiner Wahl findest du bei der Suche nach "Latin-1 Tabelle" tonnenweise entsprechende Tabellen.

Was spricht gegen UTF-8? Warum willst du Latin-1 Verwenden?

Nein, im Gegentum. Es spricht nichts dagegen, aber solange ich da  nicht 100% weiß, was und wie ich es tun muss, will ich nicht wechseln.

Dann ist es vielleicht schlauer, dich über das Umstellen kundig zu machen und nicht darauf, welche der jämmerlich wenigen Zeichen du im Klartext verwenden kannst :)

[Friedhelm]

Gedanken würde ich mir eher um А Б В Г Д Е Ж З И Й К Л М oder Н machen - oder Millionen anderer Unicode-Zeichen, die sich mit einer 8-Bit-Single-Byte-Codierung nicht abbilden lassen.

Was würde denn passieren, falls solch ein Zeichen auch darin wäre?

Würde dann mehr passieren, als das irgendein Ersatzzeichen genommen würde oder eine Buchstabenlücke entstände?

Gruß, Fred

[suit]

Was würde denn passieren, falls solch ein Zeichen auch darin wäre?

Es wird zerstört und höchstwahrscheinlich kommt dann ein "Kästchen" oder "Fragezeichen" raus :)

Würde dann mehr passieren, als das irgendein Ersatzzeichen genommen würde oder eine Buchstabenlücke entstände?

Was wäre denn das Ersatzeichen für 山?

[Friedhelm]

Was wäre denn das Ersatzeichen für 山?

Auch ein Kästchen?
Oder ein ?

Meine Frage geht ja dahin, ob meine db dann mehr als einen Zeichenfehler beinhalten könnte? Also etwas "Schlimmeres"?

Gruß, Fred

[suit]

Was wäre denn das Ersatzeichen für 山?

Auch ein Kästchen?
Oder ein ?

Ja :)

Meine Frage geht ja dahin, ob meine db dann mehr als einen Zeichenfehler beinhalten könnte? Also etwas "Schlimmeres"?

Der Datenbank ist das egal - aber wenn du eine Unternehmenseite mit mehreren hundert Produktseiten hast und du sämtliche Produktunterseiten nicht ordentlich Übersetzen kannst, weil du keine "exotischen" Zeichen eingeben kannst, ist das "schlimm", wenn du einen solchen Markt bedienen willst.

Mitunter fällt es dir auch garnicht auf, du hast einen Fließtext und da ist irgendwo ein einzelnes Zeichen drin, welches in ISO 8859-1 nicht darstellbar ist - Copy&Paste und gut. Auffallen tut dir das aber erst 8 Monate später und dir fällt auch auf, dass das in 791 Datenblättern auf der Website so ist. Der Kunde ist nicht begeisterst und schickt dir einen wütenden Mob mit Mistgabeln und Fackeln vorbei.

Kommt also drauf an, was deine Defintion von Schlimm ist.

[Cheatah]

Hi,

Meine Frage geht ja dahin, ob meine db dann mehr als einen Zeichenfehler beinhalten könnte? Also etwas "Schlimmeres"?

Zeichen sind in erster Linie einmal Bytes. Wenn Du eine Folge von Bytes in der Datenbank stehen hast, werden diese von irgendwas interpretiert und (als Zeichen) dargestellt. Geht dieses ominöse Irgendwas nun davon aus, dass ein Zeichen mehr als ein Byte lang sein kann - wie es beispielsweise bei UTF-8 der Fall ist - dann kann es sein, dass ein als Latin-1 oder ISO gespeichertes (1 Byte "langes") Zeichen mit dem oder den Folgezeichen sozusagen fusioniert. Aus "Frühstück" wird dann sowas wie "FrДtД"[1].

Dem IE passiert sowas gelegentlich; schlimmstenfalls wird bei z.B. "/* extra groß */" das Kommentarende mit verschluckt und der nachfolgende Code nicht ausgeführt.

Verwende bei allem was Du tust, immer und überall, ausschließlich UTF. Dies wird alle Schrift- und Sonderzeichen abbilden können, selbst wenn die Außerirdischen sich bei uns vorstellen und die Schriften aller 42.000 Welten der Galaxie bei uns etablieren. Mit ISO-Kodierungen wie Latin-1 bist Du immer auf 256 Zeichen *einschließlich* Steuerzeichen (Zeilenumbrüche usw.) beschränkt. Kurz gesagt, mit ISO kann man nicht mal

✝ RIP ISO

verkünden.

Cheatah

[1] Kein reales Beispiel, nur symbolisch gemeint.

[Friedhelm]

Verwende bei allem was Du tust, immer und überall, ausschließlich UTF.

Ok. ich bin gerade dabei alles in UTF-8 zu ändern.

Bitte schaut mal, ob ich bei meiner Vorgehensweise etwas vergessen werde:

1. DB mit phpmyAdmin exportieren
2. Sortierreihenfolge im Dump auf utf-8_general_ci ändern
3. Default charset im Dump auf utf-8 ändern
4. DB löschen
5. Generelle Sortierreihenfolge über phpmyAdmin auf utf-8_general_ci einstellen
6. Dump einspielen
7. header('Content-Type: text/html; charset=utf-8');
8. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
9. Alle DB-Verbindungen mit SET NAMES 'utf8' versehen
10. Alle php-Dateien, die Ausgabetext beinhalten in utf-8 neu speichern

Frage 1: Hab ich was vergessen?
Frage 2: Gibt es zu Punkt 10 ein Programm, dass das in einem batch kann???

Gruß, Fred

[dedlfix]

Hi!

1. DB mit phpmyAdmin exportieren
2. Sortierreihenfolge im Dump auf utf-8_general_ci ändern
3. Default charset im Dump auf utf-8 ändern
4. DB löschen
5. Generelle Sortierreihenfolge über phpmyAdmin auf utf-8_general_ci einstellen
6. Dump einspielen

Wenn der PMA bereits alles richtig anzeigt, kannst du einfach die betreffenden (String-)Felder umstellen (Kollation ändern. Es gibt auch eine ALTER-TABLE-Syntax, die alle Felder in einem Rutsch ändert). MySQL nimmt dabei eine Umkodierung vor. (Datenbank- bzw. Tabelleneinstellungen sind nur Default-Werte für neu anzulegende Tabellen bzw. Felder. Eine Änderung beeindruckt bestehende Felder nicht.)

Wenn der PMA Fehler anzeigt, dann passt die tatsächliche Kodierung nicht zur Feldeinstellung. Eine Reparatur ist abhängig von der Art des Fehlers und in manchen Fällen auch nicht möglich.

5. Generelle Sortierreihenfolge über phpmyAdmin auf utf-8_general_ci einstellen

Das kannst du über den PMA nicht ändern, das geht nur in der Serverkonfigurationsdatei selbst. Wenn du damit jedoch die Einstellung auf PMAs Startseite meinst, dann ist das nur ein Wert für den PMA selbst und betrifft seine Verbindungen zum DBMS, aber keinerlei Daten dort und auch keine Verbindungen zwischen anderen Clients und MySQL.

7. header('Content-Type: text/html; charset=utf-8');
8. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Passt.

9. Alle DB-Verbindungen mit SET NAMES 'utf8' versehen

Abgesehen davon, dass man bei SET NAMES die Anführungszeichen um das utf8 weglassen kann - hast du kein aktuelles PHP, bei dem mysql_set_charset() zur Verfügung steht? Alternativ kannst du auch die mysqli-Extension (und mysqli_set_charset() / mysqli::set_charset()) verwenden, wenn vorhanden.

10. Alle php-Dateien, die Ausgabetext beinhalten in utf-8 neu speichern
    Frage 2: Gibt es zu Punkt 10 ein Programm, dass das in einem batch kann???

iconv unter Linux/Cygwin.

Lo!

[Friedhelm]

Hi,

Abgesehen davon, dass man bei SET NAMES die Anführungszeichen um das utf8 weglassen kann - hast du kein aktuelles PHP, bei dem mysql_set_charset() zur Verfügung steht?

Doch, klar. Ich verwende 5.2.x

Ist denn mysql_set_charset() besser?

Gruß, Fred

[dedlfix]

Hi!

Abgesehen davon, dass man bei SET NAMES die Anführungszeichen um das utf8 weglassen kann - hast du kein aktuelles PHP, bei dem mysql_set_charset() zur Verfügung steht?
Doch, klar. Ich verwende 5.2.x
Ist denn mysql_set_charset() besser?

Ja, aber für die hierzulande verwendeten Kodierungen ist es eigentlich egal. Der Unterschied ist, dass SET NAMES nur auf dem Server ausgeführt wird, mysql_set_charset() aber in der in PHP eingebundenen MySQL-Client-API. Funktionen, die von der verwendeten Zeichenkodierung abhängig sind, wie beispielsweise Escape-Funktionen, bekommen nur über den Client-API-Aufruf mitgeteilt, welche Kodierung für diese Verbindung eingestellt wurde. Für die Kodierungen der ISO-8859-Familie und UTF-8 sind die Byte-Werte der zu maskierenden Zeichen sowohl eindeutig als auch die selben, so dass die Maskierung immer korrekt erfolgen kann. Aber es gibt Kodierungen aus dem asiatischen Raum, bei denen die Bytes in mehreren Zeichen vorkommen. Das führt zu falschen Maskierungen und unter Umständen zu SQL-Injection. Aber wie gesagt, für ISO-8859-x und UTF-8 kein Problem.

Lo!

[suit]

Verwende bei allem was Du tust, immer und überall, ausschließlich UTF.

UTF-8 :)

Und dieser Satz gilt zumindest so lange, bis man verstanden hat, in begründeten Fällen auch eine andere Codierung zu verwenden.

Aber am wenigsten falsch machen kann man mit UTF-8.

[dedlfix]

Hi!

Gedanken würde ich mir eher um А Б В Г Д Е Ж З И Й К Л М oder Н machen - oder Millionen anderer Unicode-Zeichen, die sich mit einer 8-Bit-Single-Byte-Codierung nicht abbilden lassen.
Was würde denn passieren, falls solch ein Zeichen auch darin wäre?

Diese Frage lässt auf ein grundlegendes Lernpotential schließen. In einem Zeichensatz sind begrenzt viele Zeichen enthalten. Desweiteren gibt es Kodierungen, die diese Zeichen in nutzbare Form bringen, was Bits und Bytes auf Computern sind. Alle mit der gewählten Kodierung nicht kodierbaren Zeichen lassen sich nicht darstellen - es sei denn, es gibt Ersatzschreibweisen, wie bei HTML. Doch diese machen mehr Arbeit, weil sie stets extra berücksichtigt werden müssen und nicht jedes System darauf eingestellt ist. Deswegen ist es besser, einen Zeichensatz und eine entsprechende -kodierung zu verwenden, die möglichst alles enthält und darstellen kann.

Würde dann mehr passieren, als das irgendein Ersatzzeichen genommen würde oder eine Buchstabenlücke entstände?

Ersatzzeichen (nicht zu verwechseln mit Ersatzdarstellungen wie NCRs/Entitys in HTML) sind generell jeweils nur ein einziges Zeichen, zum Beispiel das Fragezeichen. Aus diesem kann man das ursprüngliche Zeichen nicht wiederherstellen - es ist also verloren.

Lo!

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Diese Frage lässt auf ein grundlegendes Lernpotential schließen.

S.a. Zeichencodierung für Anfänger und Zeichencodierungen: grundlegende Konzepte

In einem Zeichensatz sind begrenzt viele Zeichen enthalten.

Unicode kennt keine Grenzen. ;-)

Doch diese [Ersatzschreibweisen] machen mehr Arbeit, weil sie stets extra berücksichtigt werden müssen und nicht jedes System darauf eingestellt ist. Deswegen ist es besser, einen Zeichensatz und eine entsprechende -kodierung zu verwenden, die möglichst alles enthält und darstellen kann.

Sag ich doch.

Qapla'

[suit]

In einem Zeichensatz sind begrenzt viele Zeichen enthalten.

Unicode kennt keine Grenzen. ;-)

Ach schon - aber machen uns in der nächsten Zeit hoffentlich wenige Probleme.

Auch 64-Bit time_t hat eine Grenze, aber die macht uns erst in ~ 290 Milliarden Jahre Probleme.

[Cheatah]

Hi,

Auch 64-Bit time_t hat eine Grenze, aber die macht uns erst in ~ 290 Milliarden Jahre Probleme.

ich kenne Leute, die jetzt schon darauf warten, im betreffenden Moment ihren Krückstock zu schwingen und "Ich hab's doch gesagt!" sagen zu können.

Cheatah

[dedlfix]

Hi!

In einem Zeichensatz sind begrenzt viele Zeichen enthalten.
Unicode kennt keine Grenzen. ;-)

Theoretisch. Praktisch ist mit der jeweiligen Version die Anzahl der vorhandenen Zeichen begrenzt.

Aber zum Verständnis für Anfänger: Die meisten anderen (oder gar alle?) nicht auf Unicode basierenden Zeichensätze und -kodierungen sind mehr oder weniger auf bestimmte lokale/schriftkulturelle Gegebenheiten begrenzt. Meist haben sie nur noch den ASCII-Vorrat zusätzlich enthalten (so das Schriftsystem, für das sie entworfen wurden, nicht auf lateinische Buchstaben aufbaut). Und das große Problem an ihnen ist, dass sie nicht erweiterbar sind. Bei 256 Zeichen ist für die Latin-/ISO-8859-Familie Schluss. Das zeigte sich beispielsweise beim Euro-Zeichen, das man nicht einfach so in Latin1/ISO-8859-1 hinzufügen konnte/kann. Der Ausweg ist Unicode, wofür es ja jetzt ausreichend Literaturempfehlung gab.

Lo!

[suit]

Der Ausweg ist Unicode, wofür es ja jetzt ausreichend Literaturempfehlung gab.

UTF-8 - Unicode allein ist noch kein Heilbringer :)

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Das zeigte sich beispielsweise beim Euro-Zeichen, das man nicht einfach so in Latin1/ISO-8859-1 hinzufügen konnte/kann.

Nicht ohne Reise nach Jerusalem. ¤ hat keinen Stuhl mehr abgekriegt, dafür macht sich € breit. Sieben Runden später: fertig ist ISO 8859-15.

Erinnert mich an: Wie kriegt man eine Kuh in’n Kühlschrank? Und wie kriegt man ein Pferd in’n Kühlschrank?

Qapla'

[suit]

Erinnert mich an: Wie kriegt man eine Kuh in’n Kühlschrank? Und wie kriegt man ein Pferd in’n Kühlschrank?

War das nicht eine Elefant und eine Giraffe?

[Gunnar Bittersmann]

@@suit:

nuqneH

Erinnert mich an: Wie kriegt man eine Kuh in’n Kühlschrank? Und wie kriegt man ein Pferd in’n Kühlschrank?

War das nicht eine Elefant und eine Giraffe?

Der Elefant war der im Kirschbaum.

Qapla'

[suit]

Erinnert mich an: Wie kriegt man eine Kuh in’n Kühlschrank? Und wie kriegt man ein Pferd in’n Kühlschrank?

War das nicht eine Elefant und eine Giraffe?

Der Elefant war der im Kirschbaum.

Den kenn ich nicht.

Ich kenn nur die 4-Fragen-Liste um das Grundprinzip von Algorithmen zu verstehen.

Q: Wie bekommt man einen Elefanten in den Kühlschrank?
A: Kühlschrank auf, Elefant rein, Kühlschrank zu.

Q: Wie bekommt man eine Giraffe in den Kühlschrank?
A: Kühlschrank auf, Elefant raus, Giraffe rein, Kühlschrank zu.

Q: Alle Tiere, bis auf eines, sind auf der Konferenz der Tiere. Welches Tier ist also nicht dort?
A: Die Giraffe, die ist im Kühlschrank.

Q: Du musst einen Fluss überqueren, es gibt keine Brücke, kein Floß, kein Boot. Am Fluß steht ein Schild "Achtung, Krokodile" - was machst du?
A: Durchschwimmen/-waten - die Krokodile stellen kein Problem dar, die sind auf der Konferenz der Tiere.

[Gunnar Bittersmann]

@@suit:

nuqneH

Der Elefant war der im Kirschbaum.
Den kenn ich nicht.

Warum haben Elefanten rote Augen?

Damit sie sich besser im Kirschbaum verstecken können.

Schon mal einen Elefanten im Kirschbaum gesehen?

Na siehste mal, wie gut die sich verstecken können.

Qapla'

[suit]

Der Elefant war der im Kirschbaum.
Den kenn ich nicht.

Warum haben Elefanten rote Augen?

Damit sie sich besser im Kirschbaum verstecken können.

Schon mal einen Elefanten im Kirschbaum gesehen?

Na siehste mal, wie gut die sich verstecken können.

Ach der :) den hab' ich irgendwo schon mal gehört.

[Friedhelm]

Hi,

kurzer Exkurs:

Ich arbeite mit fpdf, das leider nciht mit utf-8 umgehen kann.

So muß ich für alle pdf-scripte jeden Sting mit utf8_decode behandeln, um Umlaute darstellen zu können.

Zeitaufwand ca. 10 Std.

Ist es soviel wert, die DB dann einheitlich auf utf-8 anstelle latin1 codiert zu haben?

Will irgendwer ein Plädoyer für utf-8 halten?

Gruß, Fred

[dedlfix]

Hi!

Ich arbeite mit fpdf, das leider nciht mit utf-8 umgehen kann.
So muß ich für alle pdf-scripte jeden Sting mit utf8_decode behandeln, um Umlaute darstellen zu können.

Gegebenenfalls sogar mit Verlust aller Nicht-ISO-8859-1-Zeichen.

Ist es soviel wert, die DB dann einheitlich auf utf-8 anstelle latin1 codiert zu haben?

Ist es so viel wert, fpdf anstatt einer UTF-8-tauglichen PDF-Bibliothek zu verwenden?

Will irgendwer ein Plädoyer für utf-8 halten?

Hamwa doch schon. Allerdings, wenn an fpdf kein Weg vorbeiführt, ist ein UTF-8-Einsatz nicht unbedingt sinnvoll, weil die zusätzlich möglichen Zeichen ja sowieso nicht von fpdf behandelt werden können (wenn es nicht eine Ersatzschreibweise kennt). Wenn aber fpdf generell abgelöst werden kann, ...

Lo!

[Friedhelm]

Hamwa doch schon. Allerdings, wenn an fpdf kein Weg vorbeiführt, ist ein UTF-8-Einsatz nicht unbedingt sinnvoll, weil die zusätzlich möglichen Zeichen ja sowieso nicht von fpdf behandelt werden können (wenn es nicht eine Ersatzschreibweise kennt). Wenn aber fpdf generell abgelöst werden kann, ...

Hi,

Klar kann fpdf abgelöst werden. Wären dann aber sicher um die 100 Std., die ich dafür bräuchte, alles über eine andere Klasse als fpdf wieder genauso zu erstellen, wie es jetzt schon ist.

Zudem ist es so, dass ich nicht alles, was das Programm kann, auch ausdrucken muß.

Frag mich halt trotzdem, wofür ich grad alles in utf-8 umwandle.

Gibt es eigentlich wichtige Nicht-ISO-8859-1-Zeichen, die ich verlieren könnte?

Gruß, Fred

[dedlfix]

Hi!

Gibt es eigentlich wichtige Nicht-ISO-8859-1-Zeichen, die ich verlieren könnte?

Das weiß ich nicht, da ich nicht weiß, welche Zeichen du verwendest. Du müsstest dazu mal eine Aufstellung deiner potentiellen Zeichen machen und diese gegen eine ISO-8859-1-Liste prüfen. Solch eine findest du unter anderen im der Wikipedia. Ein prominentes Beispiel wäre das €-Zeichen.

Lo!

[Friedhelm]

Das weiß ich nicht, da ich nicht weiß, welche Zeichen du verwendest. Du müsstest dazu mal eine Aufstellung deiner potentiellen Zeichen machen und diese gegen eine ISO-8859-1-Liste prüfen. Solch eine findest du unter anderen im der Wikipedia. Ein prominentes Beispiel wäre das €-Zeichen.

...das kann fpdf! :-)

Ich bräuchte noch z.b. das Durchmesser-Zeichen, ist das ISO-8859-1?

Aber mal im ernst: Was kann utf8_decode() weniger als es ein auf latin1 getrimmtes System kann?

Gruß, Fred

[Sven Rautenberg]

Moin!

...das kann fpdf! :-)

Ich bräuchte noch z.b. das Durchmesser-Zeichen, ist das ISO-8859-1?

Aber mal im ernst: Was kann utf8_decode() weniger als es ein auf latin1 getrimmtes System kann?

Hast du TCPDF getestet? Das ist mal von FPDF geforkt worden und kann UTF-8 - ich kann es absolut nur empfehlen.

Ich kann nicht versprechen, dass es als direkter Ersatz für FPDF benutzt werden kann, aber wenn, dann sind die Anpassungen mit vertretbarem Aufwand zu erledigen.

- Sven Rautenberg

[Friedhelm]

Hast du TCPDF getestet? Das ist mal von FPDF geforkt worden und kann UTF-8 - ich kann es absolut nur empfehlen.

Ich bin gestern mal kurz darauf gestoßen als ich merkte, dass fpdf Probleme mit utf-8 hat.

Ich kann nicht versprechen, dass es als direkter Ersatz für FPDF benutzt werden kann, aber wenn, dann sind die Anpassungen mit vertretbarem Aufwand zu erledigen.

Das ist sehr schwer von außen zu beurteilen. Das kommt vor allem auch darauf an, wieviele Dokumente man hat und welche Zusatzmodule man zu fpdf nutzt. Ich nutze z.b. oft und gerne mc_tables.

Aber Du hast recht, tcpdf macht schon einen guten Eindruck. Vor allem gefällt mir der HTML-Export, das schafft viele neue Optionen.

Ich werde nun mal 1 Script umarbeiten und danach bemessen, wieviel Arbeit es wirklich ist, auf tcpdf umzustellen.

Gruß, Fred

[Gunnar Bittersmann]

@@Friedhelm:

nuqneH

Gibt es eigentlich wichtige Nicht-ISO-8859-1-Zeichen, die ich verlieren könnte?

Anführungszeichen, Gedankenstriche, …

Es sei denn, dein System kann eigentlich windows-1252, nicht nur ISO 8859-1.

Qapla'

[Don P]

Hallo,

Würde dann mehr passieren, als das irgendein Ersatzzeichen genommen würde oder eine Buchstabenlücke entstände?

Ersatzzeichen (nicht zu verwechseln mit Ersatzdarstellungen wie NCRs/Entitys in HTML) sind generell jeweils nur ein einziges Zeichen, zum Beispiel das Fragezeichen. Aus diesem kann man das ursprüngliche Zeichen nicht wiederherstellen - es ist also verloren.

Ersatzzeichen? Verloren? Das verstehe ich nicht ganz.
Angenommen es wird Text in Latin-5 codiert und in der DB gespeichert. Dann wird der Text wieder ausgelesen aber das weiterverbeitende Programm meint, es handele sich um Latin-1, und stellt daher nur unverständliches Zeug dar. Dann ist doch dadurch nichts verloren, abgesehen von der Lesbarkeit für einen Menschen. Die Codes bleiben doch dieselben. Wenn einem also nachher wieder einfällt, dass es ja Latin-5 sein soll, dann kann den ganzen Text wieder korrekt darstellen, indem an dem darstellenden Programm eben mitteilt, dass es die Zeichen der Latin-5-Tabelle zeigen soll. Es gibt dann nicht wirklich "Ersatzzeichen", sondern nur verschiedene Darstellungen derselben Zeichencodes. Oder habe ich da jetzt etwas falsch verstanden?

Gruß, Don P

[dedlfix]

Hi!

Würde dann mehr passieren, als das irgendein Ersatzzeichen genommen würde oder eine Buchstabenlücke entstände?
Ersatzzeichen (nicht zu verwechseln mit Ersatzdarstellungen wie NCRs/Entitys in HTML) sind generell jeweils nur ein einziges Zeichen, zum Beispiel das Fragezeichen. Aus diesem kann man das ursprüngliche Zeichen nicht wiederherstellen - es ist also verloren.

Ersatzzeichen? Verloren? Das verstehe ich nicht ganz.

Es geht um Konvertierung von Zeichen von einer Kodierung in eine andere. Wenn ein Zeichen mit der Zielkodierung nicht darstellbar ist, geht es verloren, weil dafür höchstens ein Ersatzzeichen verwendet werden kann.

Angenommen es wird Text in Latin-5 codiert und in der DB gespeichert. Dann wird der Text wieder ausgelesen aber das weiterverbeitende Programm meint, es handele sich um Latin-1, und stellt daher nur unverständliches Zeug dar.

Das ist der Fall der Falschinterpretation. Auch hier kann es in der Ausgabe zu Ersatzzeichen kommen, beispielsweise, wenn ein ISO-8859-x-Text als UTF-8 interpretiert wird. Da aber die Quelle nicht geändert wird, kann sie beliebig oft anders interpretiert werden.

Wenn die Ausgabe mit enthaltenen Ersatzzeichen allerdings weiterverarbeitet wird, dann gibt es auch hier wieder Verlustpotential.

Lo!

[Gunnar Bittersmann]

@@Friedhelm:

nuqneH

Gibt es eine Tabelle, in der ich sowas nachsehen kann?

Ja, sogar in http://de.selfhtml.org/@title=SELFHTML. Click.

Zeichen für internationale Verwendung? – Könnte mit http://de.selfhtml.org/inter/index.htm@title=Internationalisierung zu tun haben. Click.

Was so einfach ist das zu finden? <http://de.selfhtml.org/inter/zeichenkodierungen.htm@title=Zeichenkodierungen (ISO-8859-Familie und andere)>. Click.

Wobei die Tabellen dort etwas unsinnig sind, weil die Zeichencodes dezimal statt hexadezimal angeordnet sind.

[UTF-8] Es spricht nichts dagegen, aber solange ich da  nicht 100% weiß, was und wie ich es tun muss, will ich nicht wechseln.

Es spricht alles dafür, dass du dir dieses Wissen aneignest. ASAP! Je eher du wechselst, desto einfacher wird es. Und du vermeidest alle Probleme, die du mit veralteten Zeichencodierungen hast.

Qapla'

[Friedhelm]

Es spricht alles dafür, dass du dir dieses Wissen aneignest. ASAP! Je eher du wechselst, desto einfacher wird es. Und du vermeidest alle Probleme, die du mit veralteten Zeichencodierungen hast.

Hi Gunnar,

Je eher, desto einfacher? Woran liegt das?

Gibt es irgendwo eine Anleitung, was alles zu tun ist beim Wechsel?

Muß ich meine php-dateien dann auch als utf-8 codiert abspeichern, sofern sie Ausgabetexte mit deutschen Umlauten enthalten?

Gruß, Fred

[suit]

Je eher, desto einfacher? Woran liegt das?

Hast du schon mal den Begriff "das ist mit der Zeit so gewachsen" gehört? Mit anderen Worten: man macht es, wider besseeren Wissens (oder aufgrund einer Management-Entscheidung), falsch und macht einfach so weiter - man baut auf dem Mist den man verbrochen auf und baut immer dazu. Irgendwann ist die Sache so groß, dass sich eine umstellung mit Sinnvollem Aufwand nicht mehr lohnt. Und wer ist dann Schuld? Richtig: der Programmierer, der der das gemacht hat - und selbstverständlich nicht sein Chef.

Gibt es irgendwo eine Anleitung, was alles zu tun ist beim Wechsel?

Muß ich meine php-dateien dann auch als utf-8 codiert abspeichern, sofern sie Ausgabetexte mit deutschen Umlauten enthalten?

Müssen tust du prinzipiell garnichts - aber es ist von großem Vorteil, wenn du _alles_ (PHP-Scripte, Datenbank, Tabellen, Tabellenfelder, Datenbankverbindung ...) in derselben Zeichencodierung (und das vorzugsweise UTF-8) verwendest.

[Gunnar Bittersmann]

@@Friedhelm:

nuqneH

Gibt es irgendwo eine Anleitung, was alles zu tun ist beim Wechsel?

[qa-changing-encoding], das geht allerdings nicht auf Datenbaken ein, bejaht aber:

Muß ich meine php-dateien dann auch als utf-8 codiert abspeichern, sofern sie Ausgabetexte mit deutschen Umlauten enthalten?

Für deine Datenbank wirst du evtl. in [article-unicode-migration] fündig oder im SEFHTML-Wiki: Zeichencodierung/MySQL

Qapla'