Come domanda dell'intervista, di solito viene chiesto solo i bit tecnici di fare uno scambio sul posto di elementi a 8 bit per invertire il loro ordine (indipendentemente da quali caratteri potrebbero effettivamente rappresentare).
Allo stesso tempo, specialmente se stai intervistando una persona relativamente anziana, potresti almeno sperare di sentire alcune domande sulla specifica e sulla forma esatta dell'input. Anche se li rimandi al semplice caso di scambiare semplicemente articoli a 8 bit, sapere se pensano in termini più ampi di quello che potrebbe essere prezioso.
Se hai a che fare con una vasta gamma di input, devi semplicemente pensare in termini di "stack", un po 'come uno stack di rete. Devi costruire il tuo software in un numero di livelli, ognuno dei quali applica un insieme di trasformazioni abbastanza specifico in un ordine specifico. Ciò ti consente di mantenere ogni parte della trasformazione abbastanza semplice da poterla tenere sotto controllo e avere una ragionevole possibilità di soddisfare i suoi requisiti.
Illustrerò una possibilità che ho trovato almeno in qualche modo realizzabile. Sono il primo ad ammettere che potrebbero esserci altri che hanno idee migliori. Almeno per me, questo mi sembra un po 'come l'ingegneria a forza bruta, con poca vera eleganza.
Normalmente si desidera iniziare convertendo qualsiasi altra rappresentazione in UCS-4 (alias UTF-32). Per questo, generalmente preferisce affidarsi all'input dell'utente piuttosto che tentare di capirlo da solo. In alcuni casi, puoi essere sicuro che una particolare sequenza di ottetti non segua le regole di un particolare schema di codifica, ma puoi raramente (se mai) essere sicuro che segua un particolare schema di codifica.
Il prossimo passo è facoltativo. È possibile normalizzare l'input in uno dei quattro moduli di normalizzazione Unicode. In questo caso, probabilmente vorresti applicare la trasformazione "NFKC": decomposizione della compatibilità seguita dalla composizione canonica. Questo (dove possibile) converte combinando forme diacritiche (come l'U + 301 che Jon menziona) in punti di codice singolo (ad esempio, una "A" con un "U + 301" verrebbe convertita in "Capitale latina A con acuto" , U + 00C1).
Passi quindi attraverso tutti i personaggi dall'inizio alla fine, spezzando la stringa in caratteri reali e se ci sono (ancora) combinando segni diacritici, mantenendoli con i caratteri che modificano. Il risultato di ciò sarà in genere un indice dei caratteri effettivi nella stringa, ad esempio la posizione e la lunghezza di ciascuno.
È l'ordine inverso di quei caratteri completi, in genere utilizzando l'indice creato nel passaggio precedente.
Quindi (di nuovo, facoltativamente) si applica un altro processo di normalizzazione Unicode, come NFD (decomposizione canonica). Ciò trasformerà il suddetto "latino A acuto" in due punti di codice: una "capitale latina A" e una "combinazione acuta". Se all'inizio il tuo input contiene un U + 00C1, tuttavia converte anche quello in due code point.
Quindi codifica la sequenza di punti codice UCS-4 nella codifica desiderata (UTF-8, UTF-16, ecc.)
Si noti che i passaggi di normalizzazione Unicode possono / cambieranno il numero di punti di codice necessari per memorizzare la stringa, quindi se li si include, non è più possibile pianificare l'adattamento della stringa di risultati nella memoria originale. Ovviamente, i punti codice risultanti potrebbero non corrispondere direttamente ai punti del codice di input.