Skip to content

Generatore di font LCD e OLED (bitmap in array C)

Converti testo cinese o inglese e immagini in array C per SSD1306, SH1106, ST7920 e Adafruit GFX. Font pixel nitidi 12×12 e 16×16, tutte e 4 le modalità di scansione di PCtoLCD2002 e un decoder di array.

Niente tracciamento Funziona nel browser Gratuito
Tutto avviene nel tuo browser: testo e immagini non lasciano mai questo dispositivo.

Compatibile con la memoria a pagine di SSD1306 / SSD1309 / SH1106 / ST7565 e con MicroPython framebuf.MONO_VLSB: scrivi i byte direttamente sul display.

Anteprima

Clicca su un pixel per invertirlo.
    4 glifi · 64 byte
    Riferimento: il carattere 中 (16 × 16) in ogni direzione di scansione

    Pixel acceso = 1, glifo di GNU Unifont. Confronta questi byte con il tuo array per capire con quali impostazioni è stato generato.

    Direzione di scansione Ordine dei bit Byte (hex)
    Riga per riga (byte orizzontali) MSB prima — primo pixel nel bit 7 01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00
    Riga per riga (byte orizzontali) LSB prima — primo pixel nel bit 0 80 00 80 00 80 00 80 00 FC 1F 84 10 84 10 84 10 84 10 84 10 FC 1F 84 10 80 00 80 00 80 00 80 00
    Colonna per colonna (byte verticali) MSB prima — primo pixel nel bit 7 00 00 00 00 0F F0 08 20 08 20 08 20 08 20 FF FF 08 20 08 20 08 20 08 20 0F F0 00 00 00 00 00 00
    Colonna per colonna (byte verticali) LSB prima — primo pixel nel bit 0 00 00 00 00 F0 0F 10 04 10 04 10 04 10 04 FF FF 10 04 10 04 10 04 10 04 F0 0F 00 00 00 00 00 00
    Colonne per pagina (byte verticali, ordine di pagina SSD1306) MSB prima — primo pixel nel bit 7 00 00 0F 08 08 08 08 FF 08 08 08 08 0F 00 00 00 00 00 F0 20 20 20 20 FF 20 20 20 20 F0 00 00 00
    Colonne per pagina (byte verticali, ordine di pagina SSD1306) LSB prima — primo pixel nel bit 0 00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00
    Righe per striscia (byte orizzontali, strisce da 8 pixel) MSB prima — primo pixel nel bit 7 01 01 01 01 3F 21 21 21 21 21 3F 21 01 01 01 01 00 00 00 00 F8 08 08 08 08 08 F8 08 00 00 00 00
    Righe per striscia (byte orizzontali, strisce da 8 pixel) LSB prima — primo pixel nel bit 0 80 80 80 80 FC 84 84 84 84 84 FC 84 80 80 80 80 00 00 00 00 1F 10 10 10 10 10 1F 10 00 00 00 00

    Font pixel: GNU Unifont (16 px) e Fusion Pixel Font (12 px), entrambi con licenza SIL Open Font License 1.1. Testi delle licenze

    Tutte e otto le combinazioni di direzione di scansione e ordine dei bit sono verificate byte per byte rispetto a un'implementazione di riferimento indipendente, e i preset rispetto ai datasheet di SSD1306, SH1106 e ST7565 e al codice sorgente di Adafruit GFX, U8g2, LVGL e MicroPython. — Team Go Tools · Oct 3, 2026

    Realizzato e verificato dal team di ingegneria di Go Tools.

    Risposte rapide

    Quali impostazioni servono per un OLED SSD1306?

    Colonne per pagina · LSB prima Colonne per pagina, LSB prima, pixel acceso = 1, quando scrivi i byte direttamente nella memoria del display.

    Quali impostazioni servono per Adafruit GFX drawBitmap()?

    Riga per riga · MSB prima Riga per riga, MSB prima, pixel acceso = 1, con ogni riga completata a byte interi.

    Quanti byte occupa un carattere 16 × 16?

    32 byte 32 byte in qualsiasi direzione di scansione. Un 12 × 12 occupa 24 byte, un carattere ASCII 8 × 16 ne occupa 16.

    Cosa significano 顺向 e 逆向 in PCtoLCD2002?

    逆向 = LSB prima 顺向 ("verso diretto") = MSB prima (primo pixel nel bit 7); 逆向 ("verso inverso") = LSB prima (primo pixel nel bit 0).

    Che cos'è la bitmap di un font (取模)?

    La maggior parte dei controller grafici OLED e LCD, tra cui SSD1306, SH1106 e ST7565, non ha un font integrato. Per mostrare un carattere, il firmware copia nella memoria del display una piccola griglia di pixel accesi o spenti: un bit per pixel, otto pixel per byte. Trasformare un glifo in quei byte è ciò che i tutorial embedded cinesi chiamano 取模 (letteralmente "ricavare lo stampo" del carattere), il lavoro che il programma Windows PCtoLCD2002 svolge da anni.

    I byte da soli non bastano. Lo stesso carattere 16 × 16 si può impacchettare in quattro modi (riga per riga, colonna per colonna, colonne per pagina, righe per striscia) e ognuno può mettere il primo pixel nel bit 7 o nel bit 0. Otto sequenze di byte descrivono lo stesso glifo, e un display ne disegna correttamente solo una. Ecco perché un font copiato da un tutorial compare così spesso specchiato, spezzato a metà o ruotato.

    // 中 (16x16), pages of columns, LSB first, lit = 1 — SSD1306 page order
    const unsigned char zhong[32] = {
      0x00,0x00,0xF0,0x10,0x10,0x10,0x10,0xFF,0x10,0x10,0x10,0x10,0xF0,0x00,0x00,0x00,
      0x00,0x00,0x0F,0x04,0x04,0x04,0x04,0xFF,0x04,0x04,0x04,0x04,0x0F,0x00,0x00,0x00
    };
    // First 16 bytes = page 0 (rows 0-7), one byte per column, bit 0 = top row

    Cosa fa questo generatore

    Cinese 12 × 12 e 16 × 16 perfetto al pixel

    I font del browser sono contorni con antialiasing: sogliati a 12 px in un carattere Song, i tratti orizzontali di 中 spariscono del tutto. Per questo lo strumento include veri font bitmap: il font 16 × 16 copre tutti i 6.763 caratteri GB2312, mentre a quello 12 × 12 ne mancano 143 rari, che vengono disegnati con un font di sistema e segnalati.

    Tutte e quattro le modalità di scansione di PCtoLCD2002, in entrambi gli ordini dei bit

    Riga per riga, colonna per colonna, colonne per pagina e righe per striscia, ciascuna con MSB prima o LSB prima e pixel acceso = 1 o 0. I nomi delle opzioni seguono PCtoLCD2002 e il loro significato è verificato sul datasheet dell'SSD1306 e sui progetti di esempio OLED più diffusi, così puoi scegliere le stesse impostazioni usate da un progetto esistente.

    Preset che dicono con cosa sono compatibili

    Scegli SSD1306, Adafruit GFX o XBM e le opzioni si impostano da sole. Se modifichi un'opzione a mano, lo strumento ti dice quali display e librerie leggono quell'ordine dei byte, oppure che nessuno lo fa.

    Decodifica un array che hai già

    Incolla un array di font di origine sconosciuta: tutte e otto le letture possibili di scansione e ordine dei bit vengono disegnate affiancate. Quella leggibile ti dà le impostazioni; un clic le applica.

    Da immagine a bitmap con un vero dithering

    Loghi, icone e foto vengono scalati alla dimensione del tuo display e convertiti con soglia, dithering Floyd–Steinberg o Atkinson. Le aree trasparenti contano come sfondo e la soglia funziona in tutte le modalità.

    Output pronto per il tuo progetto

    Array 2D in stile C51 con commenti /*"中",0*/, Arduino PROGMEM con offset, dizionari bytearray MicroPython, righe DB per A51 o esadecimale semplice. Il C generato compila senza warning con -Wall -Wextra -pedantic.

    Esempi svolti

    中 per un OLED SSD1306 (16 × 16, colonne per pagina, LSB prima)

    中
    00 00 F0 10 10 10 10 FF 10 10 10 10 F0 00 00 00 00 00 0F 04 04 04 04 FF 04 04 04 04 0F 00 00 00

    32 byte: le 16 colonne della pagina 0 (righe 0–7), poi le 16 colonne della pagina 1 (righe 8–15). Nello 0xFF della colonna 7 tutti i bit sono a 1: il tratto verticale attraversa tutte e otto le righe di entrambe le pagine.

    Lo stesso 中 per Adafruit GFX drawBitmap (riga per riga, MSB prima)

    中
    01 00 01 00 01 00 01 00 3F F8 21 08 21 08 21 08 21 08 21 08 3F F8 21 08 01 00 01 00 01 00 01 00

    Due byte per riga, 16 righe. 0x01 0x00 è il solo tratto centrale: il pixel più a sinistra è il bit 7 del primo byte, quindi il pixel della colonna 7 finisce nel bit 0. Se mandi questi byte a un SSD1306 con una scrittura per pagina ottieni spazzatura: stesso glifo, impacchettamento diverso.

    A a mezza larghezza in un font da 16 pixel (8 × 16)

    A
    00 00 00 00 18 24 24 42 42 7E 42 42 42 42 00 00

    I caratteri ASCII sono a mezza larghezza: 8 × 16 fa 16 byte, un byte per riga con la scansione riga per riga. Spunta "Dai ai caratteri a mezza larghezza l'intera larghezza della cella" se il tuo driver si aspetta che ogni glifo sia 16 × 16.

    Perché 12 × 12 fa 24 byte e non 18

    中 (12 × 12, riga per riga, MSB prima)
    00 00 04 00 04 00 FF E0 84 20 84 20 84 20 FF E0 04 00 04 00 04 00 04 00

    Ogni riga da 12 pixel richiede due byte; gli ultimi quattro bit del secondo byte sono di riempimento. 12 righe × 2 byte = 24. Tutte le librerie per display indirizzano le righe come (larghezza + 7) / 8 byte, quindi compattare di più i bit le manderebbe tutte in errore.

    Come generare i dati di un font per LCD o OLED

    1. 1

      Digita il testo o trascina un'immagine

      Il testo usa un vero font pixel: 12 × 12 (Fusion Pixel) o 16 × 16 (GNU Unifont), con l'ASCII a mezza larghezza. Per loghi e icone passa alla scheda Immagine e imposta la dimensione di destinazione, per esempio 128 × 64.

    2. 2

      Scegli il display o la libreria di destinazione

      SSD1306 / SH1106 / ST7565 vogliono byte verticali in ordine di pagina, con il pixel in alto nel bit 0. Adafruit GFX, TFT_eSPI, U8g2 drawBitmap e LVGL vogliono byte orizzontali con il pixel a sinistra nel bit 7. XBM / U8g2 drawXBM è uguale, ma con il pixel a sinistra nel bit 0.

    3. 3

      Controlla l'anteprima e correggi i pixel se serve

      L'anteprima mostra esattamente la bitmap che viene codificata. Clicca su un pixel per invertirlo, oppure sposta il glifo con i campi di spostamento.

    4. 4

      Copia o scarica

      Scegli C (stile C51 di PCtoLCD2002), Arduino PROGMEM, bytearray MicroPython, assembly A51 o esadecimale semplice. La prima riga dell'output riporta direzione di scansione, ordine dei bit e dimensione del glifo: l'array si documenta da solo.

    Caratteri illeggibili: sintomo → impostazione sbagliata

    Ogni gruppo di 8 pixel è specchiato da sinistra a destra

    Byte orizzontali con l'ordine dei bit sbagliato. Adafruit GFX drawBitmap() vuole MSB prima; XBM e U8g2 drawXBM() vogliono LSB prima.

    ✗ Errato
    U8g2 drawXBM() con byte MSB prima
    ✓ Corretto
    drawXBM() → preset XBM (riga per riga, LSB prima)

    Ogni blocco di 8 righe è capovolto

    Byte verticali con l'ordine dei bit sbagliato. I controller tipo SSD1306 mettono D0 nella riga in alto, quindi vogliono LSB prima.

    ✗ Errato
    Colonne per pagina, MSB prima → SSD1306
    ✓ Corretto
    Colonne per pagina, LSB prima → SSD1306

    Metà superiore e inferiore intercalate

    Colonna per colonna e colonne per pagina sono state confuse. Danno gli stessi byte solo per glifi alti al massimo 8 pixel; a 16 pixel l'ordine dei byte cambia.

    ✗ Errato
    Colonna per colonna → scritture per pagina sull'SSD1306
    ✓ Corretto
    Colonne per pagina → scritture per pagina sull'SSD1306

    Glifo ribaltato lungo la diagonale, o invertito

    Un ribaltamento diagonale significa che byte orizzontali sono stati letti come verticali (o viceversa). Testo scuro su sfondo acceso significa che è stato scelto acceso = 0 dove il display si aspetta acceso = 1.

    ✗ Errato
    Byte riga per riga inviati a una pagina dell'SSD1306
    ✓ Corretto
    Incolla l'array nella scheda del decoder e scegli l'anteprima leggibile

    Quando ti serve

    Testo cinese su un OLED SSD1306 da 0.96"
    Una temperatura, un menu o una riga di stato in cinese su una scheda STM32 o 51. Usa il font 16 × 16 con il preset SSD1306 e incolla l'array nell'oled_font.h che il tuo progetto di esempio ha già.
    Logo di avvio su un display Arduino o ESP32
    Trascina un logo PNG, imposta 128 × 64, scegli il preset Adafruit GFX e chiama display.drawBitmap(0, 0, logo, 128, 64, WHITE).
    Icone e unità per un'interfaccia LVGL o U8g2
    Simboli di batteria, Wi-Fi e °C come immagini a 1 bit. Usa il preset Adafruit GFX / LVGL per byte orizzontali con MSB prima, oppure il preset XBM per U8g2 drawXBM().
    Lavorare su Mac o Linux
    PCtoLCD2002 e i classici strumenti di 字模提取 sono programmi Windows. Questo gira in qualsiasi browser moderno e non richiede installazione.
    Reverse engineering di un progetto ereditato
    Lo sviluppatore precedente ha lasciato un array Hzk[][32] senza alcuna nota. Incollalo nel decoder per scoprire come è stato generato prima di aggiungere nuovi caratteri nello stesso formato.

    Come funzionano le quattro direzioni di scansione

    Riga per riga (byte orizzontali)
    Le righe si leggono dall'alto in basso; all'interno di una riga, ogni byte contiene otto pixel adiacenti da sinistra a destra. Una riga da 16 pixel occupa due byte. È il layout di Adafruit GFX drawBitmap(), U8g2 drawBitmap(), dei file XBM, della GDRAM dell'ST7920 e delle immagini a 1 bit di LVGL.
    Colonne per pagina (byte verticali): l'ordine dell'SSD1306
    Il glifo viene tagliato in pagine alte otto righe. Per ogni pagina, le colonne si leggono da sinistra a destra e ogni byte contiene gli otto pixel di quella colonna. Corrisponde alla GDDRAM di SSD1306, SH1106 e ST7565, il cui datasheet specifica che il bit di dati D0 viene scritto nella riga in alto: l'ordine dei bit corrispondente è quindi LSB prima.
    Colonna per colonna, e righe per striscia
    Colonna per colonna percorre ogni colonna dall'alto in basso attraverso tutte le pagine prima di spostarsi a destra; corrisponde alla modalità di indirizzamento verticale dell'SSD1306. Righe per striscia prende una striscia larga 8 pixel, tutte le sue righe, poi la striscia successiva; nessuna libreria diffusa la usa, ma i vecchi progetti PCtoLCD2002 sì. Ciascuna modalità coincide con la sua gemella solo se il glifo è alto (o largo) al massimo 8 pixel: ecco perché la confusione passa inosservata nei test a 8 × 8.
    Ordine dei bit e valore del pixel acceso
    MSB prima mette il primo pixel letto (il più a sinistra, o il più in alto) nel bit 7; LSB prima lo mette nel bit 0. PCtoLCD2002 li chiama 顺向 ("verso diretto", MSB prima) e 逆向 ("verso inverso", LSB prima). Acceso = 1 (阴码) è ciò che si aspettano gli OLED, drawBitmap() su TFT e LVGL A1; acceso = 0 (阳码) solo per i driver che definiscono 0 come acceso.
    Riempimento quando la dimensione non è multipla di 8
    Ogni riga (byte orizzontali) o ogni pagina (byte verticali) viene completata a byte interi per conto suo, e i bit di riempimento valgono 0. Con colonne per pagina e un glifo da 12 pixel, la seconda pagina porta 4 righe di riempimento; un driver che scrive pagine intere cancella quelle 4 righe sotto il glifo. Lo strumento ti avvisa quando succede.

    Fare giusto al primo colpo

    Scegli il preset in base alla funzione di disegno, non allo schermo
    Un SSD1306 pilotato da Adafruit_SSD1306 passa per drawBitmap(), quindi vuole byte orizzontali con MSB prima anche se la memoria del controller è verticale. Scegli il preset che corrisponde alla funzione chiamata dal tuo codice.
    Usa i font pixel per 12 e 16 px
    Sotto i 20 px circa, i font vettoriali perdono tratti quando vengono sogliati. Fusion Pixel 12 e Unifont 16 sono disegnati sulla griglia dei pixel, e le opzioni 2× danno 24 × 24 e 32 × 32 puliti.
    Tieni il commento di intestazione
    La prima riga dell'output riporta direzione di scansione, ordine dei bit e dimensione. Sei mesi dopo è l'unica traccia di come è stato generato l'array.
    Prova con un carattere asimmetrico
    I glifi simmetrici come 中, 田 o H nascondono gli errori di specchiatura. Prova prima F, 7 o 乙: se si legge correttamente, tutte le opzioni sono giuste.
    Correggi la specchiatura dell'intero schermo nel driver
    Se tutto lo schermo è specchiato o capovolto, non solo il tuo font, modifica il segment remap (A0h/A1h) e la direzione di scansione COM (C0h/C8h) nella sequenza di inizializzazione. Cambiare le impostazioni del font romperebbe solo il resto del codice.

    Domande frequenti

    Quali impostazioni devo usare per un OLED SSD1306 o SH1106?
    Se il tuo codice scrive i byte del font direttamente sul display (la maggior parte degli esempi per 51 e STM32): colonne per pagina, LSB prima, acceso = 1, cioè il preset SSD1306. Se invece disegna tramite Adafruit_SSD1306 o U8g2 drawBitmap(), usa il preset Adafruit GFX, perché quelle funzioni leggono byte orizzontali con MSB prima e fanno la conversione da sole.
    I miei caratteri appaiono specchiati, capovolti o scombinati. Cosa c'è che non va?
    Ogni sintomo indica un'impostazione. Ogni 8 pixel specchiati da sinistra a destra: ordine dei bit sbagliato con byte orizzontali. Ogni 8 righe capovolte: ordine dei bit sbagliato con byte verticali. Metà superiore e inferiore intercalate: colonna per colonna e colonne per pagina confuse. Ribaltato lungo la diagonale: byte orizzontali e verticali confusi. Colori invertiti: acceso = 1 e acceso = 0 scambiati. Se è specchiato l'intero schermo e non solo il testo, correggi invece la sequenza di inizializzazione del driver.
    Perché 12 × 12 occupa 24 byte e non 18?
    Ogni riga (o ogni pagina da 8 righe) viene completata a byte interi per conto suo: 12 pixel richiedono 2 byte, e 12 righe × 2 = 24. Le librerie per display indirizzano le righe come (larghezza + 7) / 8 byte, quindi un glifo compattato in 18 byte verrebbe letto male da tutte.
    Perché il mio testo da 12 pixel cancella la riga sotto sull'OLED?
    Con colonne per pagina, un glifo da 12 pixel riempie una pagina intera e metà della successiva; gli altri 4 bit di quella seconda pagina sono zeri di riempimento. Un driver che scrive pagine intere cancella quelle 4 righe. Disegna tramite un frame buffer che imposta i singoli pixel, oppure posiziona il testo da 12 pixel in modo che le righe vuote cadano dove non viene disegnato nient'altro.
    Posso usarlo al posto di PCtoLCD2002 su Mac?
    Sì. Gira in qualsiasi browser moderno, offre le stesse quattro modalità di scansione, entrambi gli ordini dei bit e acceso = 1 / acceso = 0, e l'output C segue lo stile C51 di PCtoLCD2002 con commenti /*"字",0*/, quindi si incolla direttamente nei progetti costruiti attorno ad array tipo Hzk[][32]. Non genera file completi di librerie di font né indici. Le forme dei glifi provengono da GNU Unifont e Fusion Pixel, non dal SimSun di Windows, quindi i byte non coincideranno carattere per carattere con un array generato da PCtoLCD2002: rigenera qui l'intera tabella invece di mescolare le due fonti. Questo sito non è affiliato a PCtoLCD2002 né al suo autore, non è una versione web ufficiale e non offre il programma in download.
    Perché usare un font pixel invece del font di sistema?
    I font di sistema sono contorni disegnati con antialiasing, che il browser non può disattivare. A 12 o 16 pixel, applicare la soglia a quel bordo grigio fa perdere i tratti sottili: le barre orizzontali di 中 spariscono del tutto in un carattere Song da 12 pixel. GNU Unifont (16 px) e Fusion Pixel (12 px) sono progettati sulla griglia dei pixel, quindi non si perde nulla. I font di sistema restano disponibili per dimensioni maggiori: un carattere senza grazie (Hei) regge da circa 24 px, mentre i caratteri Song possono ancora perdere tratti a quella dimensione.
    Quali caratteri coprono i font pixel?
    Tutto il GB2312 (6.763 caratteri cinesi semplificati più la punteggiatura a larghezza piena), oltre ad ASCII stampabile, lettere latine accentate (é, ß, ł, ş, ő), greco, cirillico, kana giapponesi e simboli comuni come ℃, frecce e caratteri per disegnare riquadri. A Fusion Pixel 12 px mancano alcuni caratteri e simboli rari. L'hangul coreano e i caratteri cinesi fuori dal GB2312 (forme tradizionali, molti kanji giapponesi) vengono disegnati con un font di sistema ed elencati sotto l'anteprima, così vedi quali glifi controllare.
    Come converto un logo o un'icona in un array C?
    Apri la scheda Immagine, trascina il file, imposta la dimensione del display (128 × 64 per un OLED da 0.96") e lascia "Adatta all'interno, mantieni le proporzioni" per conservare il rapporto d'aspetto. I pixel scuri diventano pixel accesi; spunta l'inversione per un disegno chiaro su sfondo scuro. Niente dithering per loghi e testo, Floyd–Steinberg o Atkinson per le foto.
    Come capisco come è stato generato un array di font esistente?
    Incollalo nella scheda "Anteprima di un array esistente". I commenti vengono ignorati e sono accettate le sintassi C, Arduino, A51 e MicroPython. La dimensione del glifo viene dedotta dal numero di byte e vengono disegnate tutte e otto le combinazioni di direzione di scansione e ordine dei bit. Quella che si legge correttamente è la tua impostazione, e "Usa queste impostazioni" la copia nel generatore.
    Il mio testo o la mia immagine vengono caricati da qualche parte?
    No. I glifi vengono renderizzati e codificati nel tuo browser. I font pixel si scaricano una sola volta da questo sito e nulla di ciò che digiti o trascini viene inviato altrove.

    Strumenti correlati

    Vedi tutti gli strumenti →

    Convertitore di Basi Numeriche — Bin, Hex, Ott, Dec

    Strumenti di conversione

    Converti istantaneamente tra binario, esadecimale, decimale, ottale e qualsiasi base (2-36). Strumento online gratuito e privato: tutta l'elaborazione avviene nel tuo browser.

    Calcolatore di Complemento a Due e Interi con Segno

    Strumenti di conversione

    Digita un intero con segno e ottieni insieme modulo e segno, complemento a uno, complemento a due e binario con offset, da 4 a 64 bit. Oppure incolla dei bit o un byte esadecimale e leggi tutte e cinque le letture affiancate.

    Calcolatore chmod per i Permessi dei File Linux

    Strumenti di conversione

    Converti i permessi file Linux tra ottale (755, 644) e simboli rwx online: comandi chmod pronti, avvisi sui modi rischiosi come 777, 100% nel browser.

    Convertitore di colori — HEX, RGB, HSL e OKLCH

    Strumenti di conversione

    Converte HEX in RGB, HSL, OKLCH, OKLAB e CMYK direttamente nel browser — basta un clic per copiare qualsiasi formato. Gratuito, senza registrazione, i colori non lasciano mai la pagina.

    Convertire coordinate GPS: gradi minuti secondi, UTM, GCJ-02

    Strumenti di conversione

    Converti coordinate GPS in qualsiasi formato — gradi decimali, gradi minuti secondi (GMS) — in UTM, Web Mercator, GCJ-02 (AMap) e BD-09 (Baidu). Riconosce lat,lng o lng,lat, conversione in blocco in CSV. Nel browser.

    Convertitore HEX in CMYK

    Strumenti di conversione

    Converte colori HEX in CMYK direttamente nel browser. Approssimazione ingenua basata su sRGB per proof di stampa. Gratuito, online, senza registrazione, i colori non lasciano mai la pagina.