iconv Problem

[Konni Scheller]

Hallo,

ich versuchte das Beispiel auf
<http://www.interessante-zeiten.de/webdesign/ae-zu-ae-umlaute-mit-php-um
wandeln-312.html>

nachzuvollziehen.

Mein PHP5 gibt allerdings aus:

Ol'e Garcon! Diese S"ussspeise schmeckt gar nicht "ubel *b"orp*

Also so TeX-Style :)

Ich brauche allerdings das klassische - ae, oe, ue (für Dateinamen).

Woran hängt's? ist in iconv() was geändert worden? Falsche locale?

Bin für Tips dankbar.

Servus,
Konni

[Stefan Dreyer]

Post by Konni Scheller
Hallo,
ich versuchte das Beispiel auf
<http://www.interessante-zeiten.de/webdesign/ae-zu-ae-umlaute-mit-php-um
wandeln-312.html>
nachzuvollziehen.
Ol'e Garcon! Diese S"ussspeise schmeckt gar nicht "ubel *b"orp*
Also so TeX-Style :)
Ich brauche allerdings das klassische - ae, oe, ue (für Dateinamen).
Woran hängt's? ist in iconv() was geändert worden? Falsche locale?

Falsche Locale ist sehr wahrscheinlich, welche ist denn eingestellt?
Laut Beispielen im Manual muss es de_DE sein, damit es korrekt funktioniert.

[Konni Scheller]

Post by Stefan Dreyer
Falsche Locale ist sehr wahrscheinlich, welche ist denn eingestellt?
Laut Beispielen im Manual muss es de_DE sein, damit es korrekt funktioniert.

Ja, es ist "de_DE" - MacOS X 10.6.8.

Servus,
Konni

[Anton Steiner]

Post by Konni Scheller

Post by Stefan Dreyer
Falsche Locale ist sehr wahrscheinlich, welche ist denn eingestellt?
Laut Beispielen im Manual muss es de_DE sein, damit es korrekt funktioniert.

Ja, es ist "de_DE" - MacOS X 10.6.8.

Bei mir funktioniert es auch nicht. Ich verwende LANG=de_AT.UTF-8
LANGUAGE=de_AT:de unter Linux. Macht es Sinn, die Locale explizit in
php.ini zu setzen. Normal müsste PHP5 doch ohnehin UTF8 verwenden?

Servus
Anton

[Thomas 'PointedEars' Lahn]

Post by Konni Scheller
ich versuchte das Beispiel auf
<http://www.interessante-zeiten.de/webdesign/ae-zu-ae-umlaute-mit-php-um
wandeln-312.html>
nachzuvollziehen.

Hier ist nicht das Web. Bitte nicht nur URLs posten.

Post by Konni Scheller
Ol'e Garcon! Diese S"ussspeise schmeckt gar nicht "ubel *b"orp*
Also so TeX-Style :)

Faszinierend.

Post by Konni Scheller
Ich brauche allerdings das klassische - ae, oe, ue (für Dateinamen).
Woran hängt's? ist in iconv() was geändert worden? Falsche locale?

$ php -r '$satz = "Olé Garçon! Diese Süßspeise schmeckt gar nicht übel!
*börp*";> print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));'
Ole Garcon! Diese Suessspeise schmeckt gar nicht uebel! *boerp*

$ php -v
PHP 5.3.10-1 (cli) (built: Feb 3 2012 10:03:01)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

$ locale
LANG=de_CH.UTF-8
LANGUAGE=
LC_CTYPE="de_CH.UTF-8"
LC_NUMERIC="de_CH.UTF-8"
LC_TIME="de_CH.UTF-8"
LC_COLLATE="de_CH.UTF-8"
LC_MONETARY="de_CH.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="de_CH.UTF-8"
LC_NAME="de_CH.UTF-8"
LC_ADDRESS="de_CH.UTF-8"
LC_TELEPHONE="de_CH.UTF-8"
LC_MEASUREMENT="de_CH.UTF-8"
LC_IDENTIFICATION="de_CH.UTF-8"
LC_ALL=

[Konni Scheller]

Post by Thomas 'PointedEars' Lahn
Faszinierend.

Allerdings.

Post by Thomas 'PointedEars' Lahn

Post by Konni Scheller
Ich brauche allerdings das klassische - ae, oe, ue (für Dateinamen).
Woran hängt's? ist in iconv() was geändert worden? Falsche locale?

$ php -r '$satz = "Olé Garçon! Diese Süßspeise schmeckt gar nicht übel!
*börp*";> print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));'
Ole Garcon! Diese Suessspeise schmeckt gar nicht uebel! *boerp*
$ php -v
PHP 5.3.10-1 (cli) (built: Feb 3 2012 10:03:01)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
$ locale

iMac:~ konni$ php -v
PHP 5.3.8 (cli) (built: Dec 5 2011 21:24:09)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

iMac:~ konni$ php -r '$satz = "Olé Garçon! Diese Süßspeise schmeckt gar
nicht übel!
*börp*"; print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));'
Ol'e Garcon! Diese S"ussspeise schmeckt gar nicht "ubel!
*b"orp*

