nicht angemeldet
TS
Gunnar Bittersmann
TS
Gunnar Bittersmann
dedlfix
Rolf b
TS
dedlfix
TS
Matthias Scharwies
TS
Matthias Apsel
TS
TS
Hallo und guten Tag,
ich habe da nochmal ein Verständnisproblem:
welche HTML-relevanten Zeichen (Codes) gehen nicht problemlos in utf-8 über?
Welche häufigen Codes aus iso8859-1 aus dem europäischen Sprachraum (speziell DE) werden wie als [...] in utf-8 abgebildet?
Grüße
TS
@@TS
welche HTML-relevanten Zeichen (Codes) gehen nicht problemlos in utf-8 über?
Keine. UTF-8 kann alle Unicode-Zeichen codieren.
Welche häufigen Codes aus iso8859-1 aus dem europäischen Sprachraum (speziell DE) werden wie als [...] in utf-8 abgebildet?
Da habe ich ein Verständnisproblem. Was meinst du mit dieser Frage?
LLAP 🖖
Hallo und guten Tag,
@@TS
welche HTML-relevanten Zeichen (Codes) gehen nicht problemlos in utf-8 über?
Keine. UTF-8 kann alle Unicode-Zeichen codieren.
Schade, dass Du mich nicht verstehen willst! :-(
Welche Bytes, die iso8859-1 repräsentieren und für HTML (ohne DATA!) benutzt werden, gehen nicht problemlos in eine Multibyte-Codierung (hier: utf-8) über, wenn man denselben Bytestream benutzt?
Anders herum gefragt:
Was wird aus den Bytewerten, die keine direkte Repräsentanz finden in UTF-8?
Gibt es da eine Tabelle?
Gibt es überhaupt Werte aus iso-8859-1 über #127, die in utf-8 wieder eine gleichartige Darstellung bekommen?
Grüße
TS
hi,
auch wenn ich Deine Frage nicht so ganz verstehe...
Gibt es da eine Tabelle?
Unicode ist im Prinzip nur das Verwaltungssystem in dem jedes Zeichen der Welt einer eindeutigen Nummer -- dem sogenannten Codepoint -- zugeordnet ist, das ist die Zweckbestimmung des Unicode-Konsortium.
UTF-8 hingegen ist eine Kodierung die den Zusammenhang zwischen einem bestimten Codepoint und einer bestimmten Bytefolge beschreibt, praktisch ein Algorithmus.
Während in ISO-8859-1 der Codepoint 228 gleich Bytewertigkeit ist, ergeben sich in UTF-8-Kodierung aus demselben Codepoint 2 Bytes mit der Wertigkeit C3 A4. Umgekehrt definiert UTF-8 ebenso die Bestimmung des Codepoints aus einer bestimmten Bytesequenz.
Für PHP hab ich diesen Algorithmus hier mal aufgeschrieben.
mfg
@@TS
Schade, dass Du mich nicht verstehen willst! :-(
Am Willen mangelt es nicht. Sondern am Verständnis.
Welche Bytes, die iso8859-1 repräsentieren … gehen nicht problemlos in eine Multibyte-Codierung (hier: utf-8) über, wenn man denselben Bytestream benutzt?
Alle, deren höchstes Bit 1 ist …
Gibt es überhaupt Werte aus iso-8859-1 über #127, die in utf-8 wieder eine gleichartige Darstellung bekommen?
… wie du selbst schon ahntest.
und für HTML (ohne DATA!) benutzt werden
?? Häh?
Anders herum gefragt:
Was wird aus den Bytewerten, die keine direkte Repräsentanz finden in UTF-8?
Siehe englische Wikipedia: Invalid byte sequences
Gibt es da eine Tabelle?
Siehe englische Wikipedia weiter oben oder deutsche Wikipedia: Zulässige Bytes und ihre Bedeutung
LLAP 🖖
Tach!
welche HTML-relevanten Zeichen (Codes) gehen nicht problemlos in utf-8 über?
Keine. UTF-8 kann alle Unicode-Zeichen codieren.
Schade, dass Du mich nicht verstehen willst! :-(
Dann solltest du mal beschreiben, was mit übergehen konkret gemeint ist.
Welche Bytes, die iso8859-1 repräsentieren und für HTML (ohne DATA!) benutzt werden, gehen nicht problemlos in eine Multibyte-Codierung (hier: utf-8) über, wenn man denselben Bytestream benutzt?
Beschreib doch mal deine Aufgabenstellung genauer. Auch hier wieder kann ich aus dem unspezifischen "übergehen" nicht erkennen, was da wie ablaufen soll.
Anders herum gefragt:
Was wird aus den Bytewerten, die keine direkte Repräsentanz finden in UTF-8?
Ungültiges UTF-8 wird zum Fragezeichen im auf der Spitze stehenden Viereck. Welcher Vorgang bei dir unterlässt es denn ungültiges UTF-8 zu erzeugen?
Gibt es da eine Tabelle?
Gibt es überhaupt Werte aus iso-8859-1 über #127, die in utf-8 wieder eine gleichartige Darstellung bekommen?
Versteh ich auch nicht, was du genau meinst. Wenn ISO-8859-1 vorliegt (mit Zeichen/Bytes über 127) muss das umkodiert werden, wenn man das als UTF-8 haben möchte.
dedlfix.
Ich verstehe dich jetzt so, dass du wissen willst, ob die 256 Codepunkte von ISO-8859-1 die gleichen Zeichen codieren wie die Unicode Codepunkte 0-255. Die Antwort ist JA.
Es liegt aber in der Natur der Sache von UTF-8, dass man Codepunkte oberhalb von 127 nicht mit einem Byte darstellen kann. Siehe beispielsweise hier
Rolf
@@Rolf b
Iob die 256 Codepunkte von ISO-8859-1
Codepunkte?
Die Übersetzung von code point ist wohl: Zeichencode.
LLAP 🖖
Der Wikipedia Artikel „Zeichencodierung“ verwendet Codepunkt im Zusammenhang mit Unicode und definiert „Zeichencode“ als die Abbildung von Schriftzeichen zu Codepunkten.
Ich fühle mich nicht in schlechter Gesellschaft ;-)
Rolf
@@Rolf b
Der Wikipedia Artikel „Zeichencodierung“ verwendet Codepunkt im Zusammenhang mit Unicode
Verlässliche Quellen verwenden Zeichencode. ;-)
LLAP 🖖
Ui ui ui, das sollte sonst mal einer wagen. Sich in einer Diskussion selbst als Quelle zu nennen... Der Zwinkersmily möge es dir entschuldigen.
Im Ernst: gibt es eine „definitive“ Unicode-Terminologie auf Deutsch? Dass das W3C Lieferant einer solchen sein sollte, ist mir nicht ganz einsichtig.
Rolf
@@Rolf b
Ui ui ui, das sollte sonst mal einer wagen. Sich in einer Diskussion selbst als Quelle zu nennen...
Bin ich denn sonst einer? ;-)
Der Zwinkersmily möge es dir entschuldigen.
So war’s gemeint.
Dass das W3C Lieferant einer solchen sein sollte, ist mir nicht ganz einsichtig.
Ist es nicht. Die Übersetzungen zur Internationalisierung sind allesamt nicht vom W3C abgesegnet (im Gegensatz zu einigen Übersetzungen von Specs).
Ich dächte, ich hätte bei meiner Übersetzung damals bestehende Terminologie wiederverwendet – z.B. aus Michael Jendryschiks Artikel Zeichenkodierung. Falsch gedacht, weder „code point“ noch „Zeichencode“ noch „Codepunkt“ kommt da vor. Auch in alten E-Mails mit ihm oder Jens Meiert konnte ich diesbezüglich nichts finden. Sollte ich da Neuland betreten haben?
Im Englischen gibt es auch noch den Begriff character code – wie in Methodennamen charCodeAt(). Für mich ist character code und code point dasselbe. Also hab ich code point mit „Zeichencode“ übersetzt.
„Codepunkt“ halte ich für schlechtes Denglisch. Im Wikipedia-Artikel Zeichenkodierung wird „Zeichencode“ gar als Übersetzung von coded character set, codepage verwendet. Würde ich nicht tun.
Im Ernst: gibt es eine „definitive“ Unicode-Terminologie auf Deutsch?
Keine Ahnung. Wenn jemand andere Quellen als Wikipedia hat, immer her damit.
LLAP 🖖
Hallo und guten Abend,
nochmal anders gefragt:
Welche Bytefolge haben ein ä, ö, ü, Ä, Ö, Ü in utf-8 codiert?
usw.
Ist beim ö das zweite Byte 0x3C?
Grüße
TS
Tach!
Welche Bytefolge haben ein ä, ö, ü, Ä, Ö, Ü in utf-8 codiert?
Dafür gibt es genügend Tabellen und Tools.
Ist beim ö das zweite Byte
0x3C?
Nein. Die Bytes von Zeichen oberhalb von Codepoint 127 haben immer einen Wert oberhalb von 0x80.
dedlfix.
Hallo und guten Abend,
Welche Bytefolge haben ein ä, ö, ü, Ä, Ö, Ü in utf-8 codiert?
Dafür gibt es genügend Tabellen und Tools.
Oh bitte bitte , auf den Knien flehend...
Einen Link bitte auf eine vernünftige Tabelle.
Oh, vielen vielen Dank Massa.
Grüße
TS
Servus!
Dafür gibt es genügend Tabellen und Tools.
Oh bitte bitte , auf den Knien flehend...
Einen Link bitte auf eine vernünftige Tabelle.
im Wiki: Latin1-ergänzung
sonstwo: UTF-8-Codetabelle mit Unicode-Zeichen
Oh, vielen vielen Dank Massa.
keine Ursache Memsahib! (hoffentlich waren es die richtigen Tabellen?)
Grüße
TS
Herzliche Grüße
Matthias Scharwies
Hallo und guten Abend,
im Wiki: Latin1-ergänzung
sonstwo: UTF-8-Codetabelle mit Unicode-Zeichen
Oh, vielen vielen Dank Massa.
keine Ursache Memsahib! (hoffentlich waren es die richtigen Tabellen?)
Das ging zumindest schon mal in die richtige Richtung
Das Ganze dreht sich darum, dass mittels PHP preg_match() diverse Header von diversen Webseiten ausgelesen werden. Leider weiß man am Anfang nie, in welcher Kodierung die Seiten vorgehalten werden. Und dann weiß man als nächstes leider auch nicht, ob die Angaben des Servers (http-Header) zu denen des Inhaltes ("meta http-equiv" und weitere) und dann auch zur tatsächlichen Kodierung des Inhaltes passen.
Meistens tauchen da auch noch HTML-Entities auf.
In der Datenbank sollen nachher aber nur gültige Werte in utf8 kodiert stehen. ächz
Liebe Grüße vom Berg
TS
Hallo TS,
In der Datenbank sollen nachher aber nur gültige Werte in utf8 kodiert stehen. ächz
Das kannst du nicht sicherstellen.
Bis demnächst
Matthias
Hallo und guten Abend,
In der Datenbank sollen nachher aber nur gültige Werte in utf8 kodiert stehen. ächz
Das kannst du nicht sicherstellen.
Das Thema kam hier schon mal vor.
Mittels "View & Replace" kamen aber immer wieder dieselben Sequenzen vor, die dann ersetzt werden konnten.
Das widerspricht zwar dem Grundsatz "Daten sind unantastbar", aber ich betreibe hier quasi praktische Datenarachäologie. Ich bemühe mich, vergurkte Datenbestände wieder nutzbar zu machen. Das erinnert mich ein wenig an meinen Deutschunterricht, in dem wir die erste und zweite Lautverschiebung (und ihre mögliche Umkehr) kennengelernt haben.
Grüße
TS
hi,
Das Ganze dreht sich darum, dass mittels PHP preg_match() diverse Header von diversen Webseiten ausgelesen werden. Leider weiß man am Anfang nie, in welcher Kodierung die Seiten vorgehalten werden.
Das steht im Response-Header Content-Type.
Und dann weiß man als nächstes leider auch nicht, ob die Angaben des Servers (http-Header) zu denen des Inhaltes ("meta http-equiv" und weitere) und dann auch zur tatsächlichen Kodierung des Inhaltes passen.
Ich würde die Daten betreff Kodierung so verarbeiten und ggf. auch Speichern, wie es im gesendeten Content-Type deklariert ist. Wie ich hier schon vor ein paar Jahren mal gezeigt habe, ist es problemlos möglich, in eine Seite, die UTF-8-kodiert ausgeliefert wurde, per Ajax ISO-8859-1 kodierte Texte einzubauen. Beispiel ist der Golem-Feed auf meiner Site. MfG
Das Ganze dreht sich darum, dass mittels PHP preg_match() diverse Header von diversen Webseiten ausgelesen werden. Leider weiß man am Anfang nie, in welcher Kodierung die Seiten vorgehalten werden.
Das steht im Response-Header Content-Type.
Kann. Sollte auch, muss aber nicht.
Das Ganze dreht sich darum, dass mittels PHP preg_match() diverse Header von diversen Webseiten ausgelesen werden. Leider weiß man am Anfang nie, in welcher Kodierung die Seiten vorgehalten werden.
Das steht im Response-Header Content-Type.
Kann. Sollte auch, muss aber nicht.
Kann man aber lernen es so zu machen ;)
Das Ganze dreht sich darum, dass mittels PHP preg_match() diverse Header von diversen Webseiten ausgelesen werden. Leider weiß man am Anfang nie, in welcher Kodierung die Seiten vorgehalten werden.
Das steht im Response-Header Content-Type.
Kann. Sollte auch, muss aber nicht.
Kann man aber lernen es so zu machen ;)
Sicher. Der OP hat aber zu verstehen gegeben, dass aus einer heterogenen Masse aus Fremdseiten crawlen und normalisieren möchte. In dem Kontext ist "Das steht im Response-Header Content-Type." falsch.
Sicher. Der OP hat aber zu verstehen gegeben, dass aus einer heterogenen Masse aus Fremdseiten crawlen und normalisieren möchte. In dem Kontext ist "Das steht im Response-Header Content-Type." falsch.
Ja und was machen wir denn da wenn es der Header nicht hergibt? Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist! Das heißt für die Praxis, dass das was der Header hergibt so oder so eine Annahme ist die wir zunächst und grundsätzlich immer treffen müssen wenn wir überhaupt weiterkommen wollen.
Das hat was damit zu tun, dass Informationen von Drittanbietern als nicht vertraulich einzustufen sind. Von daher ist es unsinnig, vor dem Speichern solcher Daten eine Umkodierung vorzunehmen.
Aber wahrscheinlich musst Du solche Erfahrungen ersteinmal selber machen.
MfG
Sicher. Der OP hat aber zu verstehen gegeben, dass aus einer heterogenen Masse aus Fremdseiten crawlen und normalisieren möchte. In dem Kontext ist "Das steht im Response-Header Content-Type." falsch.
Ja und was machen wir denn da wenn es der Header nicht hergibt? Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist!
Neee. Falsch. Wenn der Header nix sagt, gucken wir zunächst im Markup, ob dort eine Kodierungsangabe vorliegt. So, wie der Client (Browser, Google...) das ja auch macht. Das ist bei dem Job der Maßstab.
Das heißt für die Praxis, dass das was der Header hergibt so oder so eine Annahme ist die wir zunächst und grundsätzlich immer treffen müssen wenn wir überhaupt weiterkommen wollen.
Nö. Sollte weder Header noch Metatag gesetzt sein, kommt Dein "Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist! " zum Einsatz. Also in gewisser Weise raten, was aber, wenn man es vernünftig macht, eine recht gute Trefferquote bringen sollte.
Das hat was damit zu tun, dass Informationen von Drittanbietern als nicht vertraulich einzustufen sind.
Finde ich in dem Kontext etwas prätentiös formuliert, aber ok.
Von daher ist es unsinnig, vor dem Speichern solcher Daten eine Umkodierung vorzunehmen.
Wenn ich heterogenen Input in verschiedenen Kodierungen zentral speichern möchte, scheint mir das weniger unsinnig, sondern eher eine verdammt gute Idee zu sein. Womöglich das Original zusätzlich(!) noch speichern, um bei etwaigen Kandidaten, bei denen sich "falsch geraten" herausstellt, nochmal nachbessern zu können.
Aber wahrscheinlich musst Du solche Erfahrungen ersteinmal selber machen.
Ich war in Stochastik auch nie so dolle, lieber Vektorrechnung.
Hallo und guten Tag,
Wenn ich heterogenen Input in verschiedenen Kodierungen zentral speichern möchte, scheint mir das weniger unsinnig, sondern eher eine verdammt gute Idee zu sein. Womöglich das Original zusätzlich(!) noch speichern, um bei etwaigen Kandidaten, bei denen sich "falsch geraten" herausstellt, nochmal nachbessern zu können.
Das halte ich für eine gute Anregung!
Ohne manuelle Nacharbeit wird es vermutlich nie gehen. Es stehen ja auch immer wieder HTML-Entities drin, die dann bei der konsequenten Weiterverarbeitung auch wieder doppelt für den HTML-Kontext kodiert werden, also dann deren Kodierung sichtbar gemacht wird (dargestellt wird).
Grüße
TS
@@Mitleser
Neee. Falsch. Wenn der Header nix sagt, gucken wir zunächst im Markup, ob dort eine Kodierungsangabe vorliegt. So, wie der Client (Browser, Google...) das ja auch macht. Das ist bei dem Job der Maßstab.
Neee. Falsch. Bevor wir in den Header gucken, gucken wir zuerst im Markup, ob dort eine Kodierungsangabe vorliegt – in Form eines BOM. Bei vorhandenem BOM ist das der Maßstab.
LLAP 🖖
Neee. Falsch. Wenn der Header nix sagt, gucken wir zunächst im Markup, ob dort eine Kodierungsangabe vorliegt. So, wie der Client (Browser, Google...) das ja auch macht. Das ist bei dem Job der Maßstab.
Neee. Falsch. Bevor wir in den Header gucken, gucken wir zuerst im Markup, ob dort eine Kodierungsangabe vorliegt – in Form eines BOM. Bei vorhandenem BOM ist das der Maßstab.
Stimmt, hatte ich gerade nicht auf der Mattscheibe. BOM hasse ich allerdings, vielleicht daher verdrängt.
Hallo und guten Tag Hotti,
Ja und was machen wir denn da wenn es der Header nicht hergibt? Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist!
Dafür haben wir uns ja früher schon mal seems_utf8() gebastelt. ;-P
War auch eine Idee von mir, auch wenn Andere es dann schlussendlich zur Perfektion gebracht haben. Muss ich mir doch jetzt mal selber auf die Schulter klopfen :-P
Ich bastel jetzt noch eine Funktion für MySQL nebst Tabelle. Die meisten Vorkommen von Fremdkodierungen lassen sich in utf-8-Kontext gut erkennen und sinngemäß ersetzen...
Grüße
TS
hi Tom,
Ja und was machen wir denn da wenn es der Header nicht hergibt? Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist!
Dafür haben wir uns ja früher schon mal
seems_utf8()gebastelt. ;-P
Na also, Du bist ja doch auf dem richtigen Weg. In Perl würde man eine Schablone auf die Bytesequenz legen und prüfen ob sie passt. In Fakt definiert die UTF-8-Kodierung ja Bytes die nicht aufeinanderfolgen dürfen -- genau das ist das Prüfkriterium.
Zum Speichern fremder Inhalte würde ich die jedoch nicht umkodieren, Du weißt ja nie wann der Anbieter die Kodierung mal ändert.
Guten Rutsch ;)
Hallo und guten Tag,
Ja und was machen wir denn da wenn es der Header nicht hergibt? Genau: Wir treffen eine bestimmte Annahme und prüfen ob die richtig ist!
Dafür haben wir uns ja früher schon mal
seems_utf8()gebastelt. ;-PNa also, Du bist ja doch auf dem richtigen Weg.
Eben noch nicht! Denn ich würde es gerne datenbankintern regeln und MySQL untersützt mich dabei nicht sonderlich gut...
Guten Rutsch ;)
Das soll übrigens aus dem Hebräischehn komnmen und hieß ursprünglich Rosch ha schana tov mit der freien Übersetzung einen guten Jahresanfang.
Dir und allen anderen Forumsteilnehmern wünsche ich jedenfalls auch einen guten Jahresanfang 2017 und dass auch das ganze Jahr nach euren besten Wünschen verläuft.
Vielleicht schaffe ich dann ja endlich mal, den illegalen Geheimdienst der SPD zu entlarven. Den alten Stasi-Akten sein Dank! Seit 17 Jahren spielt er mir übel mit!
Sollte mein Haus also über den Jahreswechsel abbrennen oder mir sonst irgend etwas negatives wiederfahren, bitte ich um entsprechende Nachforschungen.
Grüße
TS
@@TS
Guten Rutsch ;)
Das soll übrigens aus dem Hebräischehn komnmen und hieß ursprünglich
Rosch ha schana tovmit der freien Übersetzungeinen guten Jahresanfang.
Warum zeichnest du das als Code aus?
Und in einem Thread, wo es um Unicode geht, kann man das auch richtig™ schreiben: ראש השנה טוב. ;-)
Vielleicht schaffe ich dann ja endlich mal, den illegalen Geheimdienst der SPD zu entlarven. Den alten Stasi-Akten sein Dank!
Willst du nicht das Aufstellen von Verschwörungstheorien Hotti überlassen?
LLAP 🖖
Hmm,
Guten Rutsch ;)
Das soll übrigens aus dem Hebräischehn komnmen und hieß ursprünglich
Rosch ha schana tovmit der freien Übersetzungeinen guten Jahresanfang.
Und ich dachte immer das kommt vom Rutschen...
Vielleicht schaffe ich dann ja endlich mal, den illegalen Geheimdienst der SPD zu entlarven.
Die ganze Partei gehört verboten.
Den alten Stasi-Akten sein Dank! Seit 17 Jahren spielt er mir übel mit!
Die heutige Parteien und Medienlandschaft leidet an derselben Krankheit an der letztendlich auch die DDR gestorben ist.
MfG
nochmal anders gefragt:
Welche Bytefolge haben ein ä, ö, ü, Ä, Ö, Ü in utf-8 codiert?
Hier gucken das zeigt Dir alles vom Codepoint über den Namen des Zeichens bis zur Bytefolge.
MfG
Hallo und guten Abend,
noch eine Frage zur Konvertierung:
Wie konvertiere ich innerhalb eines UTF-8-Kontextes (der Editor arbeitet als gerade mit UTF-8) eine Sequenz, die sich auch hier als ✔` darstellt in gültiges utf-8, möglichst mit der Bytes-Repräsentation (E2 9C 94)?
Danke untertänigst für zielführende Hinweise oder sogar Soforthilfe ;-O
Grüße
TS
@@TS
Wie konvertiere ich innerhalb eines UTF-8-Kontextes (der Editor arbeitet als gerade mit UTF-8) eine Sequenz, die sich auch hier als ✔` darstellt in gültiges utf-8, möglichst mit der Bytes-Repräsentation (E2 9C 94)?
Was genau ist dein Problem?
Du konvertierst die Dezimalzahl 10004 in ihre Hexadezimal- bzw. Binärdarstellung. Kann der Taschenrechner deines OS.
Die Wikipedia-Seite zu UTF-8 war bereits verlinkt; darin findest du den Algorithmus.
Und wenn du nun verstanden hast, wie’s geht, kannst du auch Richard Ishidas Unicode code converter verwenden.
LLAP 🖖
Hallo und guten Tag Gunnar,
Was genau ist dein Problem?
Du konvertierst die Dezimalzahl 10004 in ihre Hexadezimal- bzw. Binärdarstellung. Kann der Taschenrechner deines OS.
Jetzt halte bitte mal sie Füße still. Spiel lieber Gitarre! ;-P
Es gibt da noch Erscheinungen in Zusammenhang mit preg_match() von PHP, die ich noch nicht durchschaue, obwohl ich bereits eine scheinbar funktionierende Lösung gefunden habe. Daher auch die Frage nach den Bytewerten. Da wird ein "<" erkannt, wo keines ist!
Grüße
TS
@@TS
Jetzt halte bitte mal sie Füße still. Spiel lieber Gitarre! ;-P
Du kannst die Antwort auch gerne als Minnesang haben. Vorher tanzt du bitte deine Frage.
LLAP 🖖
Hallo und guten Morgen,
@@TS
Jetzt halte bitte mal sie Füße still. Spiel lieber Gitarre! ;-P
Du kannst die Antwort auch gerne als Minnesang haben. Vorher tanzt du bitte deine Frage.
Alles klar. Ich übe schonmal und trinke mir über den Jahreswechsel die passende Torkelstärke an ;-)
Deinen Tipp habe ich gerade vorgeschlagen für die Linkliste im Wiki. Mal sehen, ob sich damit überhaupt jemand beschäftigt :-O
Grüße
TS
Hallo TS,
Deinen Tipp habe ich gerade vorgeschlagen für die Linkliste im Wiki. Mal sehen, ob sich damit überhaupt jemand beschäftigt :-O
schon gesehen. Wer ist jemand?
Bis demnächst
Matthias
Hallo @TS hallo @Matthias Apsel
Deinen Tipp habe ich gerade vorgeschlagen für die Linkliste im Wiki. Mal sehen, ob sich damit überhaupt jemand beschäftigt :-O
schon gesehen. Wer ist jemand?
Jeder kann im Wiki mitarbeiten.
Ich habe den Link aufgenommen, dabei die bestehden Links zum Thema in Zeichenkodierung/Links zusammengefasst und sowohl in Zeichenkodierung als auch der Linkliste eingebunden.
Was halbwegs zum Thema passt, hat jetzt die Kategorie Zeichenkodierung.
@TS Zumindest den Link hättest du auch selbst einfügen können. Anstelle der Diskussionseiten wollten wir Vorschläge für's Wiki im Forum diskutieren.
@Matthias Apsel Zumindest den Link hättest du auch selbst einfügen können, als du die Diskussionsseite aufgeräumt hast.
Euch beiden einen guten Rutsch ins neue Jahr und dass alle eure Wünsche in Erfüllung gehen!
Matthias Scharwies
Hallo Matthias Scharwies,
@Matthias Apsel Zumindest den Link hättest du auch selbst einfügen können, als du die Diskussionsseite aufgeräumt hast.
In der Linkliste habe ich keine passende Stelle gefunden.
Bis demnächst
Matthias
