Sounds to me like your operating system does not have the necessary filesystem-level character set support to unambiguously store this character.

If it were a Perl problem, or a BBEdit problem for that matter, I would expect to see some consistency between how the character is displayed in other applications. The lack of consistency, each app displaying it in a different way, points to the OS and/or the filesystem.

When Emacs says \216, that means the character's value is 216 when expressed in decimal notation. Less says 8E, which is presumably hexadecimal but is not the same value. (8E in hex would be 142 in decimal.) Both programs only display characters this way when they cannot show them in the normal fashion, usually either because they don't know what character set is in use or else because the font used doesn't support that character. (I sometimes get this with foreign characters I didn't install the language support for, or control characters that have no visual representation.)

What this says to me is that BBEdit and Emacs and less and Perl all have different ideas about what character set the file is encoded in, which probably means your operating system doesn't store that information in the filesystem or fails in some other way to fully support it, or something along those lines. You might check to see whether you installed the relevant language support options for your operating system; most OSes treat everything except Latin-1 as optional, and for systems sold in the US the foreign ones are sometimes not installed by default. I haven't messed with this at all with OS X, though. (I've used OS X a little, but I've never installed it.) I'm just sort of guessing the situation may be similar to what it is in MS Windows and Linux Mandrake. If so, there should be an option somewhere in your control panels or someplace (or maybe if you boot from the OS CD) for which features are installed, and you should check there for foreign language support.

The result you're getting after writing the query result to STDOUT is not two bytes, but four, and this obviously indicates that something about the process of doing this is mangling the character. This could either be a result of the same problem, or it could be an additional problem (possibly having to do with the database or who knows what). Solve the first problem first, and then worry about the database mangling if it's still an issue.

If this is a CGI application you're working on, you can take everyting but Perl and CGI out of the equation by always using the encoded form (in the case of your accented e, é) for everything except input from the browser. Encode the entities right away when you get them from the browser, store them in the database that way, retrieve them that way, and leave them that way. This is an ugly workaround, but it will work for many purposes. The only caveat is, you don't want to double-encode information that's been sent out to the browser and back; in theory the browser should always decode the entities, so that shouldn't happen, but just in case you might do a decode first before each encode.

---

$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
[download]