in reply to regexing for non-standard characters...
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: regexing for non-standard characters...
by ikegami (Patriarch) on Apr 18, 2010 at 07:24 UTC | |
But then you mention "Windows-1252 character encoding" as a possible alternative to "Unicode coded character set". That would make "Unicode coded character set" some kind of encoding, but a character set is not an encoding. Perhaps you meant "UTF-8 encoding". If you meant "UTF-8 encoding", then you're wrong about everyone assuming the input was encoded using UTF-8. I, for one, made no assumption whatsoever about the encoding of the input. (I did assume that $word contained text, but I stated that assumption.)
Not at all. If you want to deal with text, you have to decode the input. It doesn't matter one bit whether it's encoded using a single-byte fixed-width (e.g. Windows-1252), a multiple-byte fixed-width (e.g. UCS-2le) or a variable-width encoding (e.g. UTF-8, UTF-16le).
That should read: "First, you need to know the encoding of the text file (e.g. UTF-8, Windows-1252, etc)." Most definitely. In order to have text, you need to decode the input, and you can't do that until you know what encoding was used to produce those bytes. | [reply] [d/l] |
by Jim (Curate) on Apr 18, 2010 at 17:37 UTC | |
Google "Unicode coded character set". Read the definition of Coded Character Set in the Unicode Consortium's Glossary of Unicode Terms. I suspect you're familiar with the term "coded character set" and that you're making some point about my usage of it here, but your point eludes me. I think it's correct usage to write "Unicode coded character set." I've read and reread your node and I earnestly don't understand the esoteric points you seem to be making about my phraseology. I especially don't understand your seemingly blantantly incorrect assertion that "Unicode is the only character set understood by Perl…and its regex engine." I've reread my own node and I think it's both correct and potentially helpful to emmiesix, who might be working with Perl on a computer running Microsoft Windows. You probably noticed my intentional use of several em dashes in my node. I'll use the text of my post to demonstrate…well…the sense of my post.
No matter what I did to try to type a UTF-8 em dash into the Windows Command Prompt, it seems it wouldn't let me regardless of the code page setting. (Code page 65001 is UTF-8.) This is some defect of Windows, no doubt. I also don't know why the UTF-8 output appears double-spaced or why m/\x{2014}/ matches but m/\N{U+2014}/ doesn't. Maybe you do. The bottom line—and the point I was making to emmiesix—is that the "weird character" em dash could be one of several different things. What thing it is exactly (i.e., what byte or sequence of bytes) depends on the coded character set (CCS) and the character encoding form (CEF). One has to know if the text is Unicode (CCS) UTF-8 (CEF) or Windows-1252 (both CCS and CEF) or something else. | [reply] [d/l] |
by ikegami (Patriarch) on Apr 18, 2010 at 20:46 UTC | |
Ah ok. So it It means what most people mean by "character set". Adjust to fix accordingly.
You said we all made assumptions about the encoding and/or the character set, but I didn't (I stated $ch needed to be text), rethaew didn't (he assumed $string was text) and graff didn't (he's the only one whose solution dealt with the raw input, and he specifically mentioned how to handle encodings).
Just the encoding. All the decoding functions produce characters in the Unicode character set, so you don't have to worry about any other CCS.
| [reply] [d/l] [select] |