nicht angemeldet
Array-Elemente Suchen/Ersetzen
0 0
Array-Elemente Suchen/Ersetzen
Hallo Leute,
ich hab ein Array mit vielen Elementen
Beispiel-Auszug:
Uhr
Wanduhr
Armbanduhr
Jetzt soll nach dem string "uhr" gesucht werden und jeweils in ein <b>-Tag eingeschlossen werden. --> str_replace()
Da dadurch aber Uhr nicht gefunden wird (da Großbuchstabe) habe ich str_ireplace() verwendet.
str_ireplace($q, "<b>".$q."</b>", $liste)
Leider wird aber in der Ausgabe jetzt Uhr zu <b>uhr</b>, also ebenfalls kleingeschrieben.
Wie kann ich Groß-/Kleinbuchstaben-unabhängig nach einem Teilstring suchen, und diesen mit sich selbst ersetzen (nur halt mit dem <b>-Tag drumherum)?
Also so irgendwie:
str_ireplace($q, "<b>".$ITSELF."</b>", $liste)
Geht das?
-
Geht das?
In deinem Fall ist ein reguärer Ausdruck - preg_replace() beispielsweise - ggf. wesentlich sinnvoller.
-
Geht das?
In deinem Fall ist ein reguärer Ausdruck - preg_replace() beispielsweise - ggf. wesentlich sinnvoller.
Nachtrag:
Mit Stringfunktionen gehts natürlich auch - mit strpos() die Stelle deines Suchstrings suchen und den String zerlegen und mit den hervorhebungsbegrenzern (in deinem Fall ein b-Element) wieder zusammenbauen. -
In deinem Fall ist ein reguärer Ausdruck - preg_replace() beispielsweise - ggf. wesentlich sinnvoller.
Vielen Dank. Das sieht genauso aus als würde es das machen. Bei dem Zeichenwirrwarr blick ich allerdings nicht durch:
$suchmuster = array ('/(19|20)(\d{2})-(\d{1,2})-(\d{1,2})/','/^\s*{(\w+)}\s*=/'); $ersetzen = array ('\4.\3.\1\2', '$\1 ='); echo preg_replace($suchmuster, $ersetzen, '{startDatum} = 1999-5-27');Mein Suchmuster ist ja einfach nur $q
Wenn ich das einschließen will, ist dann mein $ersetzen = '<b>\1</b>' ?-
Mein Suchmuster ist ja einfach nur $q
Jein, du willst zwar "$q" finden, aber dein Suchmuster muss natürlich ein regulärer Ausdruck (Perl-Kompatible sein).
Wenn ich das einschließen will, ist dann mein $ersetzen = '<b>\1</b>' ?
Ja.
Dein Suchbegriff ist ein String und sieht so aus
"foo" oder "bar"
Das Suchmuster ist ebenfalls ein String - wenn du also nach "foo" suchen willst, sieht das so aus:
Du brauchst Begrenzer für deinen String - z.B. '' (Single quoted).
Weiters brauchst du Begrenzer für den Ausdruck - z.B. //Nach den begrenzern Brauchst du Modifikatoren - z.B. i (case-insensitive) und U (nicht gierig)
Zusammengebaut sieht das so aus:
$ausdruck = '//iU'Zwischen den Begrenzern des Ausdrucks kannst du nun das eigentliche Suchmuster einfügen - z.B. einfach nur "foo" um wörtlich nach "foo" zu suchen.
'/foo/iU'
Oder aber du erzeugst ein Untermuster ()
und gibst dort mehrere Möglichkeiten an (durch Pipes getrennt)
'/(foo|bar)/iU'
Deine Pipegetrennte-Liste an Wörtern kannst du dir z.B. per Implode zusammenbauen.
-
SEHR GEIL!
vielen vielen Dank für die ausführliche Erläuterung!!habs jetzt so übernommen und klappt auch:
preg_replace('/'.$q.'/iU', '<b>\0</b>', $results)Eine Frage noch: was heißt U = nicht gierig?
-
Eine Frage noch: was heißt U = nicht gierig?
In deinem Fall nicht relevant, da du ja nach exakten strings suchst. Aber bei Mustern ist das Verhalten von PHP per default "gierig", dh. es wird versucht so viel wie möglich zu finden.
Wenn du z.B. "foo(.*)bar" suchst - (.*) ist eine bliebige Zeichenkette . (beliebies Zeichen) * (0x oder öfter) - wird in folgendem string "foo baz bar baz bar" im gierigen Fall " bar baz bar " gefunden, im nicht gierigen Fall " bar ".
Sprich "gierig" versucht so viel wie möglich zu finden, "nicht gierig" so wenig wie möglich.
-
-
-
Mein Suchmuster ist ja einfach nur $q
Wenn ich das einschließen will, ist dann mein $ersetzen = '<b>\1</b>' ?Habe mir jetzt mal eine ausführliche Beschreibung von preg_replace durchgelesen. Hat aber noch mehr verwirrt als geholfen:
Ziel: Groß-/Kleinschreibungsunabhängig den String $q im array $liste suchen und dann vor und hinter den Teilstring <b> bzw. </b> setzen, aber die ursprüngliche Grpß-/Kleinschreibweise von $liste beibehalten.
Habe mehrere Versuche gestartet und es kommen immer Fehlermeldungen wie Delimiter must not be alphanumeric (
preg_replace($q, '<b>$0</b>', $liste))So wie ich die Beschreibung verstanden habe macht die Zeile für mich aber irgendwie sinn.
Wo liegt der Fehler?
-
Habe mehrere Versuche gestartet und es kommen immer Fehlermeldungen wie Delimiter must not be alphanumeric (
preg_replace($q, '<b>$0</b>', $liste))Siehe hier. Der Ausdruck erwartet Begrenzer - nicht nur das Suchmuster.
-
-
-
-
Hello,
ich habe
--> str_replace()
--> str_ireplace()
verwendet.Wir wollen aber bitte auch hier wieder die zugrundeliegende Codierung nicht vergessen.
Im Zeitalter von utf-8 sollte immer beachtet werden, in welcher Codierung die Daten vorliegen und welche Funktionen hier benutzt werden.Ich vertrete immer noch die Meinung, dass die PHP-Entwickler hier an der falschen Stelle angestetzt haben. Sie hätten die alten Funktionen ( z.B. strpos() ) auch für die Multibytecodierungen bestehen lassen sollen und auf einen (globalen) Schalter "set_encoding(ENCODING)" reagieren lassen sollen, anstatt neue Funktionen "mb_strpos()" zu erstellen. http://de.php.net/manual/en/function.mb-strpos.php
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ich vertrete immer noch die Meinung, dass die PHP-Entwickler hier an der falschen Stelle angestetzt haben. Sie hätten die alten Funktionen ( z.B. strpos() ) auch für die Multibytecodierungen bestehen lassen sollen und auf einen (globalen) Schalter "set_encoding(ENCODING)" reagieren lassen sollen, anstatt neue Funktionen "mb_strpos()" zu erstellen. http://de.php.net/manual/en/function.mb-strpos.php
Ja, über dieses hab ich mich auch schon gewundert - warum spezielle multibyte-Funktionen wo das doch zunehmend Standard wird :)
-
Ja, über dieses hab ich mich auch schon gewundert - warum spezielle multibyte-Funktionen wo das doch zunehmend Standard wird :)
Ein weiterer Grund, warum Perl cooler ist als PHP ;-)
-
Hello,
Ja, über dieses hab ich mich auch schon gewundert - warum spezielle multibyte-Funktionen wo das doch zunehmend Standard wird :)
ziemlich nutzloser Beitrag ohne nachvollziebare Beispiele...
Magst Du die mal liefern?Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ja, über dieses hab ich mich auch schon gewundert - warum spezielle multibyte-Funktionen wo das doch zunehmend Standard wird :)
Das ist suits Beitrag ;-)
ziemlich nutzloser Beitrag
Weshalb er das Flag "MEINUNG" trägt.
ohne nachvollziebare Beispiele... Magst Du die mal liefern?
Ich kann es versuchen.
1. Die hier angesprochenen PHP Multibyte-Funktionen sind in Perl nicht nötig. Auch kein globales Flag oder vergleichbares. Es reicht die Beherzigung einer simplen Regel:
Dekodiere alles, was reinkommt und enkodiere alles, was rausgeht.
Der dazwischen liegende Code interessiert sich nicht für Kodierungen: index(), substr(), split(), length()...
2. Habe ich kürzlich gelesen, warum gleichnamige Parameter oft mit diesem mir schleierhaften [] versehen sind. Sieht man sowas, arbeitet im Hintergrund PHP, richtig? Ursache: ein obskurer PHP Bug.
3. Seltsame Automatismen: Bei nem File Upload erzeugt PHP eine temporäre Datei, bevor ich als Scripter die Kontrolle bekomme, also eingreifen kann, richtig? Das könnte mir aber stinken, z.B. weil ich eine Progress Bar anbieten möchte.
-
- Habe ich kürzlich gelesen, warum gleichnamige Parameter oft mit diesem mir schleierhaften [] versehen sind. Sieht man sowas, arbeitet im Hintergrund PHP, richtig? Ursache: ein obskurer PHP Bug.
Dass PHP im Hintergrund arbeitet ist eine Mutmaßung - das dies aber ein uncooles PHP-Problem ist, stimmt.
-
Hello,
- Habe ich kürzlich gelesen, warum gleichnamige Parameter oft mit diesem mir schleierhaften [] versehen sind. Sieht man sowas, arbeitet im Hintergrund PHP, richtig? Ursache: ein obskurer PHP Bug.
Ich verstehe leider nicht, was Du sagen willst.
Die eckigen Klammern werden i.d.R. ganz einfach als zusätzlicher Operator benutzt. Dass PHP hier nicht sauber programmiert ist, und diesen Index-Operator nur als "Displacement" verwendet, anstatt ihn je nach Kontext individuell zu überladen, das ist ja noch nicht endgültig ausdiskutiert.
Im Kontext einer anderen Codierung sollte es möglich sein, den Operator auch codierungsgerecht zu benutzen, in einem String also das Zeichen- und nicht die Byteposition anzusprechen.
Um die Byteposition anzusprechen, bedürfte es einer zusätzlichen Funktion "byte_pos()" oder wie auch immer man die nennen wollte.
Das wäre mMn sauberer, als die Stringfunktionen neu zu deklarieren und neu zu implementieren.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
- Habe ich kürzlich gelesen, warum gleichnamige Parameter oft mit diesem mir schleierhaften [] versehen sind. Sieht man sowas, arbeitet im Hintergrund PHP, richtig? Ursache: ein obskurer PHP Bug.
Ich verstehe leider nicht, was Du sagen willst.
Die eckigen Klammern werden i.d.R. ganz einfach als zusätzlicher Operator benutzt.[] ist PHP spezifisch notwendig. Weder verlangen Spezifikationen es, noch ergibt es einen Sinn. Deshalb ist Perl cool und PHP doof. Noch doofer ist es, dass PHP mich zwingt, bei dieser mangelhaften Implementierung zu bleiben. Würde sich in Perl die Situation so darstellen, könnte ich sagen: Jungs, euer CGI Modul ist Mist. Ich nehme ein anderes!
Dass PHP hier nicht sauber programmiert ist, und diesen Index-Operator nur als "Displacement" verwendet, anstatt ihn je nach Kontext individuell zu überladen, das ist ja noch nicht endgültig ausdiskutiert.
Das verstehe ich nicht.
Im Kontext einer anderen Codierung sollte es möglich sein, den Operator auch codierungsgerecht zu benutzen, in einem String also das Zeichen- und nicht die Byteposition anzusprechen.
Um die Byteposition anzusprechen, bedürfte es einer zusätzlichen Funktion "byte_pos()" oder wie auch immer man die nennen wollte.In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.
-
Hi!
[] ist PHP spezifisch notwendig. Weder verlangen Spezifikationen es, noch ergibt es einen Sinn.
Einen Sinn sehe ich sehr wohl. Ohne [] bekommst du den Wert in skalarer Form. Mit [] bekommst du die Werte als Array, und das ganze auch noch verschachtelt, wenn du willst. Macht das Perl auch?
foo[bar][baz] ergibt $_POST['foo'] = array('bar' => array('baz' => value));
Wie macht denn Perl das? Entscheidet es von selbst, ob es einen skalaren Wert oder ein (flaches) Array liefert oder liefert es generell ein Array auch bei Einzelwerten?
Noch doofer ist es, dass PHP mich zwingt, bei dieser mangelhaften Implementierung zu bleiben.
Tut es nicht. Du kannst gern $_GET und $_POST ignorieren und die Auswertung von Querystring und Request-Body selbst übernehmen, wenn du das willst.
Dass PHP hier nicht sauber programmiert ist, und diesen Index-Operator nur als "Displacement" verwendet, anstatt ihn je nach Kontext individuell zu überladen, das ist ja noch nicht endgültig ausdiskutiert.
Das verstehe ich nicht.
Ihr habt da ein Missverständnis. Aus deinem Posting war nicht klar zu erkennen, dass du die [] in HTML-Eingabefeldnamen meinst (<input name="foo[]" ...). Tom ging von den als Operator in PHP verwendeten [] aus, also $string[4], um das 5. Zeichen/Byte im String anzusprechen beziehungsweise $array[key] für den Array-Zugriff.
Im Kontext einer anderen Codierung sollte es möglich sein, den Operator auch codierungsgerecht zu benutzen, in einem String also das Zeichen- und nicht die Byteposition anzusprechen.
Um die Byteposition anzusprechen, bedürfte es einer zusätzlichen Funktion "byte_pos()" oder wie auch immer man die nennen wollte.
In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.Das passt wegen des Missverständnisses nicht zueinander.
Lo!
-
[...] beziehungsweise $array[key] für den Array-Zugriff.
$array['key'] bitte :)
-
Hi!
[...] beziehungsweise $array[key] für den Array-Zugriff.
$array['key'] bitte :)Das key sollte hier als generischer Platzhalter für den Schlüsselwert verstanden sein, nicht als der String 'key'.
Lo!
-
-
Einen Sinn sehe ich sehr wohl. Ohne [] bekommst du den Wert in skalarer Form. Mit [] bekommst du die Werte als Array, und das ganze auch noch verschachtelt, wenn du willst. Macht das Perl auch?
foo[bar][baz] ergibt $_POST['foo'] = array('bar' => array('baz' => value));Zunächst ist wichtig: Perl macht da nichts. Das Ergebnis hängt davon ab, welches Modul ich verwende. CGI.pm, eine mir genehmere Variante die ich bei CPAN gefunden habe oder auch was selbstgestricktes sind denkbare Möglichkeiten.
In den meisten Fällen wird aber wohl CGI.pm zum Einsatz kommen. Hier ist mir kein Pendant zu o.g. PHP Variante bekannt, die wie ich zugeben muss, interessant klingt!Wie macht denn Perl das? Entscheidet es von selbst, ob es einen skalaren Wert oder ein (flaches) Array liefert oder liefert es generell ein Array auch bei Einzelwerten?
Wiederum ausgehend von CGI.pm (und auch CGI::Minimal): Ersteres trifft zu. Bei mehrfachem vorkommen eines Feldnames wird ein Array geliefert, sonst ein Wert.
Noch doofer ist es, dass PHP mich zwingt, bei dieser mangelhaften Implementierung zu bleiben.
Tut es nicht. Du kannst gern $_GET und $_POST ignorieren und die Auswertung von Querystring und Request-Body selbst übernehmen, wenn du das willst.Was spätestens bei Uploads aber problematisch wird. a) ist der Upload dann schon passé, b) ist das Auseinanderfieseln von Multipart ja keine Kleinigkeit.
Dass PHP hier nicht sauber programmiert ist, und diesen Index-Operator nur als "Displacement" verwendet, anstatt ihn je nach Kontext individuell zu überladen, das ist ja noch nicht endgültig ausdiskutiert.
Das verstehe ich nicht.
Ihr habt da ein Missverständnis. Aus deinem Posting war nicht klar zu erkennen...Stimmt, danke für die Aufklärung!
-
-
In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.
Bullshit.
Um Byte Interpretation zu erhalten, brauchst du das bytes Pragma.
Ausgenommen sind Funktionen oder Operatoren, die implizit Byteorientiert sind.Wenn du Tests mit UTF8 im Quellcode machst, musst du auch das utf8 Pragma verwenden, damit Perl deinen Quellcode als UTF8 versteht.
Bei I/O Operationen erkennt Perl automatisch UTF-8 und setzt das MB-Flag für die jeweiligen Variablen. Das ist es, was das Arbeiten mit UTF8 seit 5.8 so einfach macht.
#!perl use warnings; use strict; use constant { NL => "\n" }; BEGIN { use CGI::Carp qw(carpout); open(LOG, ">error.txt") or die "Unable to append to error.txt: $!\n"; carpout(*LOG); } use utf8; { use bytes; my $x = "ö"; print length($x), NL; } { no bytes; my $x = "ö"; print length($x), NL; } <>; exit;mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.
Bullshit.
Hach Beat, wenn Du das sagst.
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Encode ();
my $cgi = CGI->new;
my $utf8Parm = $cgi->param('utf8Parm'); # utf-8 kodiert übergeben: '€urö'
print 'Content-type: text/plain', "\n\n";
print 'LEN:', length($utf8Parm), "\n"; # 7
print 'STRINGLEN:', length(Encode::decode('UTF-8', $utf8Parm)), "\n"; # 4-
In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.
nicht String, sondern das UTF8 Flag gesetzt.
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Encode ();
my $cgi = CGI->new;
my $utf8Parm = $cgi->param('utf8Parm'); # utf-8 kodiert übergeben: '€urö'
print 'Content-type: text/plain', "\n\n";
print 'LEN:', length($utf8Parm), "\n"; # 7
print 'STRINGLEN:', length(Encode::decode('UTF-8', $utf8Parm)), "\n"; # 4Sorry, irgendwo hapert's bei mir noch.
Unter der Voraussetzung, dass du unter _encode_ auch "<:utf8" verstehst, hast du insofern Recht, als für die Variable das UTF8 Flag gesetzt wird, welches das Verhalten von Funktionen und Operatoren steuert.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
In Perl ist das ganz einfach: Wenn Du _nicht_ dekodierst, hast Du Bytes. Wenn Du dekodierst, hast Du einen String.
nicht String, sondern das UTF8 Flag gesetzt.Die mir bekannten, guten, Perl Unicode Tutorials legen allesamt Wert darauf, sich _nicht_ mit den Internas zu beschäftigen. Mit recht, wie ich finde!
Zur Erinnerung: Wir kommen vom Vergleich: "Warum Perl toller als PHP ist", hier im speziellen der Umgang mit utf8.
Sorry, irgendwo hapert's bei mir noch.
Unter der Voraussetzung, dass du unter _encode_ auch "<:utf8" verstehst, hast du insofern Recht, als für die Variable das UTF8 Flag gesetzt wird, welches das Verhalten von Funktionen und Operatoren steuert.Selbstverständich, wobei ich bei Deinem Beispiel "<:utf8" nicht von Encode, sondern von Decode sprechen möchte. Ansonsten ist es genau das, was passiert.
Da hier der IO Layer arbeitet gibt es womöglich intern technische Unterschiede(siehe oben), logische sind mir keine bekannt.-
Zur Erinnerung: Wir kommen vom Vergleich: "Warum Perl toller als PHP ist", hier im speziellen der Umgang mit utf8.
OK ab 5.8 kann man UTF8 konsequent behandeln. Leider muss ich in einem Fall immer noch mit Perl 5.6 Umgehen.
Ich weiss, dass bei PHP die Versionenunterschiede auch beträchtlch sein können. Man muss das also schon konkreter definieren.
PS: Etwas was definitiv auch in 5.8 nicht toll ist:
Warning: Wide Charakter in print...UTF8 ist zwar das Perl interne Charakterencoding, aber Perl vergisst per default diese Eigenschaft nach aussen. Das ist verwirrend, und was verwirrt, ist nicht einfach.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
OK ab 5.8 kann man UTF8 konsequent behandeln. Leider muss ich in einem Fall immer noch mit Perl 5.6 Umgehen.
Thats bad :-(
Ich weiss, dass bei PHP die Versionenunterschiede auch beträchtlch sein können. Man muss das also schon konkreter definieren.
Aber die PHP Jungs sagten doch sinngemäß(ohne Hinweis auf alte Versionen): "Also wenn Du n UTF-8 String splitten willst, musst Du die MB Dinger nehmen". Das fand ich dann schon befremdlich.
PS: Etwas was definitiv auch in 5.8 nicht toll ist:
Warning: Wide Charakter in print...Wann bekommst Du das? Ich hatte noch nicht einen Fall, wo mich dieses Warning _nicht_ auf eine Stelle aufmerksam gemacht hat, an der ICH Mist gebaut, bzw. etwas nicht beachtet habe.
UTF8 ist zwar das Perl interne Charakterencoding, aber Perl vergisst per default diese Eigenschaft nach aussen. Das ist verwirrend, und was verwirrt, ist nicht einfach.
Du würdest UTF8 brutal als Default überall erzwingen wollen? Das ist löblich, aber IMHO (noch) realitätsfern.
Wie verwirrend wäre das für all jene, die sich mit der Thematik überhaupt nicht auskennen?-
PS: Etwas was definitiv auch in 5.8 nicht toll ist:
Warning: Wide Charakter in print...Wann bekommst Du das? Ich hatte noch nicht einen Fall, wo mich dieses Warning _nicht_ auf eine Stelle aufmerksam gemacht hat, an der ICH Mist gebaut, bzw. etwas nicht beachtet habe.
zB:
use utf8;
print 'Content-type: text/html; charset=utf-8', NL,NL,
'<html>', ....
'<input type=text name="ct" value="€urö"><br>',NL,oder nach einem m// and print $1
Es spielt übrigens keine Rolle, ob ich direkt wide char UTF Zeichen im Code eingebe oder \x{} verwende.UTF8 ist zwar das Perl interne Charakterencoding, aber Perl vergisst per default diese Eigenschaft nach aussen. Das ist verwirrend, und was verwirrt, ist nicht einfach.
Du würdest UTF8 brutal als Default überall erzwingen wollen? Das ist löblich, aber IMHO (noch) realitätsfern.Ich würde mir ein Pragma wünschen, das alles als UTF-8 Encoding behandelt, bis das Gegenteil deklariert ist.
Wie verwirrend wäre das für all jene, die sich mit der Thematik überhaupt nicht auskennen?
In irgend einem Thread schrieb ich mal: UTF8 beantwortet sicher viele Fragen und wirft neue Fragezeichen auf...
Das Grundproblem ist, dass Characterencoding mit wenigen Ausnahmen nie als Teil eines Textes mitgeliefert wird.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Wann bekommst Du das? Ich hatte noch nicht einen Fall, wo mich dieses Warning _nicht_ auf eine Stelle aufmerksam gemacht hat, an der ICH Mist gebaut, bzw. etwas nicht beachtet habe.
zB:
use utf8;
print 'Content-type: text/html; charset=utf-8', NL,NL,
'<html>', ....
'<input type=text name="ct" value="€urö"><br>',NL,oder nach einem m// and print $1
Es spielt übrigens keine Rolle, ob ich direkt wide char UTF Zeichen im Code eingebe oder \x{} verwende.Ich habe persönlich noch keine Vakanz für "use utf8;" gehabt, verwende also keine Unicode Notationen im Source. HTML::Template ist mein Freund ;-)
Wenn ich Dein Beispiel verwende, erhalte ich hier auch exakt das von Dir genannte Warning.
Die gute Nachricht lautet:
binmode(STDOUT, ":utf8");
beseitig das Problem. Schau mal hier:http://perldoc.perl.org/perluniintro.html#Perl%27s-Unicode-Model
-
Wenn ich Dein Beispiel verwende, erhalte ich hier auch exakt das von Dir genannte Warning.
Was ich einfach etwas übereifrig finde. Ich möchte no warnings nicht auf ganze Blöcke notieren, und
{no warnings print $test; }
ist auch keine wirkliche Antwort.Vielleicht muss ich mal am Warningslevel von Perl drehen.
Die gute Nachricht lautet:
binmode(STDOUT, ":utf8");
beseitig das Problem. Schau mal hier:http://perldoc.perl.org/perluniintro.html#Perl%27s-Unicode-Model
Ich habe gestern übrigens den Schalte -C entdeckt ;)
http://perldoc.perl.org/perlrun.htmlmfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
-
-
-
-
-
-
-
-
-
-
-
Hi!
Ich vertrete immer noch die Meinung, dass die PHP-Entwickler hier an der falschen Stelle angestetzt haben. Sie hätten die alten Funktionen ( z.B. strpos() ) auch für die Multibytecodierungen bestehen lassen sollen und auf einen (globalen) Schalter "set_encoding(ENCODING)" reagieren lassen sollen, anstatt neue Funktionen "mb_strpos()" zu erstellen. http://de.php.net/manual/en/function.mb-strpos.php
Die mb-Funktionen sind eine Extension, also nicht unbedingt eine Erfindung der "PHP-Entwickler". Letztere haben ja vor, das Problem grundlegend zu lösen, das kommt aber aufgrund der Tragweite erst mit der nächsten Major-Version.
Wenn du aber mal genau nachschaust: Es gibt ein Function Overload Feature, mit dem du einige der normalen PHP-Funktionen schon jetzt mb-fähig machen kannst. (Hinweis im Handbuch beachten!)
Lo!
-
Hello,
Die mb-Funktionen sind eine Extension, also nicht unbedingt eine Erfindung der "PHP-Entwickler". Letztere haben ja vor, das Problem grundlegend zu lösen, das kommt aber aufgrund der Tragweite erst mit der nächsten Major-Version.
Das erklärt allerdings einiges.
Wenn du aber mal genau nachschaust: Es gibt ein Function Overload Feature, mit dem du einige der normalen PHP-Funktionen schon jetzt mb-fähig machen kannst. (Hinweis im Handbuch beachten!)
Danke. Guter Tipp. Das schaue ich mir an.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-