OK, so after reading a lot of contradicting information I decided to ask. How should document encoding be announced? The W3C validator (or at least links from the same upon a missing encoding) suggests the server should send the encoding in the content-type header. The problem with this that I see is that you can't always make a blanket judgment about what encoding pages will be in. Is it simply suggested to use .htaccess files (or equivalent) for this, then? I am led to believe that most (all?) browsers will ignore a content-type meta tag. Is there another in-file option? An attribute in an xml or html tag? But doesn't a client need to know what encoding a file is before it can parse it?

Secondly, and (in my mind at least) on a related note, what are the exact requirements for a page to be XHTML? I see a lot of talk about using <?xml ?> tags with various attributes, and using an xmlns attribute, and that the <?DOCTYPE > is simply there for validators. Well, even if the <!DOCTYPE > is soley for validators, the W3C validator doesn't complain about my lack of xmlns or anything, so are these actually required?

I'd appreciate any elaboration on these subjects.

XHTML 1.1 must be served with the XML prologue (<?xml version="1.0" encoding="UTF-8" ?>). With this prolog, pages must be served with the application/xml+xhtml MIME type (that's the meta http-equiv="Content-Type"...). Unfortunately, IE (and that's going to include IE7 too) doesn't support serving pages with this MIME type. For IE, you have to use text/html.
So for that reason, it's advisable to serve your pages as XHTML 1.0 which doesn't require the XML prologue. Either that or use a browser sniffing script to serve up different MIME/DOCTYPES.

I know that in order to use <xml> docs you need xhtml to start it up, xml is move server side database stuff then something like css, closely they resemble but both require different attributes and different code to work properly.