Regular Expressions HCl Überprüfen, ob C enthalten (nicht Cl!)

[Tux]

Hallo,
ich hab wieder ein kleines Problem:
Ich weiß ned, wie der reguläre Ausdruck heißen muss, mit dem ich überprüfen kann, ob C in HCl (oder auch HCl2 aba des gibts nich) enthalten ist. Dabei darf natürlich C nicht als Cl durchgehen.

bisheriges Ergebnis:
C[0-9]{0,2}

Hat jmd eine Idee?

[Tom]

Hello,

ich hab wieder ein kleines Problem:

Ich auch. Du hast nicht gesagt, mit welcher Programmiersprache Du die Regular Expression zu verwirklichen suchst.

Ich weiß ned, wie der reguläre Ausdruck heißen muss, mit dem ich überprüfen kann, ob C in HCl (oder auch HCl2 aba des gibts nich) enthalten ist. Dabei darf natürlich C nicht als Cl durchgehen.

bisheriges Ergebnis:
C[0-9]{0,2}

Wenn die Sprache das hält, was sie verspricht, könnte eine negative look ahead assertion tauglich sein.

C(?!l)

oder aber bei Dir auch einfacher

C[^a-z]    oder ähhnlich.

da ja das l von Chlor auf jeden Fall klein zu schreiben wäre.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Tux]

OK,
ich probier mein Problem nochmal genauer zu definieren:

Programmiersprache: PHP
Ziel:
Überprüfen, ob in einer Formel der Art CaCO2 oder auch HCl das Element $elm vorkommt.

Dafür muss ich wissen, was ich bei

preg_match_all('/'.$elm.'/',$formel,$elm_enthalten);

bei dem zweiten '/' noch hinzufügen muss.

[Tom]

Hello,

ich probier mein Problem nochmal genauer zu definieren:

Das Problem hatte ich schon verstanden. Ist ja auch schon öfter 'was zu lesen gewesen dazu hier im Forum. Nur wusste ich nicht mehr, ob Du C++, Perl oder PHP oder eine Linux-Shell benutzt hast...

Programmiersprache: PHP
Ziel:
Überprüfen, ob in einer Formel der Art CaCO2 oder auch HCl das Element $elm vorkommt.

Dafür muss ich wissen, was ich bei

preg_match_all('/'.$elm.'/',$formel,$elm_enthalten);

da funktionieren die lookbehind und lookahead assertions nicht, jedenfalls bei mir und ein paar Anderen, die sich daran bisher auch schon einen abgebrochen haben.

Du kannst dir für das Pattern doch aber die Untgerscheidung zwischen Groß- und Kleinbuchstaben nutzbar machen.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Wurstbrot13]

da funktionieren die lookbehind und lookahead assertions nicht, jedenfalls bei mir und ein paar Anderen, die sich daran bisher auch schon einen abgebrochen haben.

Also in PHP kann ich nich ^ für Anfang und $ für Ende verweden? http://www.lugaru.com/man/Regular.Expression.Assertions.html

preg_match_all('/'.$elm.'/',$formel,$elm_enthalten);

-.- ich weiß einfach ned, wie des gehen soll:
$elm wär jetz z.B. C, dann wäre mein Regulärer Ausdruck:

C
Aber wie bring ich dem jetz bei, dass er Sachen, mit HC nimmt, aber HCl nich nimmt?
(Für mich wär iwi C[^a-z] logisch, aba des funktioniert im RegEx Editor nich)

(Tux hat jetz nen Account un is Wurstbrot13)

[Wurstbrot13]

Aber wie bring ich dem jetz bei, dass er Sachen, mit HC nimmt, aber HCl nich nimmt?

Ups, gibts hier im Forum ne Editierfunktion? muss heißen: "wie HC nimmt" nich "mit HC nimmt"

[Tom]

Hello,

Schreib doch einfach noch mal ein paar erlaubte und ein paar unerlaubte Muster auf.
Anders kann man sich ja mit Chemie 6 nicht vorstellen, wie die Formeln auszusehen haben.

HCl
   HCOOH
   NaCl

usw.

Insbesondere, was ist _vor_ dem gesuchten C erlaubt und was _danach_
Und was ist NICHT erlaubt.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Wurstbrot13]

