Umlaute werden falsch dargestellt

Irgendwelche Probleme mit XAMPP für Windows? Dann ist hier genau der richtige Ort um nachzufragen.

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 06. December 2014 13:10

Schwarzmond wrote:Ah, okay, danke.

Und für alle, die das nicht sofort verstehen und (wie ich) erstmal im Internet suchen müßten...
...einfach auf den eigenen Websiten, die man mit Xampp offline bearbeiten/anschauen will, als erste Info (vor dem <html...>-Tag):

<?php
header('Content-Type: text/html; charset=iso-8859-1');
?>

eintragen.
:D


Nein!

Stattdessen php.ini bearbeiten und dort (und nur dort)

Code: Select all
default_charset="iso-8849-1"


eintragen. Und danach Apache neu starten.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Altrea » 06. December 2014 14:09

Nobbie wrote:Nein!

Stattdessen php.ini bearbeiten und dort (und nur dort)

Code: Select all
default_charset="iso-8849-1"


eintragen. Und danach Apache neu starten.

Das ist die schlechteste aller Möglichkeiten. UTF-8 hat sich mittlerweile zum Quasi-Standard im Web entwickelt.
Die großen und etablierten Webanwendungen setzen alle auf UTF-8.

Dann doch eher (auch wenn es von PHP nicht empfohlen wird) default_charset auf einen leeren String setzen, um dasselbe Verhalten zu erhalten wie vor PHP 5.6, also so:
Code: Select all
default_charset=""


Oder über eine .htaccess Datei den default_charset für einzelne Projekte gezielt setzen.

Ich entwickel keine Anwendungen mehr auf ISO-8859-1 Basis. Datenbanken und Dateien sind bei mir durchweg mit UTF-8 encodiert.
We don't provide any support via personal channels like PM, email, Skype, TeamViewer!

It's like porn for programmers 8)
User avatar
Altrea
AF Moderator
 
Posts: 11926
Joined: 17. August 2009 13:05
XAMPP version: several
Operating System: Windows 11 Pro x64

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 06. December 2014 15:21

Altrea wrote:Das ist die schlechteste aller Möglichkeiten. UTF-8 hat sich mittlerweile zum Quasi-Standard im Web entwickelt.
Die großen und etablierten Webanwendungen setzen alle auf UTF-8.


Das mag ja sein, aber Deine Antwort ist am Problem vorbei: hier schreiben exakt alle die, die eben NICHT in UTF-8 codiert haben. Entweder müssten die nun alle Dokumente im Quelltext überarbeiten und auch die Datenbanken konvertieren (was ziemlich lästig sein kann), oder sie müssen (wie ich es empfehle) den Default so vereinbaren, wie es offensichtlich bisher der Fall war. Es hat sich ja nur das Default Verhalten geändert. Nur die Lösung, in alle Dokumente die header()-Funktion zu benutzen, das ist nun wirklich von hinten durch die Brust ins Auge.

Wer (wie Du empfiehlst) ohnehin schon auf utf-8 umgestiegen ist, der braucht gar nichts zu tun und der wird auch hier nicht melden, dass seine Anwendung nicht läuft. Für den ändert sich nichts.

Unabhängig davon bin ich kein unbedingter Anhänger von utf-8, das ist eigentlich nur notwendig, wenn man multinationale Webseiten betreibt, das dürfte bei den wenigsten Anwendern der Fall sein. Ansonsten ist es einfach nur Overkill und lange lange Zeit gab es auch Probleme mit den strlen()-Funktionen (keine Ahnung, ob das inzwischen vollkommen ausgemerzt ist), wenn dort multibyte-Character berechnet wurden.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Altrea » 06. December 2014 16:26

Nobbie wrote:oder sie müssen (wie ich es empfehle) den Default so vereinbaren, wie es offensichtlich bisher der Fall war.

Bisher wurde nicht ISO-8859-1 als Standard gesetzt, sondern "no value" also einfach undefiniert.
Dadurch wurde auch kein charset im Apache Response Header mitgeschickt und der Browser hat selbst entschieden, welchen Zeichensatz er verwendet (was ein ziemliches Glückspiel sein kann).

