The Daily WTF: Curious Perversions in Information Technology
Welcome to TDWTF Forums Sign in | Join | Help
in Search

Character encoding

Last post 04-05-2012 4:53 PM by morbiuswilters. 55 replies.
Page 1 of 2 (56 items) 1 2 Next >
Sort Posts: Previous Next
  • 04-02-2012 6:08 PM

    Character encoding

    So we're testing some new functionality, to make our systems work with Initrode's by exchanging XML messages.  Initrode sends us an initialization message (over 40 MB of XML) containing the initial state of their data so our system can sync up.  The message begins with:

    <?xml version="1.0"?>

    No encoding info.  According to the XML standard, that means it's supposed to be in UTF-8.  But our XML parser chokes and dies on several places in the message, stuff like accented characters and em-dashes.  So I pull out my trusty hex editor and find out that the whole thing is encoded in ISO-8859-1; they just neglected to mention that in the actual XML message!

    So we write to Initrode requesting that if they're going to use characters outside the ANSI range, to please ensure that their XML message is tagged with the proper encoding attribute, and describing which entries were causing problems.

    A few days later, we get back a response from Initrode's developers containing a small XML snippet and saying that it looks like proper UTF-8 to them, that they're able to open the file just fine with no encoding attribute and they're not sure what our problem is.  And lo and behold, the hex editor reveals that the special characters in this new version *are* UTF-8 encoded, where the old one was not.  So they're either trying to pull a fast one or too technically ignorant to be working in this problem space.

    It's getting on towards 10 years now since Joel wrote The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).  And even if they haven't seen that particular article, you'd at least think developers working with accented characters would have absorbed this knowledge one way or another by now... and yet stuff like this still happens.


    [mod - fixed link; removed trailing space - PJH]
  • 04-02-2012 6:38 PM In reply to

    Re: Character encoding

    Are you getting this over HTTP? Because it should be valid for the encoding to be set in the headers. Although, it's still a good idea for it to be included in the declaration, too.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-02-2012 6:46 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Are you getting this over HTTP? Because it should be valid for the encoding to be set in the headers. Although, it's still a good idea for it to be included in the declaration, too.

    No, it's actually being generated by their program and written out to a specific folder as a text file, to be read in by our program.  (Long story.  We can accept HTTP, and we do in various other integrations, but their system can't handle it.)

  • 04-02-2012 8:00 PM In reply to

    Re: Character encoding

    This means they must have hand-rolled an XML library. I love it when people spend extra time to make something broken.

    Something similar happened to me a few years ago when another department asked me for an example file, which I provided for them in UTF-16 encoding with a proper declaration. They then created their output by parroting my example and ended up generating a UTF-8 XML file with UTF-16 encoding specified in the declaration. Any attempt to tell them what was wrong was met with blank stares.

  • 04-02-2012 8:15 PM In reply to

    Re: Character encoding

    Fuck it, everybody in the world just needs to learn to speak ASCII.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-02-2012 8:16 PM In reply to

    Re: Character encoding

    I've had similar happen with teams using PHP trying to write their own SOAP client.  Spend half a day tracking down an extra space before the "<?xml" about a week or so ago, hidden somewhere. 

    Another instance we changed the generation of the XML to use the proxy generated by .Net (as opposed to the previous hand-rolled we had), and a client broke because the prefix on the namespace changed (i.e. xmlns:ns1 -> xmlns:ns2).  Trying to explain how namespaces worked was like pulling teeth.  Yay string searches for "<ns1:NodeName"!!

  • 04-02-2012 8:21 PM In reply to

    Re: Character encoding

    Sutherlands:
    I've had similar happen with teams using PHP trying to write their own SOAP client.  Spend half a day tracking down an extra space before the "<?xml" about a week or so ago, hidden somewhere. 
    Probably someone with whitespace after the closing ?> tag. I never use closing tags in PHP-only files precisely for this reason.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-02-2012 9:27 PM In reply to

    Re: Character encoding

    Sutherlands:
    Another instance we changed the generation of the XML to use the proxy generated by .Net (as opposed to the previous hand-rolled we had), and a client broke because the prefix on the namespace changed (i.e. xmlns:ns1 -> xmlns:ns2).  Trying to explain how namespaces worked was like pulling teeth.  Yay string searches for "<ns1:NodeName"!!
    At least you only changed the namespace prefix - not the fucking namespace. Announced by email on the day after the rollout. On a web service consumed by thousands of mission-critical, SLA-protected applications with millions of dollars in hourly penalties payable to external customers. In response to a dev team that couldn't figure out how to work with two variations on the same subtree with the same root element name and same namespacebut different combinations of subnode. (No, I don't have ANY idea how anyone who has any idea how XML works or is even rolling their own parser could screw that up)

     

    My Monday was awesome.

  • 04-03-2012 12:03 AM In reply to

    Re: Character encoding

    Lol Weng.
  • 04-03-2012 12:17 AM In reply to

    Re: Character encoding

    That's nothing! We got cp1251 sent either as utf8 or iso-8859-15. Their machines were configured to use only cp1251 so everything worked there... On the other hand mostly everyone else did they homework and used the proper encoding hint.
  • 04-03-2012 6:08 AM In reply to

    • ender
    • Top 50 Contributor
    • Joined on 04-27-2006
    • Sunny side of the Alps
    • Posts 1,405

    Re: Character encoding

    Speaking of encodings, I'm always surprised how some services manage to mangle č's in my last name to è's or e's (I'm looking at you, Microsoft) - this implies that the text gets stored as cp1250 somewhere and then read as cp1252, though I can't fathom how that happens.
    Because 10 billion years' time is so fragile, so ephemeral... it arouses such a bittersweet, almost heartbreaking fondness.
  • 04-03-2012 9:37 AM In reply to

    Re: Character encoding

    Weng:
    Announced by email on the day after the rollout. On a web service consumed by thousands of mission-critical, SLA-protected applications with millions of dollars in hourly penalties payable to external customers.
     

    I'd like to think that the response to this email was "You fucked up royally. Roll it back NOW," and they did, but a team that couldn't foresee the problems of what they did probably doesn't have anything in place that would allow them to do a clean rollback.

     

  • 04-03-2012 1:00 PM In reply to

    • tchize
    • Top 200 Contributor
    • Joined on 07-26-2006
    • Belgium
    • Posts 301

    Re: Character encoding

    I had to deal with an application that generated xml with encoding information set to "ISO-8859-1" but actually encoded in CP1252. According to original dev "CP1252 is pretty much the same as iso" :'(

  • 04-03-2012 1:04 PM In reply to

    Re: Character encoding

    tchize:
    According to original dev "CP1252 is pretty much the same as iso" :'(
    In MySQL, it's exactly the same.. D:

    You're next, Mars!
  • Morbs is the smartest!
  • 04-03-2012 1:40 PM In reply to

    Re: Character encoding

    morbiuswilters:
    ---- it, everybody in the world just needs to learn to speak ASCII.

    No, EBCDIC is superior <ducking>

  • 04-03-2012 1:44 PM In reply to

    Re: Character encoding

    TheCPUWizard:

    morbiuswilters:
    ---- it, everybody in the world just needs to learn to speak ASCII.

    No, EBCDIC is superior <ducking>

    Yeah, but EBCDIC isn't easy to pronounce. It's like the last name of one of them brides you can buy from Europe. "I Tatanya Ebcdic, me love you long time.."

    You're next, Mars!
  • Morbs is the smartest!
  • 04-03-2012 3:08 PM In reply to

    Re: Character encoding

    Another XML/character encoding gripe: Why is it that, if the default encoding for XML is UTF-8, that Microsoft's XML parser will throw an error if the document it's trying to parse begins with a bloody UTF-8 BOM?!?

  • 04-03-2012 3:55 PM In reply to

    • ender
    • Top 50 Contributor
    • Joined on 04-27-2006
    • Sunny side of the Alps
    • Posts 1,405

    Re: Character encoding

    Because having the BOM in UTF-8 files is an abomination (and specifically, because there must be nothing before <? in xml files)
    Because 10 billion years' time is so fragile, so ephemeral... it arouses such a bittersweet, almost heartbreaking fondness.
  • 04-03-2012 3:59 PM In reply to

    Re: Character encoding

    Mason Wheeler:

    Another XML/character encoding gripe: Why is it that, if the default encoding for XML is UTF-8, that Microsoft's XML parser will throw an error if the document it's trying to parse begins with a bloody UTF-8 BOM?!?



    A better question would be: Why are you using a BOM if UTF-8 is the expected default?  UTF-8 doesn't require a BOM unless the default is ISO-8859.

    I've seen lots of stuff that bombs if UTF-8 is being used with a BOM.  SourceMod's translation system, for example.

     

  • 04-03-2012 4:02 PM In reply to

    Re: Character encoding

    powerlord:
    UTF-8 doesn't require a BOM unless the default is ISO-8859.
    I don't understand this sentence.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-03-2012 4:05 PM In reply to

    Re: Character encoding

    ender:
    Because having the BOM in UTF-8 files is an abomination (and specifically, because there must be nothing before <? in xml files)
    Are you sure about that?
    W3C Recommendation 04 February 2004, edited in place 15 April 2004:

    Entities encoded in UTF-16 must and entities encoded in UTF-8 may begin with the Byte Order Mark described in ISO/IEC 10646 [ISO/IEC 10646] or Unicode [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature, not part of either the markup or the character data of the XML document. XML processors must be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents.

    this post is bossy
  • 04-03-2012 4:06 PM In reply to

    Re: Character encoding

    powerlord:
    I've seen lots of stuff that bombs if UTF-8 is being used with a BOM.
    Yay, bugs!
    this post is bossy
  • 04-03-2012 4:07 PM In reply to

    Re: Character encoding

    ender:
    Because having the BOM in UTF-8 files is an abomination (and specifically, because there must be nothing before <? in xml files)
    BOM is permitted in UTF-8 XML. It comes before the <?xml and parsers should be able to handle it. Also, I thought a lot of Microsoft tools added a BOM to UTF-8 files, so it's weird their parser can't work with that.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-03-2012 5:16 PM In reply to

    Re: Character encoding

    rest of the message that the forum ate.
  • 04-03-2012 5:22 PM In reply to

    Re: Character encoding

    henke37:
    rest of the message that the forum ate.
    Shit, I forgot to encode my entities! Fixed now.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-04-2012 11:58 AM In reply to

    Re: Character encoding

    Jaime:

    This means they must have hand-rolled an XML library. I love it when people spend extra time to make something broken.

    I wouldn't give them that much credit-- they're probably just generating the XML via string concatenation.


    Information technology not available until further notice. The political trolls won. Wake me up when the discussion is more interesting then YouTube comments.

  • 04-04-2012 12:44 PM In reply to

    Re: Character encoding

    MiffTheFox:
    Jaime:

    This means they must have hand-rolled an XML library. I love it when people spend extra time to make something broken.

    I wouldn't give them that much credit-- they're probably just generating the XML via string concatenation.

    It depends on the circumstances, but I'd say there are definitely times when string concatenation is the superior solution. Although I would prefer to avoid XML altogether.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-04-2012 4:25 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Yeah, but EBCDIC isn't easy to pronounce.
    How is it hard? Ibby C. Dick.
    ╩юфют√ь ёЄЁрэшЎрь яюЁр эр яхэёш■.

    #TDWTF @ SlashNET was merged into #codelove @ the same network. You're still welcome to drop by. I guess.
  • 04-04-2012 4:27 PM In reply to

    Re: Character encoding

    Spectre:
    morbiuswilters:
    Yeah, but EBCDIC isn't easy to pronounce.
    How is it hard? Ibby C. Dick.
    I don't know where you got "Ibby". Ebb C Dick would be appropriate, but it doesn't flow off the tongue as neatly as ass-key.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-04-2012 6:22 PM In reply to

    Re: Character encoding

    I got your ASCII right here.

    Prepare to be boarded.


    In complex analysis, a meromorphic function on an open subset D of the complex plane is a function that is holomorphic on all D except a set of isolated points

  • 04-04-2012 7:22 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Spectre:
    morbiuswilters:
    Yeah, but EBCDIC isn't easy to pronounce.
    How is it hard? Ibby C. Dick.
    I don't know where you got "Ibby".
    Just spell EB out.
    ╩юфют√ь ёЄЁрэшЎрь яюЁр эр яхэёш■.

    #TDWTF @ SlashNET was merged into #codelove @ the same network. You're still welcome to drop by. I guess.
  • 04-04-2012 7:39 PM In reply to

    Re: Character encoding

    As if it wasn't bad enough that XML is used in the way a bad carpernter uses a hammer for every job, people who write specs where vital file information isn't actually contained in the file itself but is considered "valid enough" in the transmission protocol wrapper need to be shot.

    XML is supposed to be portable, and HTTP isn't the only transmission protocol used to move it around from one place to another. FTP and it's secure counterparts SCP and SFTP don't send headers, what you get is the actual file, nothing more.

    It's the same kind of idiocy where text documents are generated containing UTF-8 or UTF-16 and they neglect to include a BOM header, so upon receipt of the file we have to do all kinds of fancy scanning to determine if any character in the file *might* be encoded in one of multiple flavors before we can even start to use it.

    If there's no encoding specified in the file, it should be rejected as invalid on general principles. If more people did this, maybe the people creating these files would be forced to show a little disciple. Hell, if you've already wrapped 8 bytes of data in 5k of unneccessary XML "wrapper", what's an extra 20 bytes to specify the encoding too ?

    The real WTF is that it takes 60 seconds to post a message on this board and then the error message asks YOU who the site administrator is, because apparently the site administrator doesn't know.
  • 04-04-2012 9:10 PM In reply to

    Re: Character encoding

    daveime:
    As if it wasn't bad enough that XML is used in the way a bad carpernter uses a hammer for every job, people who write specs where vital file information isn't actually contained in the file itself but is considered "valid enough" in the transmission protocol wrapper need to be shot.
    Is this your first experience with a W3C spec? Because XML is one of the better thought-out ones.. I'd favor shooting them, but they'd probably get off on it, the sick bastards.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 5:26 AM In reply to

    Re: Character encoding

    morbiuswilters:
    daveime:
    As if it wasn't bad enough that XML is used in the way a bad carpernter uses a hammer for every job, people who write specs where vital file information isn't actually contained in the file itself but is considered "valid enough" in the transmission protocol wrapper need to be shot.
    Is this your first experience with a W3C spec? Because XML is one of the better thought-out ones.. I'd favor shooting them, but they'd probably get off on it, the sick bastards.

    I think he was referring to people that write schema/DTDs (or the specs for one) for some XML, rather than write the W3C XML specs themselves.

    I've had this very issue - XML rejected by the customer because it was missing some other information, but their schema claimed it to be valid... because the schema said this information was optional and I omitted it. So I asked for a revised schema, added in missing content, validated it against this new XSD and all was fine, until they complained that something else was missing...

    When I asked what was wrong with the XML I sent, they responded with some reformatted XML of mine containing additional elements but lacking all the comments and formatting of mine. Right. Let's respond to the question with an example but no explanation, that ought to clear it up. Yet my XML still "passed" their updated schema.

    Grrrr....

  • 04-05-2012 9:34 AM In reply to

    Re: Character encoding

    Cassidy:

    morbiuswilters:
    daveime:
    As if it wasn't bad enough that XML is used in the way a bad carpernter uses a hammer for every job, people who write specs where vital file information isn't actually contained in the file itself but is considered "valid enough" in the transmission protocol wrapper need to be shot.
    Is this your first experience with a W3C spec? Because XML is one of the better thought-out ones.. I'd favor shooting them, but they'd probably get off on it, the sick bastards.

    I think he was referring to people that write schema/DTDs (or the specs for one) for some XML, rather than write the W3C XML specs themselves.

    I don't.
    ╩юфют√ь ёЄЁрэшЎрь яюЁр эр яхэёш■.

    #TDWTF @ SlashNET was merged into #codelove @ the same network. You're still welcome to drop by. I guess.
  • 04-05-2012 10:14 AM In reply to

    Re: Character encoding

    Spectre:
    Cassidy:
    I think.
    I don't.

    Might explain quite a few things <grin>

  • 04-05-2012 12:27 PM In reply to

    Re: Character encoding

    Cassidy:
    I think he was referring to people that write schema/DTDs (or the specs for one) for some XML, rather than write the W3C XML specs themselves.
    No, he was referring to the fact that XML doesn't require an encoding be specified in-band. Specifically, you can specify the encoding in HTTP headers but leave it out of the XML itself. (I always include it in both headers and inline.) Combined with the fact that UTF-8 BOM is optional and determining encoding becomes much more difficult (hence his comment about having to scan the document looking for certain byte sequences that might indicate encoding). This is all valid according to the W3C. It's also the most sensible spec to come out of the W3C.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 12:43 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Cassidy:
    I think he was referring to people that write schema/DTDs (or the specs for one) for some XML, rather than write the W3C XML specs themselves.
    No, he was referring to the fact that XML doesn't require an encoding be specified in-band. Specifically, you can specify the encoding in HTTP headers but leave it out of the XML itself. (I always include it in both headers and inline.) Combined with the fact that UTF-8 BOM is optional and determining encoding becomes much more difficult (hence his comment about having to scan the document looking for certain byte sequences that might indicate encoding). This is all valid according to the W3C. It's also the most sensible spec to come out of the W3C.

    It seems to make sense to me.

    1. If the first two bytes are a BOM, then read it, note the endianness, and subsequently ignore it.
    2. If there is an encoding specified, use that encoding.
    3. If there is no encoding specified, use UTF-8.

    It's not as though the encoding is undefined if missing. The problem is people who don't understand the spec, and assume different defaults.

  • 04-05-2012 12:44 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Spectre:
    morbiuswilters:
    Yeah, but EBCDIC isn't easy to pronounce.
    How is it hard? Ibby C. Dick.
    I don't know where you got "Ibby". Ebb C Dick would be appropriate, but it doesn't flow off the tongue as neatly as ass-key.
    I've always just said "ebb-kuh-dick".

    Information technology not available until further notice. The political trolls won. Wake me up when the discussion is more interesting then YouTube comments.

  • 04-05-2012 12:51 PM In reply to

    Re: Character encoding

    pkmnfrk:

    It seems to make sense to me.

    1. If the first two bytes are a BOM, then read it, note the endianness, and subsequently ignore it.
    2. If there is an encoding specified, use that encoding.
    3. If there is no encoding specified, use UTF-8.

    It's not as though the encoding is undefined if missing. The problem is people who don't understand the spec, and assume different defaults.

    The first three bytes might be a BOM. Also, the problem is with default encodings. Do you people need this spelled out for you? The spec sucks (among other reasons) because it does not enforce consistency. There should always be an encoding explicitly specified and it should be a fatal error to not have one.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 12:59 PM In reply to

    Re: Character encoding

    morbiuswilters:
    No, he was referring to the fact that XML doesn't require an encoding be specified in-band

    Ah, okay. I've always included it inline as the "final say" in case something happens to the encoding part-way.

    morbiuswilters:
    (I always include it in both headers and inline.)

    What if there's a conflict between the two?

  • 04-05-2012 1:18 PM In reply to

    Re: Character encoding

    Cassidy:

    morbiuswilters:
    (I always include it in both headers and inline.)

    What if there's a conflict between the two?

    There won't be because I'm not incompetent.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 1:30 PM In reply to

    Re: Character encoding

    morbiuswilters:
    Cassidy:

    morbiuswilters:
    (I always include it in both headers and inline.)

    What if there's a conflict between the two?

    There won't be because I'm not incompetent.
    But some of the people I work with are, so what do I do?
  • 04-05-2012 1:40 PM In reply to

    Re: Character encoding

    Sutherlands:

    morbiuswilters:
    There won't be because I'm not incompetent.
    But some of the people I work with are, so what do I do?

    That was my question: I'm not making the assumption that you're always going to be in control of the feed (that there could be someone that farted around with a webserver config and now headers are tainted, etc) or that it's actually originating from you but from someone who also had a similar belt-n-braces approach.

    It's more the point of: if someone receives two items of data that conflict, which would take priority? I'd have thought the embedded XML declaration would win overall.

  • 04-05-2012 2:02 PM In reply to

    Re: Character encoding

    Sutherlands:

    morbiuswilters:
    Cassidy:

    morbiuswilters:
    (I always include it in both headers and inline.)

    What if there's a conflict between the two?

    There won't be because I'm not incompetent.
    But some of the people I work with are, so what do I do?
    What do you do if they can't figure out their pants zipper and piss all over the bathroom wall? Are you allowed to punch them until they learn? I really don't know, I don't spend my days babysitting retarded people.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 2:09 PM In reply to

    Re: Character encoding

    Cassidy:
    It's more the point of: if someone receives two items of data that conflict, which would take priority? I'd have thought the embedded XML declaration would win overall.
    In a sensible spec, the inline encoding would be used. This is a W3C spec, however, so they just punted: basically it depends on whatever transport protocol is used. So for HTTP we refer to RFC 3023. Other transport protocols may have their own rules.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 2:52 PM In reply to

    • PJH
    • Top 10 Contributor
    • Joined on 02-14-2007
    • Newcastle, UK
    • Posts 3,837

    Re: Character encoding

    Sutherlands:

    morbiuswilters:
    Cassidy:

    morbiuswilters:
    (I always include it in both headers and inline.)

    What if there's a conflict between the two?

    There won't be because I'm not incompetent.
    But some of the people I work with are, so what do I do?
    Wouldn't the sensible (hah!) thing to do would be to use the most recent specification? i.e. use the one in the headers if specified, and replace it with the one inline if one is specified?
    "Because you watched 'The Very Hungry Caterpillar,' we recommend 'The Human Centipede.'"
    --
    UED - Countryside: To kill Piers Morgan
  • 04-05-2012 3:03 PM In reply to

    Re: Character encoding

    PJH:
    Wouldn't the sensible (hah!) thing to do would be to use the most recent specification? i.e. use the one in the headers if specified, and replace it with the one inline if one is specified?
    HTTP headers take precedence over inline declarations. The theory being that the server may transcode the data without altering the declaration.

    You're next, Mars!
  • Morbs is the smartest!
  • 04-05-2012 3:36 PM In reply to

    Re: Character encoding

    morbiuswilters:
    PJH:
    Wouldn't the sensible (hah!) thing to do would be to use the most recent specification? i.e. use the one in the headers if specified, and replace it with the one inline if one is specified?
    HTTP headers take precedence over inline declarations. The theory being that the server may transcode the data without altering the declaration.
    This shows why putting the encoding in the document is so stupid.  Any time an XML document is stored or transmitted, there is a risk that it will be transcoded.  The likelihood of the software responsible for transmitting/storing being "XML aware" and fixing the document is quite low.  It's not like this is a new problem the the W3C couldn't have expected, FTP implementions are infamous for causing problems by doing improper CRLF translations.

  • 04-05-2012 3:41 PM In reply to

    Re: Character encoding

    Jaime:
    This shows why putting the encoding in the document is so stupid.  Any time an XML document is stored or transmitted, there is a risk that it will be transcoded.  The likelihood of the software responsible for transmitting/storing being "XML aware" and fixing the document is quite low.
    Transmit? Sure. Store? Seems unlikely. But, see, the problem here is software that transcodes my data. Why are you doing that? You shouldn't be doing that (or if you absolutely must you should be XML-aware so you can make the appropriate change to the document).

    Jaime:
    It's not like this is a new problem the the W3C couldn't have expected, FTP implementions are infamous for causing problems by doing improper CRLF translations.
    I haven't used FTP for, like, 14 years, so I'll take your word on it. Also, the problem sounds like the CRLF translations: why are you doing that? Stop doing that.

    You're next, Mars!
  • Morbs is the smartest!
Page 1 of 2 (56 items) 1 2 Next >
Powered by Community Server (Non-Commercial Edition), by Telligent Systems