sorry, es is dumm während eines Threads, wo man der ersteller is den Namen zu ändern ... meine Antwort is jetz direkt unter meiner Fragestellung.

[Dennis]

Hi Tux,

preg_match_all('/'.$elm.'/',$formel,$elm_enthalten);

Eigentlich müsste das ziemlich einfach gehen... Wenn ich mir das gerade so überlege, dann muss auf $elm (z.B. C) in jedem Fall entweder ein Großbuchstabe (Beginn des Namens eines anderen Elements), ein Leerzeichen oder das Ende des Strings folgen.

/{$elm}([A-Z]| |$)/

Probier mal, ob das so funktioniert ;-)

Viele Grüße,
  ~ Dennis.

[Længlich]

Merhaba!

Eigentlich müsste das ziemlich einfach gehen... Wenn ich mir das gerade so überlege, dann muss auf $elm (z.B. C) in jedem Fall entweder ein Großbuchstabe (Beginn des Namens eines anderen Elements), ein Leerzeichen oder das Ende des Strings folgen.

... oder eine Ziffer, z.B. in C2H6, eine Klammer (runde zur Strukturierung und eckige für Komplexe, z.B. in K3[Fe(III)(CN)6] ) oder, im Falle von eingeschlossenen, aber nicht chemisch gebundenen Teilchen, ein @-Zeichen (z.B. ist N@C60 ein Fulleren-Molekül mit eingeschlossenem Stickstoffatom).
Und unübersichtliche Formeln werden auch gerne mal mit Bindestrichen strukturiert, z.B. CH2(OH)-CH(OH)-CH2(OH).

Viele Grüße vom Længlich

[Tom]

Hello,

... oder eine Ziffer, z.B. in C2H6, eine Klammer (runde zur Strukturierung und eckige für Komplexe, z.B. in K3[Fe(III)(CN)6] ) oder, im Falle von eingeschlossenen, aber nicht chemisch gebundenen Teilchen, ein @-Zeichen (z.B. ist N@C60 ein Fulleren-Molekül mit eingeschlossenem Stickstoffatom).
Und unübersichtliche Formeln werden auch gerne mal mit Bindestrichen strukturiert, z.B. CH2(OH)-CH(OH)-CH2(OH).

Also ist auf jeden Fall sicher, dass auf das C _kein_ Kleinbuchstabe folgen darf, wenn man nach Kohlenstoff sucht? Also entweder Textende, oder ein "Nicht-Klienbuchstabe"?

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Længlich]

Teanastellen!

Also ist auf jeden Fall sicher, dass auf das C _kein_ Kleinbuchstabe folgen darf, wenn man nach Kohlenstoff sucht? Also entweder Textende, oder ein "Nicht-Klienbuchstabe"?

Meines Wissens ja. Als Kleinbuchstaben, die nicht Teil eines Elementsymbols sind, fallen mir jetzt nur n für Neutron und e- für Elektron ein - und die sind niemals Teil einer Verbindung, sondern stehen - wenn sie überhaupt auftauchen - alleine, d.h. von Leerzeichen abgetrennt.
Es sei denn, mal erlaubt Kleinbuchstaben als Variablen in allgemeinen Formeln, z.B. C(n)H(2n+2) als allgemeines Alkan mit n Kohlenstoffatomen (ich habe jetzt der Übersichtlichkeit halber Klammern gesetzt; normalerweise wäre (n) eher ein tiefgestelltes n). Aber das kommt im Anwendungsfall des OP vermutlich nicht vor.

Viele Grüße vom Længlich

[Wurstbrot13]

Schreib doch einfach noch mal ein paar erlaubte und ein paar unerlaubte Muster auf.

Anders kann man sich ja mit Chemie 6 nicht vorstellen, wie die Formeln auszusehen haben.

^ k:
Eingabe z.B.:
1. CaCO3
2. HCl
3. CO2
4. H2O
5. CaCl2
6. C8H18

Bei diesen soll zunächst überprüft werden, ob Cl (Chlor) enthalten ist:

1 nein
2 ja
3 nein
4 nein
5 ja
6 nein

