Parece que você vai ter muitos problemas para contornar uma limitação (IMHO severa) no Bloco de Notas. Seria possível instalar um editor de texto mais inteligente no sistema, por ex. Notepad ++?
O problema: desejo veicular CRLF dos arquivos codificados como LF
Eu tenho um servidor web apache2 httpd baseado em linux configurado para servir arquivos de log (grandes) ( *.log ) gerados por um simulador baseado em linux.
Esses arquivos de log têm o estilo LF final em estilo Unix, em vez de CRLF no estilo Windows. CRLF também é o padrão para arquivos de texto no protocolo http .
Quando os visualizo usando um navegador no Windows, eles são carregados no Notepad.exe e todo o texto está (incorretamente) na mesma linha; a menos que eu renomeie os logs no servidor de
*.log para *.txt .
Parece que o Microsoft Windows provavelmente está manipulando *.txt especialmente, e convertendo os finais conforme eles chegam.
Dadas essas dicas, como posso alterar a configuração para que os usuários do cliente vejam os arquivos corretamente, independentemente de sua plataforma / navegador.
Mais detalhes sobre o problema: por que não consigo fazer a coisa óbvia
Analisando os registros, descubro que .txt é exibido como mime-type text/plain e .log como text/x-log , mas a comutação de .log para text/plain usando SetType não resolveu o problema .
Em um sistema de produção, não irei facilmente alterar os arquivos para finalizar em .txt .
Os registros são muito numerosos e grandes para que eu queira converter usando (por exemplo, unix2dos ) e salvar outra cópia. Isso também me forçaria a gerenciar um cache adicional de arquivos convertidos que precisariam ser invalidados, limpos etc, ou para alterar os arquivos originais, o que pode quebrar outros sistemas que os consomem.
LF para CRLF à medida que chega? LF por CRLF enquanto ele é usado? O que tentei
Eu olhei para o módulo do Apache mod_mime e suas diretivas AddType e AddCharset mas estes não corrigem o problema, nem mesmo afirmam.
A documentação do Apache é silenciosa na questão de fim de linha.
A documentação MIME no tipo text diz que o conteúdo deve estar no formato CRLF .
Também parece que a terminação de linha não é considerada pelos padrões de codificação do conjunto de caracteres.
Parece que você vai ter muitos problemas para contornar uma limitação (IMHO severa) no Bloco de Notas. Seria possível instalar um editor de texto mais inteligente no sistema, por ex. Notepad ++?
A solução (imperfeita) na qual me decidi é usar o mod_ext_filter do Apache:
ExtFilterDefine logwin mode=output cmd=/usr/bin/unix2dos intype=text/x-log
AddOutputFilter logwin .log
# Note that apache2 defines .log as having mime-type text/x-log by default.
Essencialmente, isso diz que para qualquer arquivo que termine em .log , ele deve ser passado por um conversor de finalização de linha antes da entrega ao cliente.
Esta não é uma ótima solução para máquinas muito carregadas, já que o fork unix2dos é mais lento do que o processo interno do Apache. Também requer conversão para cada leitura do arquivo, o que é ineficiente.
Infelizmente, a fundação apache não forneceu um filtro mod interno para este cenário e não tenho tempo para escrever / manter um.
No entanto, não espero alta carga nesta máquina, assim medida pelo esforço de engenharia, essa é uma boa solução.
mime specs para text / plain codificando CRLF no fio Tags encoding apache-2.2 http