Nobbie wrote:Es hat sich ja nur das Default Verhalten geändert. Nur die Lösung, in alle Dokumente die header()-Funktion zu benutzen, das ist nun wirklich von hinten durch die Brust ins Auge.

Deine Lösung ist wie mit einem 5kg Vorschlaghammer einen kleinen Nagel in die Wand zu schlagen. Einen generellen Standardwert für alle PHP basierten Webprojekte zu setzen, der fernab des Quasi-Standard ist, nur weil eine Einzelanwendung ein Problem hat, ist nicht nur unnötig, es kann bei anderen Anwendungen dazu führen, dass diese ein Problem mit der Zeichenkodierung haben. Wenn Einzelanwendungen spezielle Voraussetzungen benötigen, dann setzt man diese empfohlenerweise so, dass sie möglichst wenig Einfüsse außerhalb des Projektes haben.

Nobbie wrote:Unabhängig davon bin ich kein unbedingter Anhänger von utf-8, das ist eigentlich nur notwendig, wenn man multinationale Webseiten betreibt, das dürfte bei den wenigsten Anwendern der Fall sein. Ansonsten ist es einfach nur Overkill und lange lange Zeit gab es auch Probleme mit den strlen()-Funktionen (keine Ahnung, ob das inzwischen vollkommen ausgemerzt ist), wenn dort multibyte-Character berechnet wurden.

PHP bietet hierfür seit PHP 4 sogenannte Multibyte-Funktionen an, mb_strlen zum Beispiel. Es gibt keine nennenswerten Nachteile mehr bei der Verwendung von UTF-8 (Speicherverbrauch sollte in der heutigen Zeit nun wirklich nicht das Argument sein). Dafür ist UTF-8 zukunftssicherer. In vielen anderen Teilen der Welt ist ISO-8859-1 der Exot und wie du schon sagst ist UTF-8 bei vielen Multilingual ausgelegten Anwendungen schon lange gesetzt. UTF-8 bietet einfach nur Vorteile ohne Nachteile aufzuweisen. Ich sehe keinen Grund mehr an ISO-8859-1 zu hängen. Zudem ist es nicht aufwändiger UTF-8 zu verwenden als ISO-8859-1.

Natürlich kostet es Einmalaufwand, seine Anwendung auf UTF-8 umzustellen und das rechnet sich nicht für jede Anwendung. Doch alle Anwendungen die mit den neuen Standardeinstellungen nicht zurecht kommen haben bereits jetzt ein Problem und bleiben auch weiterhin problematisch wenn man nichts unternimmt. Irgendwann haben auch die namhaften Hoster auf PHP 5.6 umgestellt und nicht jeder von ihnen lässt jedwede Zugriffe auf die Basiseinstellungen zu.

Um es auf den Punkt zu bringen: Deine Lösung funktioniert für die hier geschilderten Fälle. Doch es gibt andere Lösungen die ich für empfehlenswerter halte. Es soll jeder für sich selbst abwägen, welche er bevorzugt.
We don't provide any support via personal channels like PM, email, Skype, TeamViewer!

It's like porn for programmers 8)
User avatar
Altrea
AF Moderator
 
Posts: 11926
Joined: 17. August 2009 13:05
XAMPP version: several
Operating System: Windows 11 Pro x64

Re: Umlaute werden falsch dargestellt

Postby Manfred62 » 06. December 2014 16:44

Mein Hinweis von gestern bezog sich auf die Darstellung der "localhost" Startseite. Dort entstand die falsche Darstellung wohl nur, weil die Sprachdateien nicht in utf-8 gespeichert wurden.
Ansonsten gebe ich Altrea recht. Ich weiss schon gar nicht mehr, seit wann ich nur noch in utf-8 arbeite. Mit utf-8 geht: alles, immer, überall.
Manfred62
 
Posts: 6
Joined: 05. December 2014 19:21
Operating System: Windows 7

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 07. December 2014 00:59

Altrea wrote:Deine Lösung ist wie mit einem 5kg Vorschlaghammer einen kleinen Nagel in die Wand zu schlagen. Einen generellen Standardwert für alle PHP basierten Webprojekte zu setzen, der fernab des Quasi-Standard ist, nur weil eine Einzelanwendung ein Problem hat,


