ture

Nu är jag trött efter en dag på jobbet så jag kanske är ute och cyklar, men: borde du inte titta på probe[[test length]] i stället för på probe[[test length] + 1]? Det förklarar dock naturligtvis inte varför koden du länkade till råkat ut för samma problem. Den har å andra sidan problemet att den gör antaganden om längden på en UTF-16-sträng vilket verkar riskabelt. Å tredje sidan borde inte surrogatpar dyka upp speciellt ofta...

Finns det någon teckensekvens det alltid blir fel på, eller verkar det slumpmässigt?

Vild idé: Kan det vara så att den genererade strängen termineras med en noll-_byte_, oavsett hur breda tecken den innehåller? Det vore ju en småkul bug i så fall.

Är den verkligen inte nollterminerad? Manualen (http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/doc/uid/20000154-BAJHJHHD) påpekar att datat som returneras från dataUsingEncoding:allowLossyConversion: inte är det, men det säger ju inget om cStringUsingEncoding:. Fast jag har inte testat...

Det här är antagligen inte ett problem med terminalprogrammet utan med skalet (bash). När du trycker ett "ö" genererar terminalprogrammet två bytes (c3, b6 hexadecimalt) med UTF-8-koden för ett ö, och det tolkar bash p.g.a. dumma inställningar som att du tryckt ESC c ESC 6. Det är alltså bash som behöver dresseras, inte terminalprogrammet, och hur man gör det står antagligen redan beskrivet i någon av de där massvis med trådarna, så jag låter bli att skriva det igen.

Det här är en halvvild gissning, men får man inte den effekten om man ställt in Mail.app så att den använder Gmails trash-mapp som papperskorg och att flytta raderade brev till papperskorgen?

Det betyder att F1-tangenten skickar en sekvens av tre bytes, den första med värdet 33 oktalt (27 decimalt) och de andra två med ASCII-värdena för O och P. Det är samma sekvens som skickas av motsvarande tangent på en gammal VT100-terminal, vilket får många Unix-program att känna sig trygga och hemmastadda.