This is something I’ve been meaning to write up for some time - a summary of what the ThisService service-to-script shim (ServiceSkeleton) does about your data.
Nothing.
Well, actually, that’s not fair. It does do something. Services are passed data in NSPasteboard objects, that can carry a bunch of representations of the data to be processed. ThisService 1.0 limits this to receiving and/or returning representations of the NSStringPboardType type - aka string objects.
So strings appear in the input with just the string data - nothing else. ServiceSkeleton has got to encode this somehow and shoots for UTF-8. (As a corollary, scripts are also supposed to return UTF-8 encoded bytes, unless they are AppleScripts which can return string objects directly.) This gives us an NSData object - a bunch of bytes - which is then fed through an NSPipe connected to the NSTask we use for connecting to the script process. (Or, with AppleScript, we are again convering the data to an NSString (which we have to, since we’re in a different method and no longer have access to the original string object for reuse) and populating a list descriptor with the string for dispatch as the handler arguments.)
But aside from encoding in UTF-8, nothing is actually changed when passed through ServiceSkeleton. This includes keeping line endings intact, and this can be the source of some confusion. The simple answer to “Why doesn’t ThisService do anything about fixing my data?” is that “You know best what fixing your data may need, and ThisService diddling with it would only, therefore, stand in the way, and actually likely cause problems down the road.”
This does mean that you’ll have to fiddle with line endings, but in any truly usable scripting language, this isn’t a hindrance. Search for \r\n (CRLF) and replace with \n, and search for \r and replace with \n in that order, and you’ve normalized your data towards the \n line ending which is most useful when working with other UNIX utilities, and which is de facto standard on Macs since Mac OS X.