An diesem Punkt werden wir uns nicht einig werden, es gibt nicht den geringsten Grund, in Deutschland deutsche Webseiten mit utf-8 zu erstellen und es ist ja gerade der Sinn den default_charset so zu setzen, wie man es üblicherweise in den eigenen Projekten und Regionen tut. Wenn man utf8 als Immer-Standard definieren will (wofür es nicht den geringsten Grund gibt, was auch vollkommen unbewiesen ist, ich habe noch kein einziges Projekt mit utf8 designed und werde es auch so lange nicht tun, bis ich es BRAUCHE) und sonst nur "leer", dann hätte sich das PHP Team das Einführen dieser Variable schenken können.

Ich bin nicht so leichtgläubig was vermeintliche Standards betrifft, sondern bin immer noch in der Lage, selbst zu beurteilen, was ich für sinnvoll halte, egal wer was benutzt. DIe ISO Zeichensätze sind absolut ausreichend für unseren Sprachraum und ich muss nicht Probleme lösen, die sich mir nicht stellen. Wenn man sich mal die sog. "Quasi Standards" im Programmierstil anschaut (Quellcode), dann sieht man sehr schnell, dass da unsägliches Zeug von Kiddies zusammengehämmert wird, was von jedem wirklich guten Projektleiter abgelehnt würde. Das wäre das allerletzte, wenn ich aus so einem Codematsch einen Standard ableite.

Und ausgerechnet hier im Forum zu empfehlen, den default_charset leer zu lassen, wo genau das die einzige Empfehlung auf PHP.net ist, was man NICHT tun soll (und dieser Meinung bin ich durchaus auch), das ist wirklich definitiv verkorkst.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 07. December 2014 01:07

Manfred62 wrote:Mit utf-8 geht: alles, immer, überall.


Totaler Blödsinn, es erwiesenermaßen immer noch fehlerfreier, in normalen one Byte Character Codes zu programmieren, die sind seit Urzeiten bekannt und da gibt es keine Probleme. Es gibt massenhaft PHP Versionen, wo falsche Stringlängen berechnet werden, wenn im utf8 Code multibyte Character codiert sind.

Es haben massenhaft Editoren das Problem, dass sie im Quelltext für utf8 den BOM Header in die Datei schreiben, was PHP nicht verkraftet. Es gibt Probleme mit der Sortierung von SQL Datenbanken, weil die Sortierung nicht konform ist zur gewohnten Sortierung, wenn Umlaute im String sind. Usw. etc. pp. - wenn es überhaupt irgendwo Probleme gibt, dann allenfalls im utf8 Zeichensatz und nicht umgekehrt.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Altrea » 07. December 2014 01:27

@Nobbie: Ich finde in deiner Argumentation keinen Grund UTF-8 nicht zu verwenden. Latin 1 für Anwendungen im rein deutschen Sprachraum zu verwenden wird den meisten Entwicklern reichen, da stimme ich dir zu. Doch ich bin der Meinung, dass man für solche Anwendungen genauso gut UTF-8 verwenden kann ohne dass man davon einen Nachteil spürt.

Nobbie wrote:Und ausgerechnet hier im Forum zu empfehlen, den default_charset leer zu lassen, wo genau das die einzige Empfehlung auf PHP.net ist, was man NICHT tun soll (und dieser Meinung bin ich durchaus auch), das ist wirklich definitiv verkorkst.

default_charset auf leeren String zu setzen hat dieselben negativen Auswirkungen wie bei älteren PHP-Versionen wo es keinen generellen Standardwert gab: htmlentities und htmlspecialchars bereinigen Strings nicht auf Grundlage des Stanard-Zeichensatzes. Dies kann ein Sicherheitsrisiko sein, da man Zeichen anderer Zeichensätze unterschieben kann, die vom Filter nicht ausgefiltert werden und so XSS und andere Angriffe ermöglichen.
Doch diese Anwendungen hatten diese Sicherheitslücke auch schon vor PHP 5.6, von daher sehe ich diese Empfehlung nicht so kritisch.
Eine Anwendung die den benötigten Zeichensatz nicht schon längst im Apache header setzt ist eh schon ein Kandidat für eine Coderevision. Da dürfte diese kleine Sicherheitslücke noch das geringste Problem sein.
We don't provide any support via personal channels like PM, email, Skype, TeamViewer!