Und jetzt noch, ob C (Kohlenstoff) in der Formel drin is:

1 ja
2 nein
3 ja
4 nein
5 nein
6 ja

Ich hoffe irgendjemand weiß einen passenden regulären Ausdruck für PHP, mit dem "Platzhalter" $elm (kann ich ja durch '/blabla'.$elm.'blabla/' verbinden)

[Tom]

Hello,

Schreib doch einfach noch mal ein paar erlaubte und ein paar unerlaubte Muster auf.
Anders kann man sich ja mit Chemie 6 nicht vorstellen, wie die Formeln auszusehen haben.

Eingabe z.B.:

1. CaCO3
2. HCl            if (strpos($_formel[2],'Cl') !== false)  -> es steckt Chlor drin
3. CO2
4. H2O
5. CaCl2
6. C8H18

Bei diesen soll zunächst überprüft werden, ob Cl (Chlor) enthalten ist:

Du könntest die mit Chlor (und alle anderen mit C?) also auf einem anderen Stapel auch unter demselben Index ablegen und aus diesem herausmehmen. Danach kann ja kein Chlor (oder ander Elemente mit C?) mehr drin sein, und das C wird dann für Kohlenstoff stehen.

1 nein
2 ja
3 nein
4 nein
5 ja
6 nein

Und jetzt noch, ob C (Kohlenstoff) in der Formel drin is:

1 ja
2 nein
3 ja
4 nein
5 nein
6 ja

Ich hoffe irgendjemand weiß einen passenden regulären Ausdruck für PHP, mit dem "Platzhalter" $elm (kann ich ja durch '/blabla'.$elm.'blabla/' verbinden)

Und den Ausdruck hatte ich Dir schon ein paarmal hingeschrieben

#C[^a-z]#

Dann sind C2, CH, CO usw. erlaubt, aber nicht Ca, Cs, Cl, ...

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Wurstbrot13]

Du könntest die mit Chlor (und alle anderen mit C?) also auf einem anderen Stapel auch unter demselben Index ablegen und aus diesem herausmehmen. Danach kann ja kein Chlor (oder ander Elemente mit C?) mehr drin sein, und das C wird dann für Kohlenstoff stehen.

Genau ... nur steh ich dann wieder vor dem selben Problem:
Wie schreib ich das Array, aus dem ich dann rausles, welche Elemente drin sin?
Mit Regular Expressions .. und mit welchem?

Und den Ausdruck hatte ich Dir schon ein paarmal hingeschrieben

#C[^a-z]#

Dann sind C2, CH, CO usw. erlaubt, aber nicht Ca, Cs, Cl, ...

Attempting to match: #C[^a-z]#
No matches found!

Bin ich zu doof?

Text to Query: HC
RegEx: C[^a-z] (oda auch #C[^a-z]#)

Wieso findet der da nix? (Ich nutzen den RegEx Editor)

[MudGuard]

Hi,

#C[^a-z]#

Bin ich zu doof?

Nö, Tom ;-)

Text to Query: HC
RegEx: C[^a-z] (oda auch #C[^a-z]#)

[^a-z] matcht einen Character, der kein Kleinbuchstabe ist.
Nach dem C kommt aber kein Kleinbuchstabe, also paßt der reguläre Ausdruck nicht.

Man müßte (wie bereits mehrfach erwähnt) mit einer negativen Lookahead-Assertion auf den Kleinbuchstaben gucken, nicht mit einer negierten Zeichenklasse - oder ersatzweise mit einer Alternative aus der negierten Zeichenklasse, Ziffer, Stringende (und ggf. auch noch Whitespace).

Wieso findet der da nix? (Ich nutzen den RegEx Editor)

Weil er nichts finden _darf_.

cu,
Andreas

[Tom]

Hello,

Nö, Tom ;-)

Wieso?

