[🛠] Levar backups em PDF do Naver Blog para o GitHub Pages
✨ Resumo do GPT-5.5
Registro de como extraí 173 posts e 1.521 imagens de 18 backups em PDF do Naver Blog e os transplantei de volta para a estrutura existente do blog no GitHub Pages.
Fiquei com vontade de trazer de volta para o blog no GitHub Pages os posts que eu tinha acumulado no Naver Blog.
Mais exatamente, não era só uma questão de guardar arquivos de backup em algum lugar. Já havia textos escritos. Havia datas, imagens, categorias e pensamentos daquela época. Só que esses registros estavam separados, em outra casa chamada Naver Blog.
No fim, eu queria colocar este blog novamente no centro dos meus registros. Um blog no GitHub Pages é simples, mas me permite acumular registros na estrutura que eu quero.
Só que, desta vez, o problema não era escrever um post novo.
Eu precisava pegar 18 backups em PDF do Naver Blog e levar os posts e imagens dentro deles de volta para a estrutura existente do blog em Jekyll.
Primeiro defini as condições
Desde o começo, o objetivo era simples.
Eu queria trazer o backup do Naver Blog, mas fazer com que ele fosse lido dentro deste blog como se os posts já tivessem pertencido a ele desde o início.
Defini algumas condições.
- Extrair todos os posts dos 18 PDFs sem deixar nada para trás.
- Preservar a data e o link original de cada post.
- Colocar as imagens em
assets/images/YYYY-MM/YYYY-MM-DD/, seguindo a convenção existente do blog. - Fazer a numeração da série
Hoje foicontinuar a partir dos posts existentes. - Não misturar posts de restaurante, viagem, AI, desenvolvimento e assuntos parecidos na numeração de
Hoje foi. - Não empurrar os posts à força para categorias existentes; criar novas categorias se necessário.
- Não importar frases quebradas do PDF como estavam.
- O resultado precisava ser composto por posts Jekyll capazes de passar no build.
Escrito assim, parece comum. Mas, quando fui fazer de verdade, não era uma simples cópia de arquivos.
Era uma mudança de registros de um sistema para outro.
Não dava para confiar só no texto do PDF
No começo, achei que bastaria extrair texto e imagens dos PDFs.
Os posts foram extraídos. As imagens também. Mas o problema estava no corpo do texto. As frases vindas do PDF estavam quebradas em lugares estranhos.
Por exemplo, apareciam assim.
Tentar controlar aquela tempestade enorme sozinho o mais rápido possível, esse excesso de vontade em si era a maior causa que me deixava impotente
por causa disso.
Uma única frase se partia como se fossem parágrafos, palavras se quebravam, e o ritmo de leitura ficava destruído.
Se eu migrasse os textos naquele estado, talvez até tivesse um backup, mas os posts em si estariam danificados. Não pareciam textos para uma pessoa ler. Pareciam mais rastros arrancados de um PDF.
Então mudei de direção.
Usei o PDF como ponto de partida para a lista de posts e para a extração das imagens, mas reli o HTML original do Naver para recuperar o corpo do texto. Segui o fluxo de parágrafos, listas e citações do editor do Naver e reconstruí o corpo em Markdown.
Só aí os textos voltaram a parecer textos.
Ajustei as imagens ao jeito existente do blog
As imagens também eram importantes.
Os posts do Naver tinham muitas imagens. Especialmente em posts de viagem ou restaurante, as imagens eram quase o próprio corpo do texto. Se eu levasse só o texto, o registro ficaria pela metade.
No fim, as imagens importadas foram 1.521.
Os caminhos das imagens seguiram a convenção existente do blog.
assets/images/2025-09/2025-09-09/naver-004-001.jpg
Organizei os nomes com ano-mês, data e número de importação do Naver. Assim, mesmo depois, ao olhar o arquivo, dá para rastrear de qual data e de qual importação aquela imagem veio.
No corpo, usei a sintaxe normal de imagem em Markdown.
Em um blog estático, esse tipo de simplicidade importa. Depois do build, são apenas arquivos. Não preciso depender de um servidor de imagens separado nem de links externos.
Dividi as categorias de novo
A parte que exigiu mais cuidado foi a categorização.
No começo, pensei se não bastaria colocar os posts do Naver mais ou menos embaixo de diary. Mas, se fizesse isso, ficaria difícil encontrar posts depois, e a estrutura do blog também ficaria borrada.
Então criei novas categorias.
diary life
diary thought
diary relationship
diary restaurant
diary travel
Também usei categorias que já existiam, como diary ai, diary dev e diary religion. Posts de leitura e mindset foram para reading mindset, apresentações de app para tip app, e registros de construção do blog para a subcategoria devlog github-pages-blog.
Criar categorias não termina movendo um único arquivo.
São necessárias páginas de categoria. Também é necessária a navegação da sidebar. Os rótulos e links de categoria que aparecem no arquivo precisam bater. O ícone antes do título também precisa combinar com a convenção existente do blog.
Posts de restaurante foram organizados com [🍽️], posts de AI com [🤖], posts de desenvolvimento com [🧑💻], posts de viagem com [🧳], e assim por diante.
Parecem detalhes pequenos, mas, se essas partes se desorganizam, os posts importados continuam parecendo corpos estranhos vindos de fora.
Mantive a numeração de Hoje foi separada
A parte mais fácil de confundir era a numeração de Hoje foi.
Os posts de Verificação de hoje que estavam no Naver eram, na prática, Daily Reviews. Por isso, precisavam continuar a série Hoje foi do blog existente.
Por outro lado, posts de restaurante, viagem, AI e leitura não fazem parte de Hoje foi, por mais próximas que as datas estejam. Se esses posts entrassem na numeração, a própria série se quebraria.
O resultado final ficou alinhado assim.
Hoje foi #1 ~ #200
A numeração foi de 1 a 200, sem lacunas nem duplicações. Também confirmei que posts que não eram Daily Review não continham numeração Hoje foi #.
Isso não era apenas organizar números.
Era preservar a identidade da série.
A verificação foi metade do trabalho
O que assusta nesse tipo de migração é que, por fora, tudo pode parecer plausível, enquanto uma coisa ou outra vai ficando discretamente errada.
Pode faltar um arquivo de imagem enquanto a referência em Markdown continua ali. O front matter da categoria pode não combinar com a pasta real. O ícone do título pode fugir da convenção existente. Um ícone ? quebrado vindo do PDF pode permanecer no corpo.
Por isso rodei uma verificação separada.
O que conferi foi, em linhas gerais, isto.
Posts importados: 173
Referências de imagem: 1.521
Imagens ausentes: 0
Sinais ? soltos visíveis restantes: 0
Numeração Hoje foi: #1 ~ #200
Numeração misturada em posts que não eram Daily Review: 0
Incompatibilidades entre categoria e pasta: 0
No fim, também rodei o build do Jekyll.
bundle exec jekyll build
Em um blog estático, só dá para respirar tranquilo quando o build passa. Se a sintaxe Liquid de um único Markdown quebrar, o site inteiro pode parar.
Resultado
No fim, levei 173 posts e 1.521 imagens de 18 backups em PDF do Naver Blog para este blog.
Mas o mais importante não são os números.
Esse trabalho não foi um simples backup. Foi restaurar registros espalhados dentro de um único sistema.
PDF, HTML do Naver, front matter do Jekyll, páginas de categoria, navegação da sidebar, caminhos de imagem e numeração de série precisavam estar todos alinhados. Se apenas uma coisa estivesse errada, o contexto dos registros se quebraria.
Para outras pessoas, talvez pareça só uma transferência de posts. Mas, do meu ponto de vista, foi um trabalho de reorganizar o sistema de registros.
Não foi apenas trazer muitos textos. Foi decidir de novo como estruturar os registros que eu vinha acumulando, como recuperar dados quebrados e como assentá-los dentro das convenções do sistema existente.
Escrever registros é importante, mas segurá-los de novo para que não se percam também é.
Este trabalho ficou mais perto disso.
Deixe um comentário