It's like porn for programmers 8)
User avatar
Altrea
AF Moderator
 
Posts: 11926
Joined: 17. August 2009 13:05
XAMPP version: several
Operating System: Windows 11 Pro x64

Re: Umlaute werden falsch dargestellt

Postby Schwarzmond » 07. December 2014 07:38

Hi,

ich benutze auf meinen Websiten den ISO-Zeichensatz, weil das "historisch" gewachsen ist (bzw. damals mal propagiert wurde und ich es dann übernommen habe - und nie wieder geändert). Habe kein Problem damit auf UTF-8 umzustellen... aber irgendwie klappt das alles nicht.

Wenn ich in meinen Websiten nun:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

definiere - stellt Xampp trotzdem nur



statt Sonderzeichen dar.
Irgendetwas läuft da noch schief. Aber selbst der Xampp interne "localhost" stellt keine korrekten Sonderzeichen dar und nur diese Fragezeichen:

Herzlichen Gl�ckwunsch:
XAMPP ist erfolgreich auf diesem Rechner installiert!

Nun kann es losgehen. :) Als erstes bitte einmal auf der linken Seite auf �Status� klicken. Damit bekommt man einen �berblick was alles schon funktioniert. Ein paar Funktionen werden ausgeschaltet sein. Das ist Absicht so. Es sind Funktionen, die nicht �berall funktionieren oder evtl. Probleme bereiten k�nnten.

F�r die OpenSSL Unterst�tzung benutzt bitte das Testzertifikat mit der URL https://127.0.0.1 bzw. https://localhost

Viel Spa�, Kay Vogelgesang + Kai 'Oswald' Seidler


Was muss ich denn jetzt wo ändern, dass zum einen die localhost-Seite korrekt dargestellt wird - und was, damit meine Websiten wieder korrekt dargestellt werden?
Liegts vielleicht auch am WinEDT9.0?
Angeblich soll dieser doch in UTF-8 in der Voreinstellung speichern?
:cry:
Schwarzmond
 
Posts: 17
Joined: 21. April 2013 11:16
Operating System: Windows7

Re: Umlaute werden falsch dargestellt

Postby Manfred62 » 07. December 2014 09:44

Was muss ich denn jetzt wo ändern, dass zum einen die localhost-Seite korrekt dargestellt wird - und was, damit meine Websiten wieder korrekt dargestellt werden?

Für die localhost-Seite --> die de.php in utf-8 speichern (wie schon beschrieben).
Unter Sublime Text:
"File - Save with Encoding - UTF-8"
Unter PSPad:
"Format - UTF-8"
Liegts vielleicht auch am WinEDT9.0?
Angeblich soll dieser doch in UTF-8 in der Voreinstellung speichern?

Vermutlich ist das dein Problem. Diesen Editor kenn ich nicht.
Manfred62
 
Posts: 6
Joined: 05. December 2014 19:21
Operating System: Windows 7

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 07. December 2014 12:26

Altrea wrote:Doch ich bin der Meinung, dass man für solche Anwendungen genauso gut UTF-8 verwenden kann ohne dass man davon einen Nachteil spürt.


Und wie oft hast Du selbst das leidige BOM Header Problem hier beantwortet? Kann man kaum noch zählen. Alleine das ist doch schon nervig bis zum geht nicht mehr.

Altrea wrote:default_charset auf leeren String zu setzen hat dieselben negativen Auswirkungen wie bei älteren PHP-Versionen wo es keinen generellen Standardwert gab: htmlentities und htmlspecialchars bereinigen Strings nicht auf Grundlage des Stanard-Zeichensatzes.


Exakt. Und dieses Problem wird nun auf diese Weise gelöst - und dann empfehlen ausgerechnet wir hier, diese Lösung nicht zu benutzen?? Das ist ungefähr vergleichbar, als wenn man register_globals hätte weiterbenutzen sollen, weil das vorher auch schon ein Problem war...