Text to Query: HC
RegEx: C[^a-z] (oda auch #C[^a-z]#)

Die # sind hier nur die Begrenzer für das Pattern. PHP verlangt die für die PCRE-Funktionen.

[^a-z] matcht einen Character, der kein Kleinbuchstabe ist.
Nach dem C kommt aber kein Kleinbuchstabe, also paßt der reguläre Ausdruck nicht.

Das stimmt doch. Nach dem C darf KEIN Kleinbuchstabe kommen, aber ein Leerzeichen, eine Ziffer usw.
Außerdem war es nur als erste Idee gedacht, um die Richtung zu finden.

Man müßte (wie bereits mehrfach erwähnt) mit einer negativen Lookahead-Assertion auf den Kleinbuchstaben gucken,

was aber aus mir nicht erklärlichen Gründen mit preg_match, preg_match_all usw. nicht funktioniert.
Angeblich soll es funktionieren, so zumindest laut dutzender Fundstellen im Web.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[MudGuard]

Hi,

Nö, Tom ;-)
Wieso?

Schrieb ich doch.

Text to Query: HC
RegEx: C[^a-z] (oda auch #C[^a-z]#)

Die # sind hier nur die Begrenzer für das Pattern. PHP verlangt die für die PCRE-Funktionen.

Um die # geht es doch gar nicht.

[^a-z] matcht einen Character, der kein Kleinbuchstabe ist.

^^^^^^^^^^^^^^^

Nach dem C kommt aber kein Kleinbuchstabe, also paßt der reguläre Ausdruck nicht.

Das stimmt doch. Nach dem C darf KEIN Kleinbuchstabe kommen, aber ein Leerzeichen, eine Ziffer usw.

Aber eben auch _kein_ Zeichen.

Dein Ausdruck verlangt nach dem C aber noch ein Zeichen (das kein Kleinbuchstabe sein darf).

Man müßte (wie bereits mehrfach erwähnt) mit einer negativen Lookahead-Assertion auf den Kleinbuchstaben gucken,
was aber aus mir nicht erklärlichen Gründen mit preg_match, preg_match_all usw. nicht funktioniert.

bei Dir.

Angeblich soll es funktionieren, so zumindest laut dutzender Fundstellen im Web.

Tut es ja auch. Irgendwas machst Du falsch.

cu,
Andreas

[Tom]

Hello,

Man müßte (wie bereits mehrfach erwähnt) mit einer negativen Lookahead-Assertion auf den Kleinbuchstaben gucken,
was aber aus mir nicht erklärlichen Gründen mit preg_match, preg_match_all usw. nicht funktioniert.

bei Dir.

Angeblich soll es funktionieren, so zumindest laut dutzender Fundstellen im Web.

Tut es ja auch. Irgendwas machst Du falsch.

Das hatte ich auch angenommen. Darum suche ich schon seit dem "Bananen-Thread" nach dem Fehler, aber bisher habe ich ihn nicht gefunden. Ich werde mir mal Christians Beispiel ansehen. Muss doch rauszufinden sein, was ich da falsch mache!

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Christian Seiler]

Hallo,

[^a-z] matcht einen Character, der kein Kleinbuchstabe ist.
Nach dem C kommt aber kein Kleinbuchstabe, also paßt der reguläre Ausdruck nicht.

Das stimmt doch. Nach dem C darf KEIN Kleinbuchstabe kommen, aber ein Leerzeichen, eine Ziffer usw.

Ja, MudGuard ist etwas durcheinander gekommen bei seiner Erklärung. Was er _eigentlich_ meinte:

1. String: "HC"
2. Regexp: #C[^a-z]#

Matcht nicht. Grund: *NACH* dem C in "HC" kommt kein weiteres Zeichen mehr. Denn [^a-z] heißt eben NICHT "alles außer Kleinbuchstabe" sondern (Unterschied!) "EXAKT EIN ZEICHEN, das kein Kleinbuchstabe ist".

Man müßte (wie bereits mehrfach erwähnt) mit einer negativen Lookahead-Assertion auf den Kleinbuchstaben gucken,

Das muss man allerdings nicht unbedingt, es reicht, wenn man auf das Stringende prüft: #C([^a-z]|\z)# (gut, hier wäre statt \z auch $ möglich, d.h. #C([^a-z]|$)# da ein potentielles Neue-Zeile-Zeichen am Endes des Ausdrucks hier nichts kaputt macht).

Lookahead-Assertions benötigt man hier also nicht.

was aber aus mir nicht erklärlichen Gründen mit preg_match, preg_match_all usw. nicht funktioniert.

