Guia de Upload Personalizado do ShareX: Links de Screenshots Auto-hospedados
Uma das razões que poder usuários ama ShareX é que ele não bloqueia suas capturas de tela na nuvem de outra pessoa. Com um carregador personalizado, o ShareX pode enviar cada captura para um destino você controle — seu próprio servidor, um bucket de armazenamento de objetos ou um endpoint de encurtamento de links — e devolver um URL compartilhável automaticamente. Este guia explica como o sistema de carregador personalizado funciona, como configurar um corretamente e como manter seus credenciais seguros enquanto faz isso.
Distinção chave de entrada: ShareX's carregador HTTP personalizado genérico é para falar com seu próprio ou um endpoint HTTP de terceiros. Para armazenamento de objetos maior, o ShareX também envia guias de destino integrados — incluindo Amazon S3, Google Cloud Storage e Cloudflare R2 — que geralmente são mais fáceis do que criar manualmente uma solicitação HTTP. Escolha o caminho integrado quando um existir; use o carregador HTTP genérico quando não.
O que um carregador personalizado realmente é
Conforme a própria documentação do ShareX coloca, o recurso de carregador personalizado é principalmente usado por pessoas que hospemdam seus próprios serviços. Na prática, é uma pequena definição que diz ao ShareX: quando eu capturar algo, enviar para este URL, usando este pedido, e encontre o link resultante em esta parte da resposta. Obtenha essas três coisas certas e o ShareX carrega silenciosamente e copia um URL funcionando toda vez que você recorta.
A solicitação: métodos e tipos de corpo
O ShareX custom uploader suporta os métodos HTTP padrão — GET, POST, PUT, PATCH e DELETE. Como regra geral dos documentos: se a solicitação apenas carrega parâmetros e nenhum corpo, GET é preferido; se enviar um arquivo como multipart/form-data, POST é a escolha usual.
Para o corpo da solicitação, o ShareX oferece vários tipos para que ele possa corresponder ao que seu endpoint espera:
- Sem corpo — apenas parâmetros.
- Form data (multipart/form-data) — a escolha típica para fazer upload de um arquivo.
- Form URL encoded (application/x-www-form-urlencoded).
- JSON (application/json).
- XML (application/xml).
- Binary — o arquivo bruto como corpo.
A documentação da API do seu servidor diz qual método e tipo de corpo espera; você está simplesmente espelhando isso na definição do ShareX.
Analisando a resposta: onde está o link?
Após o upload, seu endpoint responde — geralmente com JSON, XML ou texto simples — e você precisa dizer ao ShareX qual campo contém a URL final. ShareX oferece quatro maneiras de extraí-la:
- JSON usando sintaxe JsonPath, por exemplo,
{json:data.link}para lerdata.linkde uma resposta JSON. - XML usando XPath, por exemplo,
{xml:/files/file[1]/url}. - Regex para correspondência de padrão de uma resposta texto simples.
- Headers para ler um URL retornado em um header de resposta.
Este é o passo que as pessoas mais frequentemente acertam errado: o upload é bem-sucedido, mas o "URL" que o ShareX copia está vazio ou malformado porque o parser aponta para o campo errado. Quando isso acontece, olhe para a resposta bruta que seu servidor retorna e rastreie o caminho exato para a string de URL.
Step-by-step: uma configuração limpa
- Leia a documentação da API do seu endpoint e observe o método, o tipo de corpo, o nome do campo para o arquivo, qualquer header de autenticação e a localização exata do URL na resposta.
- Faça backup de suas configurações atuais do ShareX primeiro. Exporte sua configuração de destino existente para que você possa reverter se uma mudança se comportar mal.
- Crie o carregador personalizado em ShareX (Destinos → Configurações de carregador personalizado). Configure o método de solicitação, URL de destino, headers e tipo de corpo para corresponder ao seu endpoint.
- Configure o parser de resposta usando a JsonPath, XPath, regex ou regra de header correta para que o ShareX retorne o URL correto.
- Teste com uma captura inofensiva — uma imagem descartável — e confirme que o link retornado realmente abre o arquivo.
- Verifique o comportamento de exclusão/retenção se seu endpoint suporta exclusão, para que você saiba como remover um upload posteriormente.
- Configure-o como seu destino ativo apenas uma vez que um link de teste real funciona de ponta a ponta.
Compartilhando e reutilizando configs: arquivos .sxcu
Uma carregador personalizado terminado pode ser exportado como um .sxcu arquivo. Outro usuário pode importá-lo clicando duas vezes no arquivo, e o ShareX aplica a configuração de destino automaticamente. Isso torna fácil compartilhar uma configuração funcionando entre suas próprias máquinas ou com uma equipe — mas é exatamente onde os segredos vazam, então leia a próxima seção antes de enviar um para qualquer pessoa.
Proteja seus segredos
Um carregador personalizado geralmente contém chaves de API, tokens ou credenciais assinadas. Trate um .sxcu arquivo como uma senha:
- Antes de compartilhar uma config, remova ou substitua credenciais reais com placeholders. Um
.sxcuvocê publica publicamente pode expor uma chave ao vivo. - Prefira tokens com escopo e revogáveis sobre chaves mestras de longa vida, então um vazamento é contido e fácil de rotacionar.
- Sempre envie sobre HTTPS para que credenciais e arquivos não sejam enviados em texto claro.
- Rotacione qualquer coisa que pode ter sido exposta — capturas e suas configs viajam mais do que você espera.
Prefira um destino integrado quando houver um
Se seu armazenamento é Amazon S3, Google Cloud Storage ou Cloudflare R2, use o guia integrado dedicado do ShareX para esse provedor em vez de construir uma solicitação HTTP genérica à mão. Os destinos integrados lidam com a assinatura específica do provedor e configuração de domínio personalizado para você, o que significa menos peças móveis e menos lugares para cometer um erro. Reserve o carregador personalizado genérico para endpoints que não têm uma opção integrada.
Se você prefere não configurar manualmente solicitações
O carregador personalizado é poderoso precisamente porque é totalmente configurável — essa flexibilidade é o ponto, e para auto-hospedadores é ideal. Se você gosta de possuir seu armazenamento mas prefere apontar e selecionar um backend em vez de escrever solicitações HTTP e parsers de resposta, uma configuração mais orientada pode economizar tempo. Maxisnap Studio, um upgrade único, adiciona backends de upload personalizados — SFTP, FTP, S3-compatível e HTTP — para que suas capturas do Windows façam upload para armazenamento que você controla com um fluxo de configuração mais simples. É um trade-off diferente do construtor de solicitações totalmente aberto do ShareX, voltado para pessoas que querem propriedade sem o detalhe do nível de solicitação. Você pode ver como as opções de upload do Maxisnap estão estruturadas no Upload por SFTP e Upload para S3 / R2 páginas ou leia a mais ampla Visão geral de Maxisnap e ShareX.
ShareX é marca registrada de seu respectivo proprietário; Amazon S3, Google Cloud Storage e Cloudflare R2 são marcas registradas de seus respectivos proprietários. Os detalhes dos recursos do ShareX foram verificados contra a documentação oficial do ShareX em 17 de agosto de 2026 e podem mudar. Maxisnap é um produto independente e não é afiliada, endossada ou patrocinada por nenhum desses projetos ou empresas.