Für die Anwendung von RegEx liegt meine ganze Hoffnung auf KI.
Für die Anwendung von RegEx liegt meine ganze Hoffnung auf KI.
Verstand op nul, frituur op 180.
Frage:
Antwort:Schreibe eine RegEx für ein Passwort mit mindestens 12 Zeichen, das Groß- und Kleinbuchstaben und Sonderzeichen enthält
Eine mögliche reguläre Ausdrucksregel (Regex) für ein Passwort, das mindestens 12 Zeichen enthält und Groß- und Kleinbuchstaben sowie Sonderzeichen erfordert, könnte wie folgt aussehen:
Erklärung der einzelnen Teile des Regex:PHP-Code:
regex
^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[^\da-zA-Z]).{12,}$
- `^` - Steht für den Beginn des Strings.
- `(?=.*[a-z])` - Positive Lookahead-Assertion, um sicherzustellen, dass mindestens ein Kleinbuchstabe vorhanden ist.
- `(?=.*[A-Z])` - Positive Lookahead-Assertion, um sicherzustellen, dass mindestens ein Großbuchstabe vorhanden ist.
- `(?=.*\d)` - Positive Lookahead-Assertion, um sicherzustellen, dass mindestens eine Ziffer vorhanden ist.
- `(?=.*[^\da-zA-Z])` - Positive Lookahead-Assertion, um sicherzustellen, dass mindestens ein Sonderzeichen vorhanden ist. `\d` steht für Ziffern, `a-zA-Z` für Buchstaben. `[^\da-zA-Z]` sucht nach einem Zeichen, das weder eine Ziffer noch ein Buchstabe ist.
- `.{12,}` - Steht für mindestens 12 beliebige Zeichen.
- `$` - Steht für das Ende des Strings.
Dieser Regex prüft, ob das Passwort die angegebenen Anforderungen erfüllt.
Das geht doch deutlich schneller als das zu Fuß zu konstruieren.
Es wäre nur noch wünschenswert, dass man sich darauf auch verlassen kann.
Verstand op nul, frituur op 180.
Hat jemand eine Idee bei einer Git-Frage
Ich kann beim Civ4 pbmod-Projekt meine Änderungen nicht mehr bei Github in den master-branch pushen. Der Befehl terminiert nicht und ich muss den Prozess mit Clt+C beenden.
Klone ich das pbmod-Repo aber in eine zweite lokale Kopie und pushe meine Änderungen in die neue Kopie funktioniert das ohne Fehlermeldung
unreferenzierte Daten würde ich mit früherem Löschen von Branches oder rebase-Operationen in Verbindung bringen.Code:git fsck --full Prüfe Objekt-Verzeichnisse: 100% (256/256), fertig. Prüfe Objekte: 100% (7001/7001), fertig. blob 7e83a44933d8c78f6d9a8b5aa8096b8e4f11824f unreferenziert blob 38076ee2ca95ab250cd5eeec82ae2d6caed10f38 unreferenziert tree c78f37f032959988e95dbbba11d5940bd0dcfae8 unreferenziert blob a5140e70b6f5f740f109bd893cb6220f3846f83f unreferenziert blob 90248c676643a1116856f79619d29ea624292433 unreferenziert blob c5a5ad3d71deb4ddd85110d173db6e5e74d2aa5e unreferenziert blob 7cabba5497e657757d8724aa6273324a1012f247 unreferenziert blob 3f35d56ffb53c222c3514a6ef71caba642404b72 unreferenziert blob 0cb92506fac1857a238b7a7cd813625b8cccb348 unreferenziert blob e04b9a14ad311e9db8c69e5079caf6c287dfd0fa unreferenziert blob fa71cc5295788f75f6eb7932b32d0e0203f6ed42 unreferenziert tree 9c735674413e3aa8f7550a9a856a8bd05539983d unreferenziert > .../software/Civ4/pbmod/CvGameCoreDLL$ git remote -v origin https://github.com/civ4-mp/pbmod (fetch) origin https://github.com/civ4-mp/pbmod (push) test /dev/shm/pbmod (fetch) test /dev/shm/pbmod (push)
Ach ja: Die letzte Aktion vor dem Problem war ein rebase, damit ich lokale Änderungen auf den origin/master-Knoten packe.
Sieht jetzt nicht unbedingt sehr kaputt aus. Evtl. ist noch etwas härter mit dem Dateisytem kaputt. Du kannst ja mal ein `strace` vor's git push werfen und schauen ob es irgendeine file operation (open, write, ...) ist die da hängt.
Achtung Spoiler:
Ich habe die Lösung gefunden. Git push mit -v zeigte beim Übertragen POST git-receive-pack (chunked). Ich verwende bei Github die https-Syntax für die Quell-Repos und „große Dateien“ will git splitten, was fehlschlägt. Da ich seit dem letzten Push Manjaro und den Internetanschluss verändert habe, kommt dass auch noch in Frage für dieses Netzwerkproblem. Das wollte ich aber nicht weiter untersuchen.
Als Workaround habe ich in den Einstellungen den Buffer hochgesetzt, ab dem gesplittet werden würde.
Danach ging der Push durch (POST git-receive-pack (1148371 bytes))Code:git config http.postBuffer 5242000
Weis jemand wie ich für ein Dokument dauerhaft das Makro akzeptieren kann?
Hintergrund:
Ich nutze aktuell Makros die nicht auf meinem PC geschrieben wurden sondern auf einem ArbeitsPC. Wenn ich diese Dokumente daheim öffne wegen 3 Tage/Woche Homeoffice, meckert er erst normal wegen Makro. Ich sage aktivieren. Dann kommt die rote Meldung wegen Sicherheitsrisiko da Macro aus externer Quelle (logisch, ich habs mir ja per Dienstmail-Adresse selbst geschickt). Wenn ich diese rote Meldung über Explorer, Dateiname, rechtsklick, Einstellungen, und dann Sicherheit und zulassen quasi ausdrücklich zulasse, kann ich das Dokument öffnen. ABER zu dem Zeitpunkt hat Excel oder Windows bereits das Makro gelöscht oder irgendwohin verschoben.
Also Datei neu aus dem Anhang dowloaden, Einstellungen ändern und erst dann öffnen. Dann arbeite ich damit, kann das Dokument öffnen und schließen wie ich will und auch die Macros verändern. SObald ich den PC dann aber runterfahre und am nächsten Morgen wieder einschalte, bringt er wieder das Sicherheitsrisiko wegen externer Quelle. Er merkt sich die Einstellungen nicht und ignoriert auch das ich das Dokument gespeichert, verändert, etc habe. Selbst wenn ich unter anderem Namen speicher. Was dazu führt das beim öffnen ohne daran zu denken wieder alle Makros und damit das gesamte Dokument im A*** ist.
Wenn ich das Dokument meinem Bruder, Arbeitskollegen oder Vater zuschicke haben die das Problem nicht. Wir haben Sicherheitseinstellungen, etc schon vergleichen. War alles gleich. Weis jemand wie ich das los werde? Oder wie Windows sich das merkt, das ich der Datei "grünes Licht" gegeben habe und mit ihr arbeite und auch das Marco verändert habe?
Ich bin Legastheniker. Wer also Rechtschreibfehler oder unklare Formulierungen findet, darf sie gerne behalten :)
Ich nutze in allen meinen Beiträgen grundsätzlich die in meinen Augen geschlechtsneutrale Bezeichnung, sofern ich keinen konkretes Objekt oder eine Person meine. So sind Äußerungen wie DER Lehrer oder DIE Krankenschwester oder DER Pfleger lediglich Berufsbezeichnungen und daher geschlechtsneutral in meinen Augen, ebenso wie DER Mond oder DIE Sonne.
Irgendwie habe ich gerade Tomaten auf den Augen?! Warum entspricht der Zugriff auf Speicher in Array-Schreibweise ( dPi[-1]) nicht der per Pointer-Schreibweise ( *(dPi-1) ) ?!
Code:// Start des Arrays (gdb) print(data) $18 = (const uint8_t *) 0x55555555f2a0 "" (gdb) print(data[0]) $20 = 0 '\000' // Schrittweite ist eins und aktueller Pointer ist ein Byte hinter data (gdb) print(stepwidth) $21 = 1 (gdb) print(dPi) $22 = (const uint8_t *) 0x55555555f2a1 "" (gdb) print(dPi-stepwidth) $16 = (const uint8_t *) 0x55555555f2a0 "" // Ok (gdb) print(*(dPi-stepwidth)) $15 = 0 '\000' // Fails (gdb) print(&dPi[-stepwidth]) $17 = (const uint8_t *) 0x55565555f2a0 <error: Cannot access memory at address 0x55565555f2a0>
Der Pointer ist eine Zahl, die man beliebig verkleinern kann. Das Array-Argument muss wohl positiv sein. In Python ginge es, weil der Compiler aus -1 len-1 macht.