Wenn Lookahead-Assertions bei Dir nicht funktionieren, dann machst Du etwas falsch.

Schau Dir zum Beispiel in meinem Autoload-Artikel an, wie ich CamelCase trenne:

$teile = preg_split ('/(?<=.)(?=\p{Lu}\P{Lu})|(?<=\P{Lu})(?=\p{Lu})/U', ...);

Das sind AUSSCHLIESSLICH Lookbehind- und Lookahead-Assertions. Funktioniert prima.

Viele Grüße,
Christian

[Tom]

Hello Christian,

Wenn Lookahead-Assertions bei Dir nicht funktionieren, dann machst Du etwas falsch.

Ich habe mich an diesem Beispiel festgebissen und kriege es einfach nicht raus, was daran verkehrt ist. Es sollen alle Hyperreferenzen gefunden werden, die _kein_ 'javascript:' enthalten.

$pattern = '#<(a|area)\s[^>]*href=("|')?(?<!javascript:)(.*)\2.*>#Ui';

Leider sind sie dann doch immer drin.

Als Testbeispiel:

<?php

$source = file_get_contents('http://harzflirt.de');
  $pattern = '#<(a|area)\s[^>]*href=("|')?(?<!javascript:)(.*)\2.*>#Ui';
  preg_match_all($pattern, $source, $_hits);

echo "<pre>\n";
  echo htmlspecialchars(print_r($_hits,1));
  echo "</pre>\n";

?>

Wäre toll, wenn Du mir den Fehler sagen könntest.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Christian Seiler]

Hi,

$pattern = '#<(a|area)\s[^>]*href=("|')?(?<!javascript:)(.*)\2.*>#Ui';

Du hast eine Lookbehind-Assertion, Du willst aber eine Lookahead-Assertion. Dein alter Pattern endet nämlich beim Quote-Zeichen, d.h. (?<!javascript:) vergleicht, ob der String 'href="' (+ noch die paar Zeichen, die davor kommen) NICHT gleich 'javascript' ist, was immer wahr ist.

Du willst eine Lookahead-Assertion, weil Du ja wissen willst, ob das, was NACH der Position kommt, 'javascript:' ist. Also (?!javacript:) statt (?<!javascript:).

Viele Grüße,
Christian

[Tom]

Hello Christian,

$pattern = '#<(a|area)\s[^>]*href=("|')?(?<!javascript:)(.*)\2.*>#Ui';

Du hast eine Lookbehind-Assertion, Du willst aber eine Lookahead-Assertion. Dein alter Pattern endet nämlich beim Quote-Zeichen, d.h. (?<!javascript:) vergleicht, ob der String 'href="' (+ noch die paar Zeichen, die davor kommen) NICHT gleich 'javascript' ist, was immer wahr ist.

Du willst eine Lookahead-Assertion, weil Du ja wissen willst, ob das, was NACH der Position kommt, 'javascript:' ist. Also (?!javacript:) statt (?<!javascript:).

Vielen herzlichen Dank.
Also DIE Logik muss man erstmal verstanden haben.

So funktioniert es nun endlich. *puhhh*

Dein Posting werde ich mir wohl noch ein paarmal durchlesen, um es mir zu merken :-)

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Tom]

Hello Christian,

ich habe das nochmal versucht, nachzuvollziehen, was im Manual steht unter Assertions:
http://de2.php.net/manual/en/reference.pcre.pattern.syntax.php

[...] Note that the apparently similar pattern (?!foo)bar  does not find an occurrence of "bar" that is preceded by something other than "foo"; it finds any occurrence of "bar" whatsoever, because the assertion (?!foo) is always TRUE  when the next three characters are "bar". A lookbehind assertion is needed to achieve this effect.

