Skip to content

Gerador de fontes LCD e OLED (bitmap para array C)

Converta texto em chinês ou inglês e imagens em arrays C para SSD1306, SH1106, ST7920 e Adafruit GFX. Fontes pixel nítidas de 12×12 e 16×16, os 4 modos de varredura do PCtoLCD2002 e um decodificador.

Sem rastreamento Roda no navegador Grátis
Tudo roda no seu navegador — textos e imagens nunca saem deste dispositivo.

Compatível com a memória por páginas de SSD1306 / SSD1309 / SH1106 / ST7565 e com MicroPython framebuf.MONO_VLSB — grave os bytes direto no display.

Pré-visualização

Clique em um pixel para invertê-lo.
    3 glifo(s) · 48 bytes
    Referência: o caractere 中 (16 × 16) em cada direção de varredura

    Pixel aceso = 1, glifo da GNU Unifont. Compare estes bytes com o seu array para saber com que configuração ele foi gerado.

    Direção de varredura Ordem dos bits Bytes (hex)
    Linha por linha (bytes horizontais) MSB primeiro — primeiro pixel no 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
    Linha por linha (bytes horizontais) LSB primeiro — primeiro pixel no 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
    Coluna por coluna (bytes verticais) MSB primeiro — primeiro pixel no 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
    Coluna por coluna (bytes verticais) LSB primeiro — primeiro pixel no 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
    Colunas por página (bytes verticais, ordem de página do SSD1306) MSB primeiro — primeiro pixel no 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
    Colunas por página (bytes verticais, ordem de página do SSD1306) LSB primeiro — primeiro pixel no 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
    Linhas por faixa (bytes horizontais, faixas de 8 pixels) MSB primeiro — primeiro pixel no 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
    Linhas por faixa (bytes horizontais, faixas de 8 pixels) LSB primeiro — primeiro pixel no 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

    Fontes pixel: GNU Unifont (16 px) e Fusion Pixel Font (12 px), ambas sob a SIL Open Font License 1.1. Textos das licenças

    As oito combinações de direção de varredura e ordem de bits são conferidas byte a byte contra uma implementação de referência independente, e os presets contra os datasheets do SSD1306, SH1106 e ST7565 e o código-fonte do Adafruit GFX, U8g2, LVGL e MicroPython. — Equipe Go Tools · Oct 3, 2026

    Desenvolvido e verificado pela equipe de engenharia da Go Tools.

    Respostas rápidas

    Que configuração um OLED SSD1306 precisa?

    Colunas por página · LSB primeiro Colunas por página, LSB primeiro, pixel aceso = 1 — quando você grava os bytes direto na memória do display.

    Que configuração o Adafruit GFX drawBitmap() precisa?

    Linha por linha · MSB primeiro Linha por linha, MSB primeiro, pixel aceso = 1, com cada linha completada até bytes inteiros.

    Quantos bytes tem um caractere de 16 × 16?

    32 bytes 32 bytes em qualquer direção de varredura. Um de 12 × 12 tem 24 bytes; um caractere ASCII de 8 × 16 tem 16.

    O que significam 顺向 e 逆向 no PCtoLCD2002?

    逆向 = LSB primeiro 顺向 ("sentido direto") = MSB primeiro (primeiro pixel no bit 7); 逆向 ("sentido inverso") = LSB primeiro (primeiro pixel no bit 0).

    O que é o bitmap de uma fonte (取模)?

    A maioria dos controladores gráficos de OLED e LCD — entre eles o SSD1306, o SH1106 e o ST7565 — não tem fonte embutida. Para mostrar um caractere, o firmware copia para a memória do display uma pequena grade de pixels acesos ou apagados, um bit por pixel, oito pixels por byte. Transformar um glifo nesses bytes é o que os tutoriais chineses de embarcados chamam de 取模 (literalmente, "extrair o molde" do caractere), o trabalho que o programa para Windows PCtoLCD2002 faz há anos.

    Só os bytes não bastam. O mesmo caractere de 16 × 16 pode ser empacotado de quatro jeitos (linha por linha, coluna por coluna, colunas por página, linhas por faixa) e cada jeito pode colocar o primeiro pixel no bit 7 ou no bit 0. São oito sequências de bytes descrevendo o mesmo glifo, e um display desenha corretamente só uma delas. É por isso que uma fonte copiada de um tutorial aparece com tanta frequência espelhada, partida ao meio ou girada.

    // 中 (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

    O que este gerador faz

    Chinês em 12 × 12 e 16 × 16 perfeito no pixel

    As fontes do navegador são contornos com antialiasing; com limiar a 12 px numa fonte Song, os traços horizontais de 中 simplesmente somem. Por isso esta ferramenta traz fontes bitmap de verdade: a de 16 × 16 cobre todos os 6.763 caracteres do GB2312, enquanto à de 12 × 12 faltam 143 caracteres raros, que são desenhados com uma fonte do sistema e sinalizados.

    Os quatro modos de varredura do PCtoLCD2002, nas duas ordens de bits

    Linha por linha, coluna por coluna, colunas por página e linhas por faixa, cada um com MSB primeiro ou LSB primeiro e pixel aceso = 1 ou 0. Os nomes das opções seguem o PCtoLCD2002, e o significado delas foi conferido com o datasheet do SSD1306 e com projetos de exemplo de OLED comuns, então você pode escolher as mesmas configurações que um projeto existente usa.

    Presets que dizem com o que são compatíveis

    Escolha SSD1306, Adafruit GFX ou XBM e as opções são ajustadas para você. Mude qualquer opção à mão e a ferramenta informa quais displays e bibliotecas leem essa ordem de bytes — ou que nenhum lê.

    Decodifique um array que você já tem

    Cole um array de fonte de origem desconhecida e as oito leituras possíveis de varredura e ordem de bits são desenhadas lado a lado. A que fica legível revela a configuração; um clique a aplica.

    Imagem para bitmap com dithering de verdade

    Logos, ícones e fotos são redimensionados para o tamanho do seu display e convertidos por limiar, dithering Floyd–Steinberg ou Atkinson. Áreas transparentes contam como fundo, e o limiar funciona em todos os modos.

    Saída pronta para o seu projeto

    Arrays 2D no estilo C51 com comentários /*"中",0*/, Arduino PROGMEM com offsets, dicionários bytearray do MicroPython, linhas DB para A51 ou hexadecimal puro. O C gerado compila sem avisos com -Wall -Wextra -pedantic.

    Exemplos comentados

    中 para um OLED SSD1306 (16 × 16, colunas por página, LSB primeiro)

    中
    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 bytes: as 16 colunas da página 0 (linhas 0–7) e depois as 16 colunas da página 1 (linhas 8–15). No 0xFF da coluna 7 todos os bits estão ligados: o traço vertical atravessa as oito linhas das duas páginas.

    O mesmo 中 para Adafruit GFX drawBitmap (linha por linha, MSB primeiro)

    中
    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

    Dois bytes por linha, 16 linhas. 0x01 0x00 é só o traço central: o pixel mais à esquerda é o bit 7 do primeiro byte, então o pixel da coluna 7 cai no bit 0. Mande esses bytes para um SSD1306 com escrita por página e o resultado é lixo — mesmo glifo, empacotamento diferente.

    A em meia largura numa fonte de 16 pixels (8 × 16)

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

    Caracteres ASCII têm meia largura: 8 × 16 são 16 bytes, um byte por linha na varredura linha por linha. Marque "Dar largura total de célula aos caracteres de meia largura" se o seu driver espera que todo glifo tenha 16 × 16.

    Por que 12 × 12 dá 24 bytes, e não 18

    中 (12 × 12, linha por linha, MSB primeiro)
    00 00 04 00 04 00 FF E0 84 20 84 20 84 20 FF E0 04 00 04 00 04 00 04 00

    Cada linha de 12 pixels precisa de dois bytes; os quatro últimos bits do segundo byte são preenchimento. 12 linhas × 2 bytes = 24. Todas as bibliotecas de display endereçam uma linha como (largura + 7) / 8 bytes, então compactar mais os bits quebraria todas elas.

    Como gerar dados de fonte para um LCD ou OLED

    1. 1

      Digite o texto ou arraste uma imagem

      O texto usa uma fonte pixel de verdade: 12 × 12 (Fusion Pixel) ou 16 × 16 (GNU Unifont), com ASCII em meia largura. Para logos e ícones, mude para a aba Imagem e defina o tamanho de destino, como 128 × 64.

    2. 2

      Escolha o display ou a biblioteca de destino

      SSD1306 / SH1106 / ST7565 precisam de bytes verticais em ordem de página, com o pixel de cima no bit 0. Adafruit GFX, TFT_eSPI, U8g2 drawBitmap e LVGL precisam de bytes horizontais com o pixel da esquerda no bit 7. XBM / U8g2 drawXBM é igual, mas com o pixel da esquerda no bit 0.

    3. 3

      Confira a pré-visualização e corrija pixels se precisar

      A pré-visualização mostra exatamente o bitmap que é codificado. Clique em qualquer pixel para invertê-lo ou desloque o glifo com os campos de deslocamento.

    4. 4

      Copie ou baixe

      Escolha C (estilo C51 do PCtoLCD2002), Arduino PROGMEM, bytearray do MicroPython, assembly A51 ou hexadecimal puro. A primeira linha da saída registra a direção de varredura, a ordem dos bits e o tamanho do glifo, então o array se documenta sozinho.

    Caracteres embaralhados: sintoma → configuração errada

    Cada grupo de 8 pixels aparece espelhado na horizontal

    Bytes horizontais com a ordem de bits errada. Adafruit GFX drawBitmap() precisa de MSB primeiro; XBM e U8g2 drawXBM() precisam de LSB primeiro.

    ✗ Incorreto 
    U8g2 drawXBM() recebendo bytes com MSB primeiro
    ✓ Correto 
    drawXBM() → preset XBM (linha por linha, LSB primeiro)

    Cada bloco de 8 linhas aparece de cabeça para baixo

    Bytes verticais com a ordem de bits errada. Controladores do tipo SSD1306 colocam o D0 na linha de cima, então precisam de LSB primeiro.

    ✗ Incorreto 
    Colunas por página, MSB primeiro → SSD1306
    ✓ Correto 
    Colunas por página, LSB primeiro → SSD1306

    Metades de cima e de baixo intercaladas

    Coluna por coluna e colunas por página foram confundidos. Eles só geram os mesmos bytes para glifos de até 8 pixels de altura; com 16 pixels, a ordem dos bytes muda.

    ✗ Incorreto 
    Coluna por coluna → escrita por página no SSD1306
    ✓ Correto 
    Colunas por página → escrita por página no SSD1306

    Glifo espelhado na diagonal, ou invertido

    Espelhamento na diagonal significa que bytes horizontais foram lidos como verticais (ou o contrário). Texto escuro sobre fundo aceso significa que aceso = 0 foi escolhido onde o display espera aceso = 1.

    ✗ Incorreto 
    Bytes linha por linha enviados para uma página do SSD1306
    ✓ Correto 
    Cole o array na aba do decodificador e escolha a pré-visualização legível

    Quando você precisa disto

    Texto em chinês num OLED SSD1306 de 0,96"
    Uma leitura de temperatura, um menu ou uma linha de status em chinês numa placa STM32 ou 51. Use a fonte de 16 × 16 com o preset SSD1306 e cole o array no oled_font.h que seu projeto de exemplo já tem.
    Logo de inicialização num display Arduino ou ESP32
    Arraste um logo PNG, defina 128 × 64, escolha o preset Adafruit GFX e chame display.drawBitmap(0, 0, logo, 128, 64, WHITE).
    Ícones e unidades para uma interface LVGL ou U8g2
    Símbolos de bateria, Wi-Fi e °C como imagens de 1 bit. Use o preset Adafruit GFX / LVGL para bytes horizontais com MSB primeiro, ou o preset XBM para U8g2 drawXBM().
    Trabalhando num Mac ou Linux
    O PCtoLCD2002 e as clássicas ferramentas de 字模提取 são programas para Windows. Esta roda em qualquer navegador moderno e não precisa de instalação.
    Engenharia reversa de um projeto herdado
    O desenvolvedor anterior deixou um array Hzk[][32] sem nenhuma anotação. Cole-o no decodificador para descobrir como ele foi gerado antes de acrescentar novos caracteres no mesmo formato.

    Como funcionam as quatro direções de varredura

    Linha por linha (bytes horizontais)
    As linhas são lidas de cima para baixo; dentro de uma linha, cada byte guarda oito pixels vizinhos, da esquerda para a direita. Uma linha de 16 pixels ocupa dois bytes. É o layout do Adafruit GFX drawBitmap(), do U8g2 drawBitmap(), dos arquivos XBM, da GDRAM do ST7920 e das imagens de 1 bit do LVGL.
    Colunas por página (bytes verticais) — a ordem do SSD1306
    O glifo é fatiado em páginas de oito linhas de altura. Em cada página, as colunas são lidas da esquerda para a direita e cada byte guarda os oito pixels daquela coluna. Isso corresponde à GDDRAM do SSD1306, SH1106 e ST7565, cujo datasheet diz que o bit de dados D0 é gravado na linha de cima — portanto a ordem de bits correspondente é LSB primeiro.
    Coluna por coluna, e linhas por faixa
    Coluna por coluna percorre cada coluna de cima para baixo por todas as páginas antes de ir para a direita; corresponde ao modo de endereçamento vertical do SSD1306. Linhas por faixa pega uma faixa de 8 pixels de largura, todas as suas linhas, e depois a faixa seguinte; nenhuma biblioteca popular usa esse modo, mas projetos antigos do PCtoLCD2002 usam. Cada modo só fica idêntico ao seu par quando o glifo tem no máximo 8 pixels de altura (ou de largura), e é por isso que a confusão passa despercebida em testes com 8 × 8.
    Ordem dos bits e valor do pixel aceso
    MSB primeiro coloca o primeiro pixel lido (o mais à esquerda, ou o mais acima) no bit 7; LSB primeiro o coloca no bit 0. O PCtoLCD2002 chama esses modos de 顺向 ("sentido direto", MSB primeiro) e 逆向 ("sentido inverso", LSB primeiro). Aceso = 1 (阴码) é o que OLEDs, drawBitmap() em TFT e LVGL A1 esperam; aceso = 0 (阳码) só serve para drivers que definem 0 como aceso.
    Preenchimento quando o tamanho não é múltiplo de 8
    Cada linha (bytes horizontais) ou cada página (bytes verticais) é completada separadamente até fechar bytes inteiros, e os bits de preenchimento valem 0. Com colunas por página e um glifo de 12 pixels, a segunda página carrega 4 linhas de preenchimento; um driver que grava páginas inteiras apaga essas 4 linhas abaixo do glifo. A ferramenta avisa quando isso acontece.

    Acertando de primeira

    Escolha o preset pela função de desenho, não pela tela
    Um SSD1306 controlado pela Adafruit_SSD1306 passa por drawBitmap(), então precisa de bytes horizontais com MSB primeiro, mesmo que a memória do próprio controlador seja vertical. Escolha o preset que corresponde à função que o seu código chama.
    Use as fontes pixel em 12 e 16 px
    Abaixo de uns 20 px, fontes vetoriais perdem traços quando passam pelo limiar. Fusion Pixel 12 e Unifont 16 são desenhadas sobre a grade de pixels, e as opções 2× geram 24 × 24 e 32 × 32 limpos.
    Mantenha o comentário de cabeçalho
    A primeira linha da saída registra direção de varredura, ordem dos bits e tamanho. Seis meses depois, é o único registro de como o array foi gerado.
    Teste com um caractere assimétrico
    Glifos simétricos como 中, 田 ou H escondem erros de espelhamento. Teste primeiro com F, 7 ou 乙: se aparecer certo, todas as opções estão certas.
    Corrija o espelhamento da tela inteira no driver
    Se tudo na tela aparece espelhado ou de cabeça para baixo, e não só a sua fonte, altere o segment remap (A0h/A1h) e a direção de varredura COM (C0h/C8h) na sequência de inicialização. Mexer nas configurações da fonte só quebraria o resto do código.

    Perguntas frequentes

    Que configuração devo usar para um OLED SSD1306 ou SH1106?
    Se o seu código grava os bytes da fonte direto no display (a maioria dos exemplos para 51 e STM32): colunas por página, LSB primeiro, aceso = 1 — o preset SSD1306. Se ele desenha pela Adafruit_SSD1306 ou pelo U8g2 drawBitmap(), use o preset Adafruit GFX, porque essas funções leem bytes horizontais com MSB primeiro e fazem a conversão por conta própria.
    Meus caracteres aparecem espelhados, de cabeça para baixo ou embaralhados. O que está errado?
    Cada sintoma aponta para uma configuração. Cada 8 pixels espelhados na horizontal: ordem de bits errada com bytes horizontais. Cada 8 linhas de cabeça para baixo: ordem de bits errada com bytes verticais. Metades de cima e de baixo intercaladas: coluna por coluna e colunas por página confundidos. Espelhado na diagonal: bytes horizontais e verticais confundidos. Cores invertidas: aceso = 1 e aceso = 0 trocados. Se a tela inteira estiver espelhada, e não só o seu texto, corrija a sequência de inicialização do driver.
    Por que 12 × 12 ocupa 24 bytes, e não 18?
    Cada linha (ou cada página de 8 linhas) é completada separadamente até fechar bytes inteiros: 12 pixels precisam de 2 bytes, e 12 linhas × 2 = 24. As bibliotecas de display endereçam uma linha como (largura + 7) / 8 bytes, então um glifo compactado em 18 bytes seria lido errado por todas elas.
    Por que meu texto de 12 pixels apaga a linha de baixo no OLED?
    Com colunas por página, um glifo de 12 pixels preenche uma página inteira e metade da seguinte; os outros 4 bits dessa segunda página são zeros de preenchimento. Um driver que grava páginas inteiras apaga essas 4 linhas. Desenhe por um frame buffer que altera pixels individuais, ou posicione o texto de 12 pixels de modo que as linhas vazias caiam onde nada mais é desenhado.
    Posso usar isto no lugar do PCtoLCD2002 num Mac?
    Sim. Ele roda em qualquer navegador moderno, oferece os mesmos quatro modos de varredura, as duas ordens de bits e aceso = 1 / aceso = 0, e a saída C segue o estilo C51 do PCtoLCD2002 com comentários /*"字",0*/, então dá para colar direto em projetos construídos com arrays no estilo Hzk[][32]. Ele não gera arquivos completos de biblioteca de fontes nem índices. Os glifos vêm do GNU Unifont e do Fusion Pixel, não do SimSun do Windows, então os bytes não vão bater caractere por caractere com um array gerado pelo PCtoLCD2002 — gere a tabela inteira aqui em vez de misturar os dois. Este site não tem vínculo com o PCtoLCD2002 nem com seu autor, não é uma versão web oficial e não oferece o programa para download.
    Por que usar uma fonte pixel em vez da fonte do sistema?
    As fontes do sistema são contornos desenhados com antialiasing, que o navegador não consegue desligar. Em 12 ou 16 pixels, aplicar limiar nessa borda cinza faz perder os traços finos — as barras horizontais de 中 somem por completo numa fonte Song de 12 pixels. GNU Unifont (16 px) e Fusion Pixel (12 px) são desenhadas sobre a grade de pixels, então nada se perde. As fontes do sistema continuam disponíveis para tamanhos maiores: uma fonte sem serifa (Hei) se sustenta a partir de uns 24 px, enquanto fontes Song ainda podem perder traços nesse tamanho.
    Quais caracteres as fontes pixel cobrem?
    Todo o GB2312 — 6.763 caracteres chineses simplificados mais a pontuação de largura total — e também ASCII imprimível, letras latinas acentuadas (é, ß, ł, ş, ő), grego, cirílico, kana japonês e símbolos comuns como ℃, setas e caracteres de desenho de caixas. Faltam à Fusion Pixel 12 px alguns caracteres e símbolos raros. O hangul coreano e os caracteres chineses fora do GB2312 (formas tradicionais, muitos kanji japoneses) são desenhados com uma fonte do sistema e listados abaixo da pré-visualização, para você ver quais glifos conferir.
    Como converto um logo ou ícone em array C?
    Abra a aba Imagem, arraste o arquivo, defina o tamanho do display (128 × 64 para um OLED de 0,96") e mantenha "Ajustar dentro, manter proporções" para preservar a proporção. Pixels escuros viram pixels acesos; marque inverter para arte clara sobre fundo escuro. Sem dithering para logos e texto; Floyd–Steinberg ou Atkinson para fotos.
    Como descubro de que jeito um array de fonte existente foi gerado?
    Cole-o na aba "Pré-visualizar um array existente". Comentários são ignorados, e sintaxe de C, Arduino, A51 e MicroPython é aceita. O tamanho do glifo é deduzido pela contagem de bytes e as oito combinações de direção de varredura e ordem de bits são desenhadas. A que aparece legível é a sua configuração, e "Usar esta configuração" a copia para o gerador.
    Meu texto ou minha imagem é enviado para algum lugar?
    Não. Os glifos são renderizados e codificados no seu navegador. As fontes pixel são baixadas uma única vez deste site, e nada do que você digita ou arrasta é enviado para lugar nenhum.

    Ferramentas relacionadas

    Ver todas as ferramentas →

    Conversor de Base Numérica — Binário, Hex, Decimal e Octal

    Ferramentas de Conversão

    Converta números entre binário, hexadecimal, decimal, octal e qualquer base personalizada (2-36) instantaneamente. Gratuito, privado, sem cadastro — todo o processamento acontece no seu navegador.

    Calculadora de complemento de dois e inteiros com sinal

    Ferramentas de Conversão

    Digite um inteiro com sinal e obtenha de uma vez sinal-magnitude, complemento de um, complemento de dois e binário deslocado, de 4 a 64 bits. Ou cole um padrão de bits ou byte hexadecimal e veja as cinco leituras.

    Calculadora chmod — Permissões de Arquivos Linux

    Ferramentas de Conversão

    Converta permissões de arquivos Linux entre octal (755, 644) e símbolos rwx. Gere comandos chmod e detecte ajustes arriscados como 777 — grátis, direto no seu navegador.

    Conversor de Cores — HEX, RGB, HSL e OKLCH

    Ferramentas de Conversão

    Converta HEX para RGB, HSL, OKLCH, OKLAB e CMYK no seu navegador — copie qualquer formato com um clique. Grátis, sem cadastro, suas cores nunca saem da página.

    Conversor de coordenadas: lat/long, GMS, UTM, GCJ-02

    Ferramentas de Conversão

    Converta coordenadas GPS de qualquer formato — graus decimais, graus minutos segundos (GMS) — para UTM, Web Mercator, GCJ-02 (AMap) e BD-09 (Baidu). Detecta lat,lng ou lng,lat, inverte o GCJ-02 abaixo de 1 mm e exporta CSV.

    Conversor de HEX para CMYK

    Ferramentas de Conversão

    Converta cores HEX para CMYK no seu navegador. Aproximação ingênua baseada em sRGB para prévias de impressão. Grátis, sem cadastro, suas cores ficam locais.