Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 14063 invoked by uid 6000); 3 Dec 1999 16:02:41 -0000 Received: (qmail 14024 invoked from network); 3 Dec 1999 16:02:40 -0000 Received: from ss01.nc.us.ibm.com (HELO 32.97.136.231) (32.97.136.231) by taz.hyperreal.org with SMTP; 3 Dec 1999 16:02:39 -0000 Received: from us.ibm.com (unverified [9.37.76.77]) by johngalt.raleigh.ibm.com (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 03 Dec 1999 11:08:52 -0500 Message-ID: <3847E9F7.CC54B419@us.ibm.com> Date: Fri, 03 Dec 1999 11:04:07 -0500 From: Greg Ames X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: OS/390 Translation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Status: O > Using '\n' would definitely cause problems for TPF and BS2000 (both EBCDIC > machines). Hmmm, I checked '\n' on OS/390 and got 0x15. That works, because running it thru the standard ascii conversion produces 0x0a ( \012) which is \n in the most of the ascii world, and is the desired result. What is '\n' on TPF and BS2000? My goal is to provide Apache support for EBCDIC content in charsets that don't map to ISO-8859-1. I'm thinking that replacing most of the \012 strings with something more portable will simplify that task. Greg Ames