iMac:~ konni$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=


Wobei sich nichts ändert, wenn ich LC_ALL auf "de_CH" setze.

Seufz,
Konni

[Karl Pflästerer]

Post by Konni Scheller

Post by Thomas 'PointedEars' Lahn
Faszinierend.

Allerdings.

Post by Thomas 'PointedEars' Lahn

Post by Konni Scheller
Ich brauche allerdings das klassische - ae, oe, ue (für Dateinamen).
Woran hängt's? ist in iconv() was geändert worden? Falsche locale?

$ php -r '$satz = "Olé Garçon! Diese Süßspeise schmeckt gar nicht übel!
*börp*";> print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));'
Ole Garcon! Diese Suessspeise schmeckt gar nicht uebel! *boerp*
$ php -v
PHP 5.3.10-1 (cli) (built: Feb 3 2012 10:03:01)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
$ locale

iMac:~ konni$ php -v
PHP 5.3.8 (cli) (built: Dec 5 2011 21:24:09)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
iMac:~ konni$ php -r '$satz = "Olé Garçon! Diese Süßspeise schmeckt gar
nicht übel!
*börp*"; print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));'
Ol'e Garcon! Diese S"ussspeise schmeckt gar nicht "ubel!
*b"orp*
iMac:~ konni$ locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=
Wobei sich nichts ändert, wenn ich LC_ALL auf "de_CH" setze.

locale hat da nichts mit zu tun. Es sind zwei verschiedene iconv
Implementierungen.
Beim Mac ist es libiconv; unter Linux wird iconv von der glibc kommen.
Schaut man in die Quellen von libiconv, so findet sich dort die Datei
translit.def; ein Ausschnitt:

00E3 ~a # LATIN SMALL LETTER A WITH TILDE
00E4 "a # LATIN SMALL LETTER A WITH DIAERESIS
00E5 a # LATIN SMALL LETTER A WITH RING ABOVE
00E6 ae # LATIN SMALL LETTER AE

Für deinen Zweck ist iconv() unter Mac OS nicht direkt brauchbar.
Je nach Anforderungen würde ich entweder iconv() überhaupt nicht nutzen
und eine eigene Übersetzungsfunktion schreiben oder einfach das Ergebnis
der iconv() Transliteration umwandeln ("a => ae ...).

KP

[Konni Scheller]

Post by Karl Pflästerer
locale hat da nichts mit zu tun. Es sind zwei verschiedene iconv
Implementierungen.

Das hatte ich schon vermutet.

Post by Karl Pflästerer
Beim Mac ist es libiconv; unter Linux wird iconv von der glibc kommen.
Schaut man in die Quellen von libiconv, so findet sich dort die Datei
00E3 ~a # LATIN SMALL LETTER A WITH TILDE
00E4 "a # LATIN SMALL LETTER A WITH DIAERESIS
00E5 a # LATIN SMALL LETTER A WITH RING ABOVE
00E6 ae # LATIN SMALL LETTER AE
Für deinen Zweck ist iconv() unter Mac OS nicht direkt brauchbar.
Je nach Anforderungen würde ich entweder iconv() überhaupt nicht nutzen
und eine eigene Übersetzungsfunktion schreiben oder einfach das Ergebnis
der iconv() Transliteration umwandeln ("a => ae ...).

Ich habe jetzt ein

$name =
preg_replace("|\"(.)|","$1e",iconv("UTF-8","ASCII//TRANSLIT",$name));

eingefügt, das tut erstmal wunderbar.

Vielen Dank für die Erklärung.

Denn wenn es auch einfach ist, einen workaround zu schreiben, so möchten
man doch wissen, warum der ursprüngliche Ansatz nicht funktionierte :)

Servus,
Konni

[Matthias P. Würfl]

Post by Konni Scheller
Denn wenn es auch einfach ist, einen workaround zu schreiben, so möchten
man doch wissen, warum der ursprüngliche Ansatz nicht funktionierte:)

Ohne Genaues zu wissen: Ich hatte auch schon das Problem, dass bei
Texten vom Mac (also Word oder so) ein Umlaut dann bei mir (Win) aus 2
Zeichen bestand - und da war weder PHP noch (denke ich) iconv beteiligt.

Grüße, Matthias

[Thomas 'PointedEars' Lahn]

Post by Konni Scheller
Denn wenn es auch einfach ist, einen workaround zu schreiben, so möchten
man doch wissen, warum der ursprüngliche Ansatz nicht funktionierte:)

Obigens war keine Frage.

Ich hatte auch schon das Problem, dass bei Texten vom Mac (also Word oder
so) ein Umlaut dann bei mir (Win) aus 2 Zeichen bestand - und da war weder
PHP noch (denke ich) iconv beteiligt.

Das eine hat also mit dem anderen nichts zu tun. Vermutlich hast Du den
Umlaut unter Mac OS (X) in einem Klartexteditor (eher nicht Word) in UTF-8
oder UTF-16 codiert, wo er zwei Oktetts benötigt, die unter Windows bei
Verwendung der (hier falschen) Vorgabecodierung Windows-1252 als zwei
Zeichen dargestellt werden.

