mod_rewrite, Umlaute & Codierung

[scnmitz73]

Zunächst einmal Hallo Zusammen (bin neu hier) ,

ich habe eine Frage zu Umlauten und Sonderzeichen in URLs:
wir haben gerade eine umfassende Website online gestellt und sämtliche URLs per mod_rewrite für Google leserlich gemacht...

Nun ist uns aufgelallen, dass Google & Wikipedia Umlaute und Sonderzeichen per UTF-8 (ä zu %C4%A4) codieren.
Dies scheint aus Suchmaschinensicht die optimale Codierung für Umlaute und Sonderzeichen darzustellen. Wir hingegen nutzen leider einen URL-Encode, der die Sonderzeichen und Umlaute auf andere Weise umwandelt (ä zu %E4):
https://www.google.de/search?hl=de&rls= ... a.de&meta=

Nun ist die Frage, ob wir nicht besser auf UTF-8 umstellen sollten, um zu gewährleisten, dass Google etwaige Suchbegriffe auch in den URLs findet (oder sollte das auch bei unserer Codierung funktionieren?). Falls die Umstellung sinnvoll wäre, stellt sich die Frage, was dann mit den bestehenden (anders codierten) Links in Google passiert - wäre hier ein redirect nötig oder können wir aufgrund der kurzen Historie darauf verzichten?

Vielen Dank!

Marc

[haha]

wir haben gerade eine umfassende Website online gestellt und sämtliche URLs per mod_rewrite für Google leserlich gemacht...

Das ist schonmal der grundlegend falsche Ansatz. URLs sollten für Menschen leserlich und benutzbar sein, nicht für Maschinen.

Nun ist uns aufgelallen, dass Google & Wikipedia Umlaute und Sonderzeichen per UTF-8 (ä zu %C4%A4) codieren.
Dies scheint aus Suchmaschinensicht die optimale Codierung für Umlaute und Sonderzeichen darzustellen.

Unicode ist grundsätzlich, nicht nur aus Suchmaschinensicht, die optimale Zeichentabelle. utf-8 dazu ist das geringstmögliche Übel, Unicode in Byteketten zu verfrachten.

Wir hingegen nutzen leider einen URL-Encode, der die Sonderzeichen und Umlaute auf andere Weise umwandelt (ä zu %E4):

Ihr benutzt iso-8859-1 oder windows-1252.

Nun ist die Frage, ob wir nicht besser auf UTF-8 umstellen sollten, um zu gewährleisten, dass Google etwaige Suchbegriffe auch in den URLs findet (oder sollte das auch bei unserer Codierung funktionieren?).

Zeichen außerhalb der Basisbuchstaben A-Z (groß und klein), der Ziffern 0-9 und einiger Satzzeichen sind Fremdkörper in URLs. Von daher wäre es das Klügste, gänzlich auf Umlaute und dergleichen in den URLs zu verzichten - Ihr habt mehr Ärger als Vorteile damit.

Zum einen bieten URLs keine Möglichkeit, transparent die verwendete Kodierung der Gegenstelle mitzuteilen. Die Interpretation der Bytes ist daher ein Ratespiel, unabhängig davon, ob iso-8859-Zeichen kodiert werden oder solche aus Unicode/utf-8.
Von solchen Wackelspielchen hält man sich besser fern. Dass Google Suchanfragen auf eine bestimmte Weise kodiert, hat damit nichts zu tun, denn hier redet Google mit sich selbst.

