Como uma pergunta de entrevista, geralmente é perguntado sobre os bits técnicos de uma troca no local de itens de 8 bits para reverter sua ordem (independentemente de quais caracteres eles realmente representam).
Ao mesmo tempo, especialmente se você estiver entrevistando uma pessoa relativamente sênior, pode esperar pelo menos ouvir algumas perguntas sobre a especificação e a forma exata da entrada. Mesmo se você direcioná-los de volta ao simples caso de trocar itens de 8 bits, saber se eles pensam ou não em termos mais amplos do que isso pode ser valioso.
Se você precisar lidar com uma ampla variedade de entradas, precisará pensar em termos de uma "pilha", um pouco como uma pilha de rede. Você precisa criar seu software em várias camadas, cada uma das quais aplica um conjunto de transformações bastante específico em uma ordem específica. Isso permite que você mantenha cada parte da transformação simples o suficiente para mantê-la sob controle e tenha uma chance razoável de fazê-la atender aos seus requisitos.
Esboçarei uma possibilidade que achei pelo menos um pouco viável. Eu sou o primeiro a admitir que pode haver outros que têm idéias melhores. Pelo menos para mim, isso parece um pouco com a engenharia de força bruta, com pouca elegância real.
Você normalmente deseja começar convertendo qualquer outra representação para UCS-4 (também conhecido como UTF-32). Para isso, geralmente você prefere confiar nas informações do usuário do que tentar descobrir por conta própria. Em alguns casos, você pode ter certeza de que uma sequência específica de octetos não segue as regras de um esquema de codificação específico, mas raramente (se alguma vez) pode ter certeza de que ela segue um esquema de codificação específico.
O próximo passo é opcional. Você pode normalizar a entrada para um dos quatro formulários de normalização Unicode. Nesse caso, você provavelmente desejaria aplicar a transformação "NFKC": decomposição de compatibilidade seguida por composição canônica. Isso (sempre que possível) converterá formas diacríticas combinadas (como o U + 301 mencionado por Jon) em pontos de código único (por exemplo, um "A" com um "U + 301" seria convertido em "capital latina A com agudo" , U + 00C1).
Você então percorre todos os caracteres do começo ao fim, dividindo a string em caracteres reais - e se houver (ainda) combinando marcas diacríticas, mantendo-os com os caracteres que eles modificam. O resultado disso normalmente será um índice dos caracteres reais da string, como a posição e o comprimento de cada um.
Você inverte a ordem desses caracteres completos, geralmente usando o índice criado na etapa anterior.
Você então (novamente, opcionalmente) aplica outro processo de normalização Unicode, como NFD (decomposição canônica). Isso transformará o mencionado "Latin A com agudo" de volta em dois pontos de código - um "Latim maiúsculo A" e um "combinando Agudos". No entanto, se sua entrada contivesse um U + 00C1, ela também converteria esse em dois pontos de código também.
Em seguida, você codifica a sequência dos pontos de código UCS-4 na codificação desejada (UTF-8, UTF-16, etc.)
Observe que as etapas de normalização Unicode podem / irão alterar o número de pontos de código necessários para armazenar a sequência, portanto, se você incluí-los, não poderá mais planejar o ajuste da sequência de resultados no armazenamento original. Obviamente, os pontos de código resultantes também podem não corresponder diretamente aos pontos de código de entrada.