Pregătești
Alegi conținutul codului sau fișierul pe care vrei să îl transmiți.
Instrumente în browser Instrument public
MEGA QR include un generator de coduri și un instrument de transfer optic. Creezi un cod pentru link, Wi-Fi sau contact; pentru transfer, un ecran afișează o succesiune de coduri pe care camera celuilalt dispozitiv le reconstruiește într-un fișier.

MEGA QR
Alegi conținutul codului sau fișierul pe care vrei să îl transmiți.
Generatorul produce imaginea QR. Transferul optic afișează cadre succesive.
Camera citește codul sau adună cadrele până când poate reconstrui fișierul.
Link, Wi-Fi, contact și alte tipuri de conținut; export PNG sau SVG.
Date transmise între ecran și cameră, fără o conexiune de rețea între dispozitive.
Generarea și reconstrucția se fac în browser, fără un cont de utilizator.
Transferul optic depinde de cameră, lumină, distanță și ecran. Dispozitivul care transmite nu primește confirmarea recepției. Un cod afișat public poate fi citit de cei care îl văd.
MEGA QR în detaliu
MEGA QR sunt două instrumente pe același domeniu, iar al doilea nu seamănă deloc cu primul. Generatorul face coduri QR pentru opt tipuri de conținut: link, text, WiFi, carte de vizită, WhatsApp, email, SMS, telefon și coordonate. Transferul optic mută un fișier întreg de pe un ecran pe o cameră, fără cablu, fără Bluetooth, fără rețea între cele două dispozitive.
Amândouă rulează integral în browser. Paginile nu fac nicio cerere către terți, iar cele două binare WebAssembly de care depinde transferul sunt servite din public/wasm/, nu de pe un CDN — altfel promisiunea că nimic nu pleacă de pe dispozitiv ar fi falsă. O parolă de WiFi tastată în generator nu ajunge niciodată pe un server.
Ideea pe care merită să o înțelegi despre transfer: un ecran emite lumină, o cameră o citește, și receptorul nu are cum să ceară nimic înapoi. Nu există canal de retur. Din faptul acesta decurge tot restul — cadrele se descriu singure, ordinea lor nu contează, orice submulțime suficient de mare reconstruiește fișierul, iar expeditorul nu poate ști niciodată dacă a ajuns ceva.
Link, text, WiFi, vCard, WhatsApp, email, SMS, telefon și geolocalizare. Când pui un logo, nivelul de corecție a erorilor trece forțat pe H, cel mai înalt — un logo face o gaură în zona de date și codul nu supraviețuiește altfel. Logoul e plafonat la 35% din suprafață, cu avertisment de la 30%. Exportul se randează separat de previzualizare, ca un PNG de 4096 px să nu perturbe ce e pe ecran.
Biblioteca de generare, qr-code-styling 1.9.2, își convertește textul cu charCodeAt(i) & 0xFF și taie tăcut fiecare diacritică românească și tot chirilicul: „Ștefan Țurcanu” se scana înapoi ca „tefan urcanu”. Codificăm noi în UTF-8 înainte s-o vadă, astfel încât trunchierea ei să nu mai aibă ce tăia. Payload-urile WiFi și vCard sunt și ele escapate — un „;” într-o parolă sau o virgulă într-un nume de firmă corupeau altfel codul, fără niciun semn.
Fișierul e împachetat într-un plic (nume, tip MIME, mărime, SHA-256), comprimat cu gzip dacă iese mai mic, apoi dat pe RaptorQ (RFC 6330). Fiecare cadru poartă un antet fix de 20 de octeți și unul sau mai multe pachete. Nu contează care cadre prinzi, contează câte: orice submulțime suficient de mare reconstruiește fișierul. Măsurat prin pixeli randați real, supraîncărcarea RaptorQ e 1,000x — codurile LT pe care le folosesc proiectele de referință cer 1,15x.
Al doilea mod de trimitere e o tură fixă care se repetă la nesfârșit, fără sesiune și fără cineva care să apese start. Lungimea turei călătorește în fiecare cadru, așa că un trecător care îndreaptă camera știe din primul cod prins cât durează totul, în loc să vadă o rotiță. Configurația de referință e 36 de cadre la 12 pe secundă — o tură de trei secunde care duce 25 KB dintr-un singur cod alb-negru simplu. Un meniu întreg, sau orarul complet al unei stații.
Numărul de coduri pe ecran, culoarea și versiunea QR sunt trei limitări diferite și se reglează separat. Scara de densitate are 29 de trepte, de la v10 pe o singură bandă (7 KB/s la 30 de cadre pe secundă) până la v39 pe patru benzi în culoare (959 KB/s). Există și o scară completă fără culoare, până la 320 KB/s, pentru că o cameră căreia îi moare crominanța nu trebuie să rămână blocată pe o singură bandă.
Date și funcționare
De la explorare la implementare
Un cod QR duce la conținut scurt și, dacă e un link, la o pagină pe care o poți schimba ulterior — codul tipărit nu-și schimbă singur destinația. Transferul optic mută un fișier între două dispozitive care nu au voie sau nu pot să comunice prin rețea. Sunt sarcini diferite și confuzia dintre ele e cea mai frecventă.
Pentru tipar: contrast, dimensiune finală, zonă liberă în jur, testat la mărimea la care va fi lipit. Pentru transfer: cât de mare cade un modul pe senzorul camerei. Sub un model dur de lentilă (grilă de crominanță decalată cu un pixel plus o neclaritate 3x3) culoarea întoarce toate cele trei coduri la 4 pixeli de dispozitiv per modul și absolut nimic la 2. Aceea e granița reală, și de aceea culoarea e alegerea omului, nu a controlerului.
Suita noastră trece un lanț de camere autentic — cadrele sunt scrise ca YUV 4:2:0 și date lui Chrome ca webcam fals, deci subeșantionarea crominanței e reală. Ce nu are: obiectiv, reflexii, mișcare, obturator rulant. Zece minute cu un telefon adevărat dau prima cifră onestă și sunt pasul următor din lista noastră de lucru, nu un detaliu.
Printr-un lanț de cameră simulat, la 10 cadre pe secundă, cu codurile umplând cea mai mare parte a imaginii la 3-5 pixeli de cameră per modul, toate cele patru configurații au ieșit cu hash verificat: alb-negru pe o bandă 15,8 KB/s, alb-negru pe patru benzi 37,7 KB/s, culoare pe o bandă 40,1 KB/s, culoare pe patru benzi 115,7 KB/s. Culoarea pe o singură bandă bate alb-negrul pe patru. Rata de ratare a fost zero peste tot. Reține de unde vin cifrele: cadre geometrice perfecte, fără obiectiv și fără mișcare. Un telefon adevărat nu a fost încă pus în fața lor.
Camera e cerută la 1920x1080 la 30 de cadre pe secundă, cu preferință pentru cea din spate; dacă Android refuză constrângerea, cădem pe orice cameră. Fiecare cadru capturat e redus la 1280 px pe latura lungă înainte de decodare. Ce contează cu adevărat nu e rezoluția, ci câți pixeli de senzor cad pe un modul: alb-negrul are nevoie de aproximativ trei, culoarea de aproximativ dublu, pentru că lanțul video al telefonului livrează de obicei 4:2:0 și înjumătățește ambele planuri de culoare în ambele direcții. Detaliul fin de culoare e primul lucru pe care o cameră reală îl distruge.
Pentru că singurul lucru pe care dispozitivul care trimite îl poate măsura e câte simboluri au produs propriile lui codificatoare față de câte i s-au cerut — o afirmație despre un procesor, nu despre o cameră aflată la două palme. Un laptop nu ratează niciodată o treaptă, deci un controler care citește „zero ratări” ca „mai dă-i drumul” urcă până în vârf și pune pe ecran patru coduri care se schimbă de treizeci de ori pe secundă, pe care nimic nu le poate scana. Asta chiar s-a livrat o dată și un om a găsit-o într-un minut. Acum modul automat e plafonat la o bandă, alb-negru, versiunea 26 și 15 cadre pe secundă. 15 nu e o cifră rotundă: o cameră de telefon înregistrează la 30 și nu e sincronizată cu ecranul, deci un cadru trebuie să stea afișat două expuneri consecutive — 67 ms — ca să fie prins întreg.
Nimic special, și asta e tot rostul. Nu există numere de ordine de recuperat. Codificatorul produce pachete de reparație în proporție de 2x față de simbolurile sursă — măsurat pe acest cod: la 60% pierdere de cadre, un set de aproximativ 2x K recuperează 2 MB fără ca lista să fie redată vreodată a doua oară. Plafonul absolut e 60.000 de pachete; peste el expeditorul pur și simplu reia lista mai des, ceea ce costă timp, nu memorie. Dacă totuși ceva iese greșit, hash-ul SHA-256 prinde asta și transferul eșuează declarat în loc să livreze un fișier corupt.
Nu, și nu e o scăpare. Nu există canal de retur — un ecran emite lumină, iar lumina nu se întoarce cu confirmări. Finalizarea se vede pe dispozitivul care recepționează. Orice interfață care ar pretinde altceva ar minți, și am avut deja o dată un test care oferea exact această dovadă pe care produsul n-o are niciodată: simularea își calcula rata de ratare din ce reușea camera simulată să rezolve. Aceea e un canal de retur. Când un test și codul livrat nu sunt de acord asupra a ce se poate ști, testul e cel care minte.
32 MB, refuzat la selecție dacă e mai mare. Limita nu vine din protocol, ci din memoria unei file de browser: RaptorQ materializează toate pachetele deodată, iar un fișier de 50 MB la raport 2x ar însemna 150 MB de tablouri vii, suficient cât să omoare fila unui telefon. Codificarea rulează sincron pe firul principal, măsurată la 2,5 secunde pentru 32 MB pe calculator. Ce călătorește efectiv nu e mărimea fișierului: plicul e comprimat cu gzip înainte de RaptorQ, deci un tabel de 1 MB e câteva kilooctete de pachete, iar o fotografie de 1 MB e un megaoctet de pachete.
Nici, nici. Nu există cont și nu există abonament. După prima vizită paginile funcționează fără rețea, pentru că totul — inclusiv cele două binare WebAssembly — e servit din propriul domeniu. Merită spus și ce am învățat pe drum: un service worker înregistrat nu înseamnă suport offline. La prima încărcare pagina și resursele ei sunt aduse înainte ca workerul să preia controlul, deci handlerul lui nu le vede niciodată. Pagina își raportează propriile resurse prin Performance API în loc să presupună.
Exemplu ilustrativ
Un scenariu de utilizare, fără date de client sau rezultate comerciale atribuite.
Un ecran într-o stație sau o vitrină trebuie să dea trecătorilor un fișier — orarul complet, meniul, un formular — fără WiFi public, fără cont și fără ca cineva să apese ceva.
Ecranul rulează un carusel: 36 de cadre la 12 pe secundă, o tură de trei secunde care se repetă la nesfârșit. Densitatea e fixă pe durata caruselului, pentru că o tură e o promisiune doar dacă lungimea ei se ține. Lungimea turei călătorește în fiecare cadru, așa că un telefon care prinde primul cod știe imediat cât durează totul.
Trecătorul filmează trei secunde și primește 25 KB reconstruiți în browserul lui, verificați cu SHA-256, dintr-un singur cod alb-negru simplu. Ecranul nu află că a fost citit și nu are cum.
Ce este necesar:Un ecran care poate ține un cadru afișat 83 ms fără sfâșiere, lumină în care codul nu e spălat de reflexii, și o cameră care rezolvă aproximativ trei pixeli de senzor per modul. Cifra de 25 KB e derivată din aceleași funcții pe care le folosește expeditorul, nu tastată de mână alături de ele.
Posibilități de colaborare
Coduri pentru acces la informații publice, instrucțiuni sau contacte; transfer optic de fișiere între dispozitive compatibile, cu evaluarea politicilor de securitate ale instituției.
Definim un pilot în jurul unui proces real: utilizatori, date, integrări, costuri și criterii de acceptare. Extinderea urmează după evaluarea rezultatului.
Stabilim cerințele de accesibilitate, găzduire, protecție a datelor și interoperabilitate. Orice conexiune cu servicii AGE sau STISC necesită validarea eligibilității, accesului și aprobărilor.
Acestea sunt scenarii de adaptare, nu declarații despre contracte sau parteneriate existente. Funcțiile propuse se confirmă în domeniul de lucru al proiectului.
Discută un pilotonGDPR.md verifică suprafața publică a unui website: cookie-uri, trackere, formulare și documente de informare.
Platformă publicăMegaforms explorează colectarea de răspunsuri prin formulare conversaționale, inclusiv răspunsuri vocale și transcriere.
Dezvoltare & demonstrațiiConstruim o platformă pentru meniuri digitale și operațiuni accesibile prin QR.
Dezvoltare & demonstrațiiPovestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.