Die Probleme des utf8 Zeichensatzes sind ja auch nicht auf Apache beschränkt. Die größten gibt es auf Grund der variablen Stringlängen ("Barbel" belegt 6 Bytes, "Bärbel" belegt 7 Bytes), das zieht sich durch alle Komponenten hindurch (PHP; MySQL usw.) und es kann Probleme geben bei der Berechnung des richtigen Zeichens, wenn ein funktionierendes Script von Intel (Byte-Swapper) auf einen nicht-Byte-Swapper (früher die Motorola Prozessoren) portiert wird, exakt dafür wird der BOM in Textdateien geschrieben (das ist die einzige Möglichkeit, Textdateien als utf8 zu definieren, weil diese Dateien keinen Header besitzen, wie sonst beispielsweise *.jpg oder *.avi usw, also eigentlich jedes Binärformat) und exakt darüber stolpern dann wieder verschiedene Komponenten.

Was mich am meisten an utf8 stört, ist die Tatsache, dass es ein Mix-Code ist, konsequenter wäre es gewesen, einen eigenen Datentyp zu vereinbaren mit 16bit Zeichenlänge - dann bestimmt nämlich nicht der semantische Inhalt den Speicherbedarf (das ist eigentlich verrückt, wenn man mal länger darüber nachdenkt). Ob "Bärbel" oder "Barbel" - das sollte doch kein Unterschied sein, ist es aber. Inwiefern das zur Laufzeit zu Problemen führt, hängt natürlich davon ab, was man damit macht und was man nicht damit macht.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Nobbie » 07. December 2014 12:39

Was übrigens ein schönes Beispiel aus der Praxis ist, für Probleme mit utf8, das ist "Tapatalk". Kennt wahrscheinlich jeder hier?!

Je nach Kombination aus PHP Version, aus Tapatalk Version, aus IOs Version, aus Android Version usw. werden dort die Umlaute falsch dargestellt. Auf manchen Geräten sieht es richtig aus, auf anderen teilweise richtig (da sind dann die Beiträge richtig, aber die Betreffs falsch) und bei manchen wird jeder Umlaut falsch dargestellt und das in beide Richtungen.

Wenn Du Forenbetreiber bist (ich betreue u.a. ein paar SMF basierte Foren) dann quälst Du Dich durch Daueranfragen von Anwendern, warum die Umlaute in Tapatalk falsch sind - und Du kannst gar nichts ändern (das verstehen Laien aber nicht, das ist immer der Forenbetreiber Schuld). Je nach Client sieht es richtig aus, dann wieder nicht. Ich habe sogar für das Tapatalk Team noch eine Routine gepatched, damit es überhaupt unter PHP4 (was es immer noch auf Hostern gibt, damit muss man leben) darstellbar ist. Wenn Du den Quelltext siehst, was da zusammengeschustert wird, dann kriegst Du Haarausfall, das ist GRAUSAM!!
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

so konvertiert ihr nach UTF-8 w/o BOM

Postby sashaman » 07. December 2014 20:36

lieber nobbie,

ich respektiere deinen standpunkt, kann mich dem aber nicht anschließen.
das problem mit tapatalk kann ich mir schon vorstellen - ein mix aus foren die mal auf utf8 mal in andren codierungen laufen... wie soll denn da was einheitlich interpretiert werden

