As I stated before, most of the db functions (especially in Query Builder) will escape the data before it's placed in the database, but you can use $this->db->escape() directly when needed. The key point is to prepare the data for wherever you are currently putting it, not for where you think it's going to end up later.
When storing data in the database, focus on what is required to safely store it in the database: validate the data to make sure it is of the right type and within the range to safely store it in the database fields, then escape it and/or use bound queries to help avoid SQL-injection attacks. If your database's encoding doesn't match your form's encoding, you may need to manipulate the data accordingly, but this is the domain of functions like mb_convert_encoding() (before escaping the data/binding it to your queries). If you start using functions which deal with HTML, JavaScript/JSON, etc., then you're not focused on the current task, because somewhere down the line you may find a reason to output the same data in multiple formats, and you shouldn't assume that data in your database is safe for output in any given format.
When sending data to a view, focus on what is required to safely display data in the current view. If your database encoding doesn't match your output encoding, you'll need to convert it again, but even at this point you should be using functions specific to that task, rather than doing it as a side-effect of HTML entity encoding or some similar process.
If the view is HTML, and you're going to manipulate any HTML entities in the data, you're going to want to use htmlentities() or htmlspecialchars() at this point (after the encoding conversion, if necessary), as the browser can easily decode them where appropriate. If you want to normalize the EOL characters, this might be the appropriate time, though the EOL characters in your data are probably never going to matter if your output format is HTML, except maybe as a very inefficient form of compression which could be better handled elsewhere. The last thing you should do before output is use a function like xss_clean() on any character/string or text. The point of doing this last is that any of the previous operations could potentially undo the work done by a function like xss_clean() to protect your output (in cases where it doesn't remove something completely).
If the view (or target output format) is JSON, or some other format, chances are that you will need a completely different set of functions to verify that the data is safe for output.