Zum anderen wird eine Seite nicht an Hand ihrer URL ausgesucht, sondern an Hand ihres Inhalts - dazu gehört auch die URL, aber nicht ausschließlich.
Darüber hinaus ist zumindest Google in der Lage, ä, ö, ü und ß mit der jeweils entsprechenden Variante ae, oe, ue und ss gleichzusetzen (schönes Beispiel: https://www.google.de/search?q=%C3%B6).

Es besteht also überhaupt kein Grund, Sonderzeichen in URLs einzusetzen.

Falls die Umstellung sinnvoll wäre, stellt sich die Frage, was dann mit den bestehenden (anders codierten) Links in Google passiert - wäre hier ein redirect nötig oder können wir aufgrund der kurzen Historie darauf verzichten?

Das müsst Ihr selbst entscheiden. Falls irgendwer von außen auf eine Eurer Seiten verweist, ist es nicht verkehrt, diese URLs umzuleiten bzw. noch besser denjenigen auf die Änderung hinzuweisen.

[scnmitz73]

Hallo haha,

vielen Dank erstmal für die schnelle Antwort!

Du hast natürlich recht, dass URLs usergerecht und nicht suchmaschinengerecht sein sollten und ebenso, dass man auf Umlaute verzichten sollte. Leider erlaubt dies unsere Infrastruktur nicht, da die URLs dynamisch aus der Datenbank auf der Basis von Namen und Bezeichnungen definiert werden - hier lassen sich Umlaute und Sonderzeichen leider nicht vermeiden.

Verstehe ich Deine Antwort richtig, dass in einem solchen Fall UTF-8 eingesetzt werden sollte, da Google dieses interpretieren kann, oder ist iso-8859-1 auch OK?
(https://www.google.de/search?q=%E4 liefert jedenfalls auch ä zurück...)

Dank Dir sehr!

Marc

[mcchaos]

Ihr könntet aber doch z.B. alle Umlaute mittels ä -> ae usw. codieren. Das ist noch besser lesbar als %E4.

[scnmitz73]

ä -> ae etc. war auch unser erster ansatz...
leider müssen wir datenbanktechnisch eine rückübersetzung gewährleisten und die bricht uns dann das genick, weil dosieraerosol hierbei auch zu ...ärosol.. übersetzt würde, was schlichtweg falsch wäre.

[Christophe]

Die in den Links verwendete Zeichencodierung muss natürlich der Zeichencodierung der Seite entsprechen. Wenn ihr auf der Seite wie auf Onmeda iso-8859-15 nutzt, solltet ihr auch Umlaute so codieren. ä = %e4 Wäre in diesem Fall absolut korrekt. Google und Wikipedia codieren Zeichen in utf-8, deshalb wird diese Codierung auch in den Links benutzt.

[rocker]

ä -> ae etc. war auch unser erster ansatz...
leider müssen wir datenbanktechnisch eine rückübersetzung gewährleisten

Am einfachsten geht das indem Du die entspechende Spalte verdoppelst.
In der einen alles ä-> ae ersetzt und in der suchst, aber die unersetzte mit gleichem Index anzeigen läßt

[scnmitz73]

@rocker: sorry, ich stehe auf dem schlauch... verstehe ich leider nicht!

[rocker]

@scnmitz73
kein Problem.

Du hast geschrieben das eine Rückübersetzung notwendig ist.
Was natürlich nicht geht, wie Du schon beschrieben hast.

Ist aber nicht notwendig, wenn Du 2 Datensätze benutzt.
Deinen mit Umlauten und einen automatisch ersetzten.

Den automatisch ersetzten benutzt Du dann für die URLs und die SQL-Abfrage, lieferst aber auf der Seite den Originaltext aus.

Beispiel Parfüm wird zu parfuem.
parfuem kommt in die URL und wird in der Tabelle gesucht und gefunden.
Jetzt nimmst Du aus der Tabelle die Originalspalte mit der gleichen Nr. und gibst Parfüm aus.

Hoffe das ist jetz verständlicher.

[mcchaos]

ä -> ae etc. war auch unser erster ansatz...
leider müssen wir datenbanktechnisch eine rückübersetzung gewährleisten und die bricht uns dann das genick, weil dosieraerosol hierbei auch zu ...ärosol.. übersetzt würde, was schlichtweg falsch wäre.

Nicht ganz Kommt drauf an, was ihr genau macht. Ich nehme an, dass Du bei "dosieraerosol" die Datenbank nach diesem Begriff durchsuchst. Du könntest dann aber ja suchen nach:
dosieraerosol ODER dosierärosol

Wenn Du das mit regular Expressions für alle ersetzten Umlaute machst, kannst Du auch nach allen Möglichkeiten suchen, selbst wenn das Wort "Aerosolkühlung" heißen würde. Du darfst dann natürlich nicht das Wort "Ärosolkuehlung" als anderen Wert in der Datenbank haben.

Klappt bei mir wunderbar, wenn Du nähere Infos willst, sag Bescheid. Die Datenbank darf dazu natürlich nicht sehr groß sein, weil REGEXP natürlich nicht so performant ist wie ein direkt match.

[800XE]

dosieraerosol ODER dosierärosol

Wenn Du das mit regular Expressions für alle ersetzten Umlaute machst, kannst Du auch nach allen Möglichkeiten suchen, selbst wenn das Wort "Aerosolkühlung" heißen würde. Du darfst dann natürlich nicht das Wort "Ärosolkuehlung" als anderen Wert in der Datenbank haben.

"Aerosolkühlung" wird in der URL zu "Aerosolkuehlung"

wieviel wörter hats du dann im Query?
warum wird das ursprüngliche gefunden aber "Ärosolkuehlung" nicht?



einfach=
rückverwandlung aller möglichen Umlaute = Ärosolkühlung
und dann wird es schon garnicht gefunden .... urlVersion + rückVersin sid ja nicht im Text drin

aufwendig=
urlwort das ae rückwandeln, wenn was rückgewandelt wurde, dann Querystring erweitern
urlwort das oe rückwandeln, wenn was rückgewandelt wurde, dann Querystring erweitern
urlwort das ue rückwandeln, wenn was rückgewandelt wurde,
dann Querystring erweitern

== urlwort = testaeueoe =
SQL WHERE testaeueoe OR testäueoe OR testaeüoe OR testaeueö

dann würde aber ein Orginal = testäueö = nicht gefunden
also das aufwenide noch aufwendiger und nochmal .....
.....


... oder machst du das pregmatschen in der SQL, das dort alle Umlaute vor dem WHERE in xe gewandelt werden (gibts eine Spache wo im zeichensatz ein x als Umlaute, also x mit Punkten drüber? )


ich glaub ich bleit bei meinen doppelten datensätzen


Titel=Wann wird es mal wieder kühl
url = wann-wird-es-mal-wieder-kuehl
text=Immer so heiß darußen ......

browserURL nehmen und im Feld url suchen
in <h1> und <title> kommt der orginaltitel

[mcchaos]

dosieraerosol ODER dosierärosol

Wenn Du das mit regular Expressions für alle ersetzten Umlaute machst, kannst Du auch nach allen Möglichkeiten suchen, selbst wenn das Wort "Aerosolkühlung" heißen würde. Du darfst dann natürlich nicht das Wort "Ärosolkuehlung" als anderen Wert in der Datenbank haben.

"Aerosolkühlung" wird in der URL zu "Aerosolkuehlung"

wieviel wörter hats du dann im Query?

Na, eben ganz genau eins, egal, wieviel Umlaute drin sind

SELECT id FROM table WHERE spalte REGEXP '(Ae|Ä)rosolk(ue|ü)hlung'

[800XE]

Du darfst dann natürlich nicht das Wort "Ärosolkuehlung" als anderen Wert in der Datenbank haben.

"Aerosolkühlung" wird in der URL zu "Aerosolkuehlung"
wieviel wörter hats du dann im Query?

Na, eben ganz genau eins, egal, wieviel Umlaute drin sind

SELECT id FROM table WHERE spalte REGEXP '(Ae|Ä)rosolk(ue|ü)hlung'

das matscht dann auch auf "Ärosolkuehlung"
warum sagtest du dann das das nicht in der Datenbank stehen dürfte?
*verwirtbin*


und wie ists beim REGEX mit case(in)sensitiv?
bei Ascii und bei Umlauten .... strcmpi ist ja nur bei ascii caseinsensitiv, nicht bei Umlauten

[haha]

Leider erlaubt dies unsere Infrastruktur nicht, da die URLs dynamisch aus der Datenbank auf der Basis von Namen und Bezeichnungen definiert werden - hier lassen sich Umlaute und Sonderzeichen leider nicht vermeiden.

Irgendwie müssen die Namen, aus denen letztlich auch die URLs entstehen, ja in die Datenbank kommen bzw. gekommen sein. Ich würde mich erstmal schlau machen, wie viele Namen überhaupt betroffen sind und anschließend abwägen, ob man nicht kurzerhand zu jedem Namen, der Sonderzeichen enthält, einen URL-Namen per Hand definiert. Das ginge sogar teilweise automatisch, da der eine oder andere Begriff bzw. Wortstamm sicher häufiger vorkommt (z. B. …säure => …saeure).
Ich denke, die Chancen, dass das gar nicht so viel Arbeit ist, stehen nicht schlecht, denn Umlaute sind bei den doch eher lateinisch/griechisch angehauchten Arzneimittelnamen bestimmt deutlich in der Minderheit. Und am Ende steht die meiner Meinung nach sauberste Lösung, das wäre mir was wert. Also zumindest mal durchzählen.

Die Idee, mit Mustern zu arbeiten, funktioniert natürlich auch, ist mir persönlich aber unsympatisch, da man sich Bequemlichkeit mit Unschärfe und Geschwindigkeitseinbußen erkauft.

Verstehe ich Deine Antwort richtig, dass in einem solchen Fall UTF-8 eingesetzt werden sollte, da Google dieses interpretieren kann,

Nein, es ging mir nur darum, dass Google mit seinen eigenen URLs logischerweise umgehen kann, aber daraus sollte gerade nicht einen Rückschluss auf die allgemeine Vor- oder Nachteilhaftigkeit ziehen. Google kann sowohl mit iso-8859-1, mit utf-8 als auch mit ae/oe/ue/ss umgehen (und sicher mit einer Reihe weiterer Verfahren), da gibt es keinen Unterschied.

Wie aber hier schon geschrieben wurde, solltet Ihr unbedingt die Zeichentabelle benutzen, die auch für den Seiteninhalt selbst genutzt wird. In Eurem Fall ist das dann vermutlich iso-8859-15. Für den in der URL genutzten Zeichensatz gibt es wie gesagt keine Kennzeichnungsmöglichkeit, deshalb besser durchgängig bei einem bleiben.

[mcchaos]

"Aerosolkühlung" wird in der URL zu "Aerosolkuehlung"
wieviel wörter hats du dann im Query?

Na, eben ganz genau eins, egal, wieviel Umlaute drin sind

SELECT id FROM table WHERE spalte REGEXP '(Ae|Ä)rosolk(ue|ü)hlung'

das matscht dann auch auf "Ärosolkuehlung"
warum sagtest du dann das das nicht in der Datenbank stehen dürfte?
*verwirtbin*

Jetzt bin ich verwirrt: Du sagts es doch schon selbst, dass in dem Fall dann beides matcht. Wenn aber beides matcht, weiß ich nicht mehr, welche Seite ich nun darstellen soll. Deshalb muß man aufpassen, dass sowas nicht vorkommt.

Beispiel:
URL ist aerosolkuehlung.html

Einträge in der DB:
1.) Aerosolkühlung
2.) Ärosolkuehlung

Nun wüßte ich nicht mehr, welcher Eintrag gemeint ist. Daher gilt es, solche "mehrdeutigen" Einträge zu vermeiden.