That sounds like an aweful idea. Adding s/\0//g might make the program *appear* to work, but would almost certainly add a bug. It would be best to find out why they're there in the first place. For example, if they're present after every other character or so, it because text encoded as UTF-16 or UCS-2 is being treated as the text encoded in another encoding (probably iso-latin-1).
| [reply]
[d/l] |
I use s/\0+//g right now and it seems to work fine. Where do I get those strings? They come on the socket I am listening to. String are generated by a phone switch. NULL characters are always added whenever the date is inserted in a string like in the example bellow:
120507 1324 01300 6417 13639820545 801<CR
+><LF>13:24 12/05<CR><LF>^@^@^@13:24 12/05<CR><LF>^@^@^@120507 1324 00
+456 2867416007 808 14972681971 801<CR><LF>13:24 12
+/05<CR><LF>^@^@^@
I don't see any other places with those characters (not in the data I am capturing, or anywhere else), only when the timestamp is added in string. I guess it is safe to use s/\0+//g in this case, am I right? | [reply]
[d/l] |
I guess so. There's no obvious reason for them to be there. They truly appear to be junk.
| [reply] |