Lookbehind assertions start with (?<= for positive assertions and (?<! for negative assertions. For example, (?<!foo)bar does find an occurrence of "bar" that is not preceded by "foo". [...]

Da steht doch aber nun genau das, was ich versucht hatte, oder wie ist das nun wieder zu verstehen?

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Christian Seiler]

Hi,

Da steht doch aber nun genau das, was ich versucht hatte, oder wie ist das nun wieder zu verstehen?

Nein. Der Absatz beschreibt genau das gleiche Problem, was Du hattest, nur gerade anders herum.

Viele Grüße,
Christian

[Tom]

Hello Christian,

so ganz ist das leider noch nicht ausgestanden. Ich habe jetzt eine Lösung, die funktioniert für alle meine Testfälle, aber leider widerspricht sie nach meinem Verständnis den Regeln für Lookahead-Assertions

$pattern= '#<(a|area)\s*.*(?!href=.?javascript:|href=.?mailto:)href=("|'|)?(\S+)\2\s*([^>]*)>(.+)</\1>#i';

findet alle Referenzen in <a> und <area>, egal ob in der Schreibweise mit einfachen, doppelten oder ohne Häkchen umd die URi und unterdrückt in diesem Beispiel 'mailto:' und 'javascript:'

Ich habe bestimmt 30 verschiedene Lösungen durch, die alle nicht funktioniert haben.
Auch Deine Lösung arbeitet leider nicht mit der Variante 'keine Häkchen um die URi' zusammen.

Es sind also nun mMn zwei Schmuddelstellen drin

1.)   ("|'|)?
  2.)   und die variable Länge der Assertion...

aber so geht es.
Ich habe ca. ein Dutztend valide und nicht valide Seiten im Netz ausgetestet damit.

Zufrieden bin ich aber nicht damit.

Testseiten lade ich noch auf den Server, falls erforderlich.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Tom]

Hello,

... und noch 'ne Runde preg_mtach_all().

Es waren noch soviel Fehler drin. :-(
Das Pattern war zu gefräßig. Von mehreren Links in einer Zeile wurde nur immer der letzte gefunden.

Ich habe es nicht anders hinbekommen. Ich bekomme die beiden Lösungen einfach nicht in ein Pattern.

#----- matcht alle Links MIT Häkchen und ohne JavaScript usw. -----------------------------------

$pattern1= '#<(a|area)\s*.*href=("|')(?!javascript:|mailto:)(\S*)\2\s*([^>]*)>(.+)</\1>#Ui';

#------------------------------------------------------------------------------------------------

#----- matcht alle Links OHNE Häkchen und ohne JavaScript usw. ----------------------------------

$pattern2= '#<(a|area)\s*.*href=(?!"|'|javascript:|mailto:)([^\s]*?)(?<!"|')\s*([^>]*)>(.+)</\1>#Ui';

#------------------------------------------------------------------------------------------------

So geht aber wenigstens nichts mehr verloren, alle Links werden gefunden.

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom

[Patrick Andrieu]

Hallo Tom!

Anfangs irreführend ist »behind« und »ahead«.

Einen Textstring lesen wir von links nach rechts, nach menschenverständnis wäre also behind, was danach kommt:

»Ich habe bis hierhin gelesen, was kommt dahinter?«
»Gar nichts!«

look behind = schau dahinter
look ahead = schau nach vorne

Wo ist dahinter, wo ist davorne? ;)

RegExp-mäßig muss man sich das aber so vorstellen:

look behind = ««««« in diese Richtung
look  ahead = »»»»» in diese Richtung

»Ich, RegExp, habe mich bis hierhin vorgearbeitet:|«

»hierhin« liegt »behind«, alles nach dem Pipe-Zeichen wäre »ahead«.

Viele Grüße aus Frankfurt/Main,
Patrick

[MudGuard]

Hi,

Nach dem C kommt aber kein Kleinbuchstabe, also paßt der reguläre Ausdruck nicht.

Das stimmt doch. Nach dem C darf KEIN Kleinbuchstabe kommen, aber ein Leerzeichen, eine Ziffer usw.

Ja, MudGuard ist etwas durcheinander gekommen bei seiner Erklärung. Was er _eigentlich_ meinte:

Korrekt, es hätte heißen müssen:
Nach dem C kommt aber kein Keinkleinbuchstabe ...

cu,
Andreas

[Tom]

Hello,

Korrekt, es hätte heißen müssen:
Nach dem C kommt aber kein Keinkleinbuchstabe ...

Bei soviel Chemie ist das ja kein Wunder :-)

Harzliche Grüße vom Berg und Frohe Weihnachtszeit

Tom