![ASCII Table and Extended ASCII Table (in link description) [1024x723 - 206KB]](https://pic8.co/sh/7ZtGEu.jpg){kind=link}
Thanks for the heads up. Hashing function must resolve to the same value fo the two images.
Thanks for the heads up. Hashing function must resolve to the same value fo the two images.
ASCII Table - https://pic8.co/sh/7ZtGEu.jpg
Extended ASCII Table - https://files.catbox.moe/w62lkh.jpg
Note: Catbox link for Extended ASCII Table since Pic8 thinks they are the same image. @Picman
ASCII Table - https://pic8.co/sh/7ZtGEu.jpg
Extended ASCII Table - https://files.catbox.moe/w62lkh.jpg
Note: Catbox link for Extended ASCII Table since Pic8 thinks they are the same image. @Picman
Do any present day software engineers use the table anymore? I remember referring to the table many, many times about 40 years ago. I think it was file transfer protocols and rs232 or gpib related.
Do any present day software engineers use the table anymore? I remember referring to the table many, many times about 40 years ago. I think it was file transfer protocols and rs232 or gpib related.
I often refer to the ASCII table when helping younger software developers understand why some non-printable characters are interfering with their data conversion. They often have no idea that there are control characters that can creep into their data from external data sources that may throw off their data parsing.
I recently helped one guy discover why the system he was sending data to in XML format was rejecting files. His data contained an EOT (End Of Text) character that the receiving system didn't like. He spent a lot of time trying to figure out what was wrong with no good results. When I saw the error he was getting from the receiving system, I opened his XML in a Hex editor and discovered the EOT char in the element the error referred to. Added a filter for ASCII chars below 32 (with the exception of 10 LF and 13 CR of course) and he was back up and running.
I often refer to the ASCII table when helping younger software developers understand why some non-printable characters are interfering with their data conversion. They often have no idea that there are control characters that can creep into their data from external data sources that may throw off their data parsing.
I recently helped one guy discover why the system he was sending data to in XML format was rejecting files. His data contained an EOT (End Of Text) character that the receiving system didn't like. He spent a lot of time trying to figure out what was wrong with no good results. When I saw the error he was getting from the receiving system, I opened his XML in a Hex editor and discovered the EOT char in the element the error referred to. Added a filter for ASCII chars below 32 (with the exception of 10 LF and 13 CR of course) and he was back up and running.
Oh how quickly it comes back to me! Yes, I had similar problems back in the day (early 1980s) when we came out of the dark ages and performed the monumental task of automating the test floor; which required centralized test program libraries. Back then, the various "newer" test platforms had rs232 and/or gpib transfer capability. Good times!
Oh how quickly it comes back to me! Yes, I had similar problems back in the day (early 1980s) when we came out of the dark ages and performed the monumental task of automating the test floor; which required centralized test program libraries. Back then, the various "newer" test platforms had rs232 and/or gpib transfer capability. Good times!
(post is archived)