S
Sami Sihvonen
Mel said:
I suspect it was the broken newsreader that can't handle charsets...
I suspect it was the broken newsreader that can't handle charsets...
G
Gary R. Schmidt
Now that makes more sense! I've see the "big typeface" effect on a fewBlinky said:Mel wrote:
There's no accounting for OE.
That's the only unusual one I saw; I wondered about that, too. Seem
more likely a culprit than the X-Face header.
messages, and they had X-Face headers, but I missed the "Content-Type"
headers.
So, it's down to the usual problem, people posting non-7-bit ASCII
messages in a newsgroup!!!
Cheers,
Gary B-)
D
Darrien
Are you sure about that?
Here's some ISO-2022-JP text, you can tell me yourself if it's plain 7-bit
ASCII or not.
$B;d$NL>A0$O%i%s%P!<%H$G$9(J
?
=?ISO-8859-1?Q?=BBQ=AB?=
Posting that, your headers should also have
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
D
Darrien
Why?
http://www.faqs.org/rfcs/rfc1468.html
---
MIME Considerations
The name given to the JUNET character encoding is "ISO-2022-JP". This
name is intended to be used in MIME messages as follows:
Content-Type: text/plain; charset=iso-2022-jp
The ISO-2022-JP encoding is already in 7-bit form, so it is not
necessary to use a Content-Transfer-Encoding header.
G
Gary R. Schmidt
But it's not ASCII. It is something that has been _encoded_ using ASCII.Darrien said:
Cheers,
Gary B-)
?
=?ISO-8859-1?Q?=BBQ=AB?=
Clearly, I was wrong about the 8-bit encoding. But in order to use the
Content-Type header to specify a charset, I believe you should specify
a MIME version, as per RFC 2045, no? Else aren't you stuck with the
more limited use of Content-Type under RFC 1049?
F
fLameDogg
Agreed. Like I said in the other thread, oops me. I just shouldn't
post on three hours' sleep :O)
F
fLameDogg
Well, that's what it gets for mixing mail and news anyhow :O)
Although, as others will hasten to point out, yes, other apps do that
but manage not to pollute news with HTML.
D
Darrien
An oversight on my part.
Fixed.
D
Darrien
But it's still using *7-bit* ASCII, not 8-bit ASCII, binary or something
else as you have implied above.
Splitting hairs doesn't negate the fact that you were wrong.
G
Gary R. Schmidt
Darrien wrote:
[SNIP]
that are defined by the American Standard Code for Information
Interchange, and that does not allow for hiregana or katakana or Latin-1
or Cyrillic characters.
At the end of this message is an extract from a man page on it,
admittedly taken from a Linux machine, that displays the character that
*are* representable in ASCII.
I can't see any hiragana or katakana characters in there, can you?
man page extract:
ASCII is the American Standard Code for Information Interchange. It is
a 7-bit code. Many 8-bit codes (such as ISO 8859-1, the Linux default
character set) contain ASCII as their lower half. The international
counterpart of ASCII is known as ISO 646.
The following table contains the 128 ASCII characters.
Oct Dec Hex Char Oct Dec Hex Char
------------------------------------------------------------
000 0 00 NUL 100 64 40 @
001 1 01 SOH 101 65 41 A
002 2 02 STX 102 66 42 B
003 3 03 ETX 103 67 43 C
004 4 04 EOT 104 68 44 D
005 5 05 ENQ 105 69 45 E
006 6 06 ACK 106 70 46 F
007 7 07 BEL 107 71 47 G
010 8 08 BS 110 72 48 H
011 9 09 HT 111 73 49 I
012 10 0A LF 112 74 4A J
013 11 0B VT 113 75 4B K
014 12 0C FF 114 76 4C L
015 13 0D CR 115 77 4D M
016 14 0E SO 116 78 4E N
017 15 0F SI 117 79 4F O
020 16 10 DLE 120 80 50 P
021 17 11 DC1 121 81 51 Q
022 18 12 DC2 122 82 52 R
023 19 13 DC3 123 83 53 S
024 20 14 DC4 124 84 54 T
025 21 15 NAK 125 85 55 U
026 22 16 SYN 126 86 56 V
027 23 17 ETB 127 87 57 W
030 24 18 CAN 130 88 58 X
031 25 19 EM 131 89 59 Y
032 26 1A SUB 132 90 5A Z
033 27 1B ESC 133 91 5B [
034 28 1C FS 134 92 5C \
035 29 1D GS 135 93 5D ]
036 30 1E RS 136 94 5E ^
037 31 1F US 137 95 5F _
040 32 20 SPACE 140 96 60 `
041 33 21 ! 141 97 61 a
042 34 22 " 142 98 62 b
043 35 23 # 143 99 63 c
044 36 24 $ 144 100 64 d
045 37 25 % 145 101 65 e
046 38 26 & 146 102 66 f
047 39 27 ' 147 103 67 g
050 40 28 ( 150 104 68 h
051 41 29 ) 151 105 69 i
052 42 2A * 152 106 6A j
053 43 2B + 153 107 6B k
054 44 2C , 154 108 6C l
055 45 2D - 155 109 6D m
056 46 2E . 156 110 6E n
057 47 2F / 157 111 6F o
060 48 30 0 160 112 70 p
061 49 31 1 161 113 71 q
062 50 32 2 162 114 72 r
063 51 33 3 163 115 73 s
064 52 34 4 164 116 74 t
065 53 35 5 165 117 75 u
066 54 36 6 166 118 76 v
067 55 37 7 167 119 77 w
070 56 38 8 170 120 78 x
071 57 39 9 171 121 79 y
072 58 3A : 172 122 7A z
073 59 3B ; 173 123 7B {
074 60 3C < 174 124 7C |
075 61 3D = 175 125 7D }
076 62 3E > 176 126 7E ~
077 63 3F ? 177 127 7F DEL
[SNIP]
No, you are wrong. 7-bit ASCII can _only_ display the set of characters
that are defined by the American Standard Code for Information
Interchange, and that does not allow for hiregana or katakana or Latin-1
or Cyrillic characters.
At the end of this message is an extract from a man page on it,
admittedly taken from a Linux machine, that displays the character that
*are* representable in ASCII.
I can't see any hiragana or katakana characters in there, can you?
man page extract:
ASCII is the American Standard Code for Information Interchange. It is
a 7-bit code. Many 8-bit codes (such as ISO 8859-1, the Linux default
character set) contain ASCII as their lower half. The international
counterpart of ASCII is known as ISO 646.
The following table contains the 128 ASCII characters.
Oct Dec Hex Char Oct Dec Hex Char
------------------------------------------------------------
000 0 00 NUL 100 64 40 @
001 1 01 SOH 101 65 41 A
002 2 02 STX 102 66 42 B
003 3 03 ETX 103 67 43 C
004 4 04 EOT 104 68 44 D
005 5 05 ENQ 105 69 45 E
006 6 06 ACK 106 70 46 F
007 7 07 BEL 107 71 47 G
010 8 08 BS 110 72 48 H
011 9 09 HT 111 73 49 I
012 10 0A LF 112 74 4A J
013 11 0B VT 113 75 4B K
014 12 0C FF 114 76 4C L
015 13 0D CR 115 77 4D M
016 14 0E SO 116 78 4E N
017 15 0F SI 117 79 4F O
020 16 10 DLE 120 80 50 P
021 17 11 DC1 121 81 51 Q
022 18 12 DC2 122 82 52 R
023 19 13 DC3 123 83 53 S
024 20 14 DC4 124 84 54 T
025 21 15 NAK 125 85 55 U
026 22 16 SYN 126 86 56 V
027 23 17 ETB 127 87 57 W
030 24 18 CAN 130 88 58 X
031 25 19 EM 131 89 59 Y
032 26 1A SUB 132 90 5A Z
033 27 1B ESC 133 91 5B [
034 28 1C FS 134 92 5C \
035 29 1D GS 135 93 5D ]
036 30 1E RS 136 94 5E ^
037 31 1F US 137 95 5F _
040 32 20 SPACE 140 96 60 `
041 33 21 ! 141 97 61 a
042 34 22 " 142 98 62 b
043 35 23 # 143 99 63 c
044 36 24 $ 144 100 64 d
045 37 25 % 145 101 65 e
046 38 26 & 146 102 66 f
047 39 27 ' 147 103 67 g
050 40 28 ( 150 104 68 h
051 41 29 ) 151 105 69 i
052 42 2A * 152 106 6A j
053 43 2B + 153 107 6B k
054 44 2C , 154 108 6C l
055 45 2D - 155 109 6D m
056 46 2E . 156 110 6E n
057 47 2F / 157 111 6F o
060 48 30 0 160 112 70 p
061 49 31 1 161 113 71 q
062 50 32 2 162 114 72 r
063 51 33 3 163 115 73 s
064 52 34 4 164 116 74 t
065 53 35 5 165 117 75 u
066 54 36 6 166 118 76 v
067 55 37 7 167 119 77 w
070 56 38 8 170 120 78 x
071 57 39 9 171 121 79 y
072 58 3A : 172 122 7A z
073 59 3B ; 173 123 7B {
074 60 3C < 174 124 7C |
075 61 3D = 175 125 7D }
076 62 3E > 176 126 7E ~
077 63 3F ? 177 127 7F DEL
S
Sami Sihvonen
Gary R. Schmidt said:
Here in Europe ISO 8859-15 is more popular, it's basicly ISO 8859-1
but with added character used to describe euro currency sign... And
the default character set for GNU/Linux distributions is ISO 10646,
also known as Unicode and UTF-8.
D
Darrien
Message-ID: <[email protected]>
"So, it's down to the usual problem, people posting non-7-bit ASCII
messages in a newsgroup!!!"
I never claimed that it wasn't encoded using 7-bit ASCII, only that your
comment "people (refering to me) posting non-7-bit ASCII messages" was
incorrect.
First of all, the message in question was 7-bit ASCII. No one can contest
that. That's already enough to render your statement invalid. Your comment
(as I interpreted it) said that the problems experienced by Henry The Mole
were caused by me posting in non 7-bit ASCII. Which I wasn't.
Secondly, ISO-2022-JP is encoded *using* 7-bit ASCII. If I had posted using
ISO-2022-JP coded text without including an appropriate MIME header, he still
wouldn't have had any problems (providing that his system complied with the
RFCs) because the text would be interpreted no differently than if I had
loosed a chimp at my keyboard and let him bang on it.
[snip]
G
Gary R. Schmidt
Okay, okay, how about this - people posting non-pure 7-bit ASCII, whereDarrien said:
"non-pure" includes HTML, different Character Set selection mappings so
that browsers /may/ attempt to display characters not represented in the
ASCII character set, and so forth.
Cheers,
Gary B-)
D
Darrien
I accept your defeat.
A new argument. So be it.
I disagree, HTML can be written in pure 7-bit ASCII.
I disagree, if the Character Set encodes using 7-bit ASCII, then the only
problems that can arise (as I've outlined in my previous post) are
dependant on the client using the Character Set information correctly.
I suspect that his client *was* using the information correctly by
changing the font to one that can support East Asian characters.
Why bring browsers in?
If the client cannot support display of the characters intended to be
displayed, then the client should not attempt to display them. Which his
client did not do because it was able to display them.
G
Gary R. Schmidt
Darrien wrote:
[SNIP a lot of point avoiding argument about things that are simply not
7-bit ASCII]
Sigh. I should know better by now than to get into such arguments with
people, but when I started in computers some time before IBM released
the IBM-PC onto an unsuspecting world there were only 2 character sets,
ASCII and EBCDIC, and that was that. Encoding Cyrillic characters into
7-bits does not make it ASCII. HTML is not ASCII, particularly in
regard to Usenet. Etcetera.
Data is never independent of how it is interpreted. When I generate a
character with the value of (decimal) 65 and am working in or with
ASCII, I expect to see displayed the uppercase character A, which, for
those who are using variant display tools, is the nominal first
character of the Roman alphabet, used to represent the English languages
(and others, but let's just keep this simple).
.... I'm bored with this sort of banal stupidity, people who have never
read or contributed to a Standard in their lives waffling on, attempting
to change the meanings of well-established terms to suit their own
devices. Bloody PHBs appear all over the place, now!
Cheers,
Gary B-)
[SNIP a lot of point avoiding argument about things that are simply not
7-bit ASCII]
Sigh. I should know better by now than to get into such arguments with
people, but when I started in computers some time before IBM released
the IBM-PC onto an unsuspecting world there were only 2 character sets,
ASCII and EBCDIC, and that was that. Encoding Cyrillic characters into
7-bits does not make it ASCII. HTML is not ASCII, particularly in
regard to Usenet. Etcetera.
Data is never independent of how it is interpreted. When I generate a
character with the value of (decimal) 65 and am working in or with
ASCII, I expect to see displayed the uppercase character A, which, for
those who are using variant display tools, is the nominal first
character of the Roman alphabet, used to represent the English languages
(and others, but let's just keep this simple).
.... I'm bored with this sort of banal stupidity, people who have never
read or contributed to a Standard in their lives waffling on, attempting
to change the meanings of well-established terms to suit their own
devices. Bloody PHBs appear all over the place, now!
Cheers,
Gary B-)
D
Darrien
Your inability to defend your argument is noted and accepted.
G
Gary R. Schmidt
Darrien wrote:
[SNIP]
*plonk*
[SNIP]
*plonk*