I've recently run into the situation where an html address, including the character ' ~ ', will not be saved or published by the venerable Mozilla 'composer' utility ( still issued with seamonkey as the html editor ).
Instead it pushes out ' %7E ', which my web host Primustel chokes on. Previous host owners ( Magma ) did not choke and enforced the ' ~ ' character in the first place.
I've been editing the pages 'on-line' via a Primus file management utility, in order to keep links clickable.
Why doesn't Mozilla's 'composer' pass the ' ~ ' character into it's html pages, as entered? If it's interchangable with ' %7E ', then why the choking at Primus?
RL
Didn't find your answer? Ask the community — no account required.
G
Glenn
I seems that Mozilla makes a small error - and Primus makes a serious error.
Please look here:
formatting link
Citat: "... The URI syntax has been designed with global transcription as one of its main considerations. A URI is a sequence of characters from a very limited set: the letters of the basic Latin alphabet, digits, and a few special characters. ... Percent-encoded octets (Section 2.1) may be used within a URI to represent characters outside the range of the US-ASCII coded character set if this ...
2.3. Unreserved Characters
Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" ... For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers. ... For example, the octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by "~" without changing its interpretation. ..."
Glenn
L
legg
Turns out that the version of 'composer' issued with Mozilla's Seamonkey is 'improved', in order to cause this problem.
Older versions of 'composer' from previous Mozilla or Netscape distributions will save and publish the ' ~ ' tilde symbol in a link without any problems.
RL
J
JeffM
See "regression", below.
Its *c>Turns out that the version of 'composer'
The regression was noted in a very recent thread. "Seamonkey Composer keeps getting worse"
Composer hasn't seen any development activity in many years. Its developer moved on to NVU and has since abandoned that and started BlueGriffon.
"Kaze" was another developer who picked up the Composer codebase and turned out an improved app / bug fix called KompoZer. There were some talks with the SeaMonkey team about a collaboration, but it appears nothing actually came of that.
A common suggestion you will see repeated is to forgo the "convenience" of the integrated editor and get a **modern** HTML editor with active development. news:ZuadnZN_zoqVHobTnZ2dnUVZ snipped-for-privacy@mozilla.org
R
Rich Grise
If you know your elbow from a hole in the ground, you can edit HTML on notepad.
Have Fun! Rich
J
JeffM
Rich Grise wrote:
...or even using a proper text editor.
The advantage of a WYSIWYG editor is being able to toggle back and forth between Source mode and View mode without *saving* the file. Some find that sort of thing convenient. The Tags mode can also be a useful crutch.
L
legg
The old 'composer' displays the tags placed by the new 'composer' when the mis-edited files are reopened in the (WYSIWYG) 'normal' mode.
RL
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.