ich denke das hat schon gründe, weshalb php (und andere) utf8 als standard codierung "empfielt".
selbst windows http://msdn.microsoft.com/en-us/library/windows/desktop/dd374081%28v=vs.85%29.aspx
und etliche andre (z.B. http://utf8everywhere.org/) empfehlen utf8/unicode, bestimmt nicht grundlos. benutzt windoof nicht auch seit geraumer zeit unicode?
und es hilft probleme zu vermeiden wenn man seine lokalen development dateien beim hoster online stellen will.
ein zügige umstellung auf unicode halte ich deshalb für die beste lösung und unerlässlich!
persönliche anmerkung: der freundlichste dürftest du auch nicht sein, kommt mir so vor (und ich hab grad mal diesen thread gelesen).

ich möchte hier mal meine lösung für alle andren präsentieren:

Wie immer das wichtigste zuerst: BACKUP, BACKUP, BACKUP!

UTFCast Express runterladen + installieren (kostenlose version reicht vollkommen): http://www.rotatingscrew.com/utfcast-express.aspx
legt ein verzeichnis für die konvertierten datein an, z.B. C://UTF8converter
UTFCast starten

    1. wählt das verzeichnis aus, das die zu konvertierenden dateien beinhaltet
    2. wählt das zielverzeichnis
    3. deaktivieren, damit das BOM nicht geschrieben wird
    4. rekursiv anwählen, damit alle unterordner in die konvertierung einbezogen werden
    5. konvertierung starten

Image
http://goo.gl/e8EXb1
https://db.tt/7KI3dnf0

nun kopiert ihr den inhalt aus dem eigentlichen zielordner (punkt2) in den ursprünglichen quellordner (punkt 1) zurück,
natürlich müßt ihr die ordner migrieren (zusammenführen) und die dateien ersetzen.
deshalb nochmals: BACKUP gemacht?

Image
http://goo.gl/ClGgLz
https://db.tt/O3tRrzLV

die zu berücksichtigenden standardverzeichnisse sind:
C://xampp/htdocs
C://xampp/security

wenn ihr ordner mit euren eigenen scripten und projekten konvertiert natürlich ausgiebig testen!
das wars, alle ASCII dateien sollten nun UTF-8 kodiert sein.


mit notepad++ könnt ihr auch problemlos konvertieren:

Image
http://goo.gl/DxdMW2
https://db.tt/0En1JrTj

der prozess mit notepad++ kann auch automatisiert werden erfordert aber installation von
http://npppythonscript.sourceforge.net/download.shtml
und benötigt anpassungen im python script.
darauf gehe ich jetzt aber nicht näher ein, wer interesse hat findet die notwendigen infos bei
http://pw999.wordpress.com/2013/08/19/mass-convert-a-project-to-utf-8-using-notepad/
und
http://shoestringcode.blogspot.com/2013/11/bulk-convert-ansi-files-to-utf-8.html

hoffe damit zumindest einigen geholfen zu haben,
mfG sash

auf notation und interpunktion lege ich keinen wert (utf8unicodeci lol), wer rechtschreibfehler findet darf sie behalten
sashaman
 
Posts: 1
Joined: 07. December 2014 15:15
Operating System: win/linux/mac

Re: so konvertiert ihr nach UTF-8 w/o BOM

Postby Nobbie » 07. December 2014 22:17

sashaman wrote:ich denke das hat schon gründe, weshalb php (und andere) utf8 als standard codierung "empfielt".


Tut PHP aber gar nicht. PHP "empfiehlt", den default-charset zu setzen und damit eine klare Einstellung zu treffen. Es wird lediglich utf8 als Default angenommen (der aber ausdrücklich nicht empfohlen wird), was natürlich logisch ist, weil es da zumindest theoretisch alle abbildbaren Zeichen inkludiert sind. Aber das ist keinesfalls eine Empfehlung, sondern nur eine Notlösung, weil man irgendeinen Zeichensatz annehmen muss und dann wird man sicherlich nicht japanisch o.ä. nehmen. "Empfehlen" tut PHP nachhaltig, den Zeichensatz konkret zu definieren.

sashaman wrote:selbst windows http://msdn.microsoft.com/en-us/library ... 85%29.aspx
und etliche andre (z.B. http://utf8everywhere.org/) empfehlen utf8/unicode, bestimmt nicht grundlos. benutzt windoof nicht auch seit geraumer zeit unicode?


Wo glaubst Du, würde WIndows utf8 als Zeichensatz verwenden? In NTFS wird ANSI Code oder utf16 verwendet, insbesondere fopen() in VisualC benutzt ANSI.

sashaman wrote:und es hilft probleme zu vermeiden wenn man seine lokalen development dateien beim hoster online stellen will.


Nein, wieso glaubst Du das? Wo soll das helfen, wenn man einen Hoster mit PHP4 betreibt unter Debian Linus und einen extf2/3/4 unter latin1? Das ist alles Einstellungssache.

sashaman wrote:ein zügige umstellung auf unicode halte ich deshalb für die beste lösung und unerlässlich!


Das halte ich für eine Fehleinschätzung Deinerseits.

Vor allem ist ja noch wie vor nicht definiert WO genau Du utf8 als Default haben willst? Auf Webservern? In Datenbanken? Auf Dateisystemen? In Textdateien? Gerade letzteres ist bis inkl. heute ein häßliches Problem, weil der BOM Header zu unangenehmen Fehlern in PHP führt.

Du magst mich als "unfreundlich" empfinden, das stört mich nicht so sehr, aber Du solltest nicht unterschätzen, dass ich seit sehr (sehr!) vielen Jahren in der IT aktiv bin und viele Projekte geleitet und betreut, früher auch selbst mitprogrammiert habe. Ich gehöre nicht zu den Leuten, sich auf die Schnelle mal eine Meinung aneignen, nur weil ein Trend gerade mal "hipp" ist. Eine Generalumstellung in allen Bereichen der IT auf utf8 kann man natürlich anstreben (da hätte ich auch nichts gegen), aber so lange immer noch riesige Lücken in der universellen Unterstützung existieren (und die sind definitiv vorhanden), kann ich nicht guten Gewissens einem Anwender empfehlen, bedingungslos auf utf8 umzusteigen. Ganz besonders auch deswegen, weil es hier im europäischen Raum (und schon gar nicht in Deutschland) irgendeine Notwendigkeit gibt, auf utf8 umzusteigen, weil es de fakto kein einziges Problem löst, allenfalls aber welche schafft. Es dürfte nach wie vor ein weiter Weg sein, eine generelle Umstellung über Hersteller und Softwareentwickler aller Klassen und Kategorien hinweg eine einheitliche Umstellung auf utf8 zu erreichen, insbesondere unter dem Aspekt, dass es tonnenweise Software gibt, die mit ISO Zeichensätzen programmiert sind und die oft genug nicht "einfach mal so" auf utf8 umzustellen sind.
Nobbie
 
Posts: 13170
Joined: 09. March 2008 13:04

Re: Umlaute werden falsch dargestellt

Postby Schwarzmond » 07. December 2014 22:57

Hallo,

also ich störe nur ungern euer Fachgespräch - aber ich bin was diese Dinge angeht absolut hilflos...
:?

Ich will mit Xampp nur meine private Homepage programmieren - und seitdem ich die neuste Version installiert habe, bekomme ich noch nichtmal die � aus der localhost-Datei raus, also der von mir unveränderten, von Xampp mitgelieferten Datei.

Ich habe inzwischen im HEADER meiner HP

Code: Select all
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>


eingestellt, aber mit Xampp sieht es immer noch aus wie Kraut und Rüben... oder sollte ich sagen: Wie Kraut und R�ben.
:lol:

Eigentlich will ich ja nur meine HP programmieren, keine große Datenbank verwalten oder sonstwas machen, nur ein paar Seiten der privaten HP.
Online, auf dem Server meines Webspace-Anbieters, sieht auch alles prima aus, nur eben nicht auf Xampp.
Im Grunde ist es mir ja auch egal, ob ich jetzt alles auf UTF-8 umstelle, damit es wieder geht, oder ob ich durch "Tricks" Xampp dazu bekomme, wieder Nicht-UTF-8 kodierte Texte korrekt anzuzeigen... nur scheitere ich bisher sowohl beim einen, als auch anderen...
:oops:

Was ich aus der Diskussion hier mitgenommen habe: die HTML bzw. PHP-Datei selbst muß auch im UTF-8 Format sein. Angeblich speichert WinEDT9 von Haus aus im UTF-8 Format, aber da es nicht geht, würde ich jetzt gerne mal herausfinden, ob die gespeicherten Seiten wirklich UTF-8 kodiert sind. Wie kann man das denn herausfinden?
Mit Rechtsklick auf die Datei und "Infos" kann man da ja leider nicht erkennen....
:)
Schwarzmond
 
Posts: 17
Joined: 21. April 2013 11:16
Operating System: Windows7

PreviousNext

Return to XAMPP für Windows

Who is online

Users browsing this forum: No registered users and 27 guests