Envolver cada linha com texto

Entrada vazia ou só de espaços é rejeitada com um erro invalid_input claro para que um formulário em branco nunca pareça um envelopamento bem-sucedido. O caminho é lógica de string pura e determinística—sem rede, sem sementes aleatórias, sem dependência de relógio—assim o executor gratuito do navegador e a API pré-paga devolvem o mesmo JSON sempre que você a chama.

O que significa envolver cada linha e quando isso ajuda

Os padrões usam uma aspa dupla reta dos dois lados, de modo que três nomes viram três nomes entre aspas, prontos para colar em JSON, CSV ou um arquivo de configuração. Quando skip_empty é true, uma linha de comprimento zero permanece vazia para que os vãos de parágrafo sobrevivam enquanto as linhas com conteúdo são envolvidas. Entrada inteira vazia ou só de espaços é erro duro: não há documento envolvido significativo a devolver, e quem chama deve tratar isso como invalid_input e não como sucesso de zero linhas.

Como chamar a API e o que a resposta contém

Quando você passa uma string vazia explícita de um lado, esse lado permanece vazio para que possa prefixar só ou sufixar só. Se os dois lados resultarem strings vazias, a chamada é rejeitada, porque envolver com nada não é um envelopamento. Prefira enviar o corpo multilinha bruto em vez de unir tudo de antemão quando quiser semântica real por linha. Envie um corpo JSON com um campo string obrigatório text (aliases input, value, string, s, content e body). Inclua de forma opcional prefix (aliases pre e left) e suffix (aliases post e right) como strings de no máximo sessenta e quatro caracteres cada, e skip_empty (aliases skip_blank, ignore_empty e skip_blanks) como boolean. Quando prefix ou suffix é omitido, cada um assume por padrão uma aspa dupla reta. O valor de text deve ser não vazio após o trim geral de espaços e não deve exceder cem mil caracteres, para que uma única requisição não esgote a memória do Worker ou do navegador com pastes enormes. Em sucesso a resposta ecoa input como a string original enviada, text como o resultado totalmente envolvido unido com LF, prefix e suffix como os afixos efetivos, skip_empty como o flag efetivo, line_count como o número de segmentos após o split, wrapped_count como quantos desses segmentos de fato receberam os afixos, lines como um array ordenado das strings envolvidas, e message como um resumo curto em inglês. Validação falha—text ausente, valor que não é string, payload grande demais, conteúdo vazio após o trim geral, afixo que não é string ou é grande demais, ambos os afixos vazios ou um skip_empty que não é boolean—retorna invalid_input e nunca é cobrada. O preço é um US$ 0,002 fixo por requisição bem-sucedida com unidade item. Ao integrar, asserte em text ou lines para o conteúdo envolvido, em wrapped_count quando skip_empty entra em jogo, e trate invalid_input como bug do cliente em envios de formulário em branco e não como evento de cobrança.

Dicas práticas, limites e buscas relacionadas

Defina prefix como um sinal de maior que e um espaço com suffix vazio para transformar notas em uma citação de bloco de markdown. Defina prefix como uma tag de item de lista de abertura e suffix como a tag de fechamento correspondente para montar linhas de marcação. Checagens de ida e volta para testes são fáceis: envie três linhas curtas e espere três linhas entre aspas com line_count três e wrapped_count três; envie uma linha em branco entre duas palavras com skip_empty true e espere que a linha do meio permaneça vazia; envie de propósito string vazia ou só espaços para confirmar invalid_input e a mensagem que pede uma string não vazia; envie prefix vazio e suffix vazio juntos para confirmar a rejeição dos dois vazios. Lembre-se das quebras finais intencionais: um LF final cria um último segmento vazio que é envolvido a menos que skip_empty seja true. Tarefas falhas que retornam invalid_input não consomem saldo pré-pago, o que mantém barata a validação de formulários e testes negativos de CI.