[Matthias P. Würfl]

Post by Thomas 'PointedEars' Lahn

Ich hatte auch schon das Problem, dass bei Texten vom Mac (also Word oder
so) ein Umlaut dann bei mir (Win) aus 2 Zeichen bestand - und da war weder
PHP noch (denke ich) iconv beteiligt.

Das eine hat also mit dem anderen nichts zu tun. Vermutlich hast Du den
Umlaut unter Mac OS (X) in einem Klartexteditor (eher nicht Word) in UTF-8
oder UTF-16 codiert, wo er zwei Oktetts benötigt, die unter Windows bei
Verwendung der (hier falschen) Vorgabecodierung Windows-1252 als zwei
Zeichen dargestellt werden.

Nein. Dann wären da zwei Zeichen Kuddelmuddel. Es ist aber ein Zeichen
Buchstabe und ein Zeichen (davor) die zwei Punkte, die normalerweise
darüber sein sollten.

Grüße, Matthias

[Karl Pflästerer]

Post by Matthias P. Würfl

Post by Thomas 'PointedEars' Lahn

Ich hatte auch schon das Problem, dass bei Texten vom Mac (also Word oder
so) ein Umlaut dann bei mir (Win) aus 2 Zeichen bestand - und da war weder
PHP noch (denke ich) iconv beteiligt.

Das eine hat also mit dem anderen nichts zu tun. Vermutlich hast Du den
Umlaut unter Mac OS (X) in einem Klartexteditor (eher nicht Word) in UTF-8
oder UTF-16 codiert, wo er zwei Oktetts benötigt, die unter Windows bei
Verwendung der (hier falschen) Vorgabecodierung Windows-1252 als zwei
Zeichen dargestellt werden.

Nein. Dann wären da zwei Zeichen Kuddelmuddel. Es ist aber ein Zeichen
Buchstabe und ein Zeichen (davor) die zwei Punkte, die normalerweise darüber
sein sollten.

Das hat einen anderen Grund: es gibt verschiedene Unicode Normalformen;
unter ihnen C (NFC(omposition)) und D (NFD(ecomposition).
NFC wird von den meisten Systemen außer Mac bevorzugt; Ä wird als ein
Zeichen gespeichert: U+00C4; utf-8 kodiert ist dies 0xC3 0x84

Unter Mac OS wird bevorzugt NFD erzeugt; ein Ä wird als ein »A« und
»U+0308« gespeichert; utf-8 kodiert ergibt dies 0x41 0xCC 0x88
Damit können Windows Programme kaum umgehen und zeigen A und ̈getrennt.

Den Effekt hast du leicht, wenn Mac Nutzer Webformulare per c&p
ausfüllen; dann können leicht solch kodierte Umlaute in der Datenbank
landen. Für Mac Nutzer sieht alles in Ordnung aus, Windows Nutzer sehen
Zeichenmüll.


KP

[Thomas 'PointedEars' Lahn]

Post by Karl Pflästerer

Post by Matthias P. Würfl
Nein. Dann wären da zwei Zeichen Kuddelmuddel. Es ist aber ein Zeichen
Buchstabe und ein Zeichen (davor) die zwei Punkte, die normalerweise
darüber sein sollten.

Das hat einen anderen Grund: es gibt verschiedene Unicode Normalformen;
unter ihnen C (NFC(omposition)) und D (NFD(ecomposition).
NFC wird von den meisten Systemen außer Mac bevorzugt; Ä wird als ein
Zeichen gespeichert: U+00C4; utf-8 kodiert ist dies 0xC3 0x84
Unter Mac OS wird bevorzugt NFD erzeugt; ein Ä wird als ein »A« und
»U+0308« gespeichert; utf-8 kodiert ergibt dies 0x41 0xCC 0x88
Damit können Windows Programme kaum umgehen und zeigen A und
getrennt.
Den Effekt hast du leicht, wenn Mac Nutzer Webformulare per c&p
ausfüllen; dann können leicht solch kodierte Umlaute in der Datenbank
landen. Für Mac Nutzer sieht alles in Ordnung aus, Windows Nutzer sehen
Zeichenmüll.

Danke für die Erklärung und den Hinweis. AIUI bedeutet das z. B., dass für
ein CMS, welches mit Mac OS benutzt werden können soll, eine Konvertierung
(z. B. mit der Normalizer-Klasse, siehe <news:slrnjmhhfc.ir8.hjp-
***@hrunkner.hjp.at>) stattfinden muss. Faszinierend. Ich frage mich,
welche "Web 2.0"-Applikationen diesen Umstand überhaupt berücksichtigen.

Interessanterweise wird NFD von KNode unter GNU/Linux/X.org teilweise
unterstützt. In Deinem Artikel sehe ich nämlich ein "g" mit Trema :) Beim
Antworten verschwindet hingegen dieses (zusammengesetzte) Zeichen.