2009-11-25 6 views
5

Sto provando a valutare diverse strategie per il confronto tra stringhe maiuscole e minuscole UTF-8.Maiuscole/minuscole UTF-8 senza conoscere la lingua

Ho letto del materiale dal consorzio Unicode, ho fatto esperimenti con ICU e ho cercato di proporre varie alternative di qualità di implementazione.

In più occasioni ho visto che i testi differiscono tra Simple Case Mapping e Full Case Mapping e volevo assicurarmi di comprendere completamente la differenza.

Come ho letto, Simple Case Mapping è "context-free", cioè non ha bisogno di sapere quale linguaggio è il carico utile. Ciò darà risultati approssimativi, a causa della debacle turca "I/ı/İ/i".

La mappatura del caso completo, d'altra parte, deve conoscere la lingua del payload per poter eseguire la mappatura. Con queste informazioni extra, può prendere misure speciali per coprire casi in cui "Kim" come una stringa turca dovrebbe diventare "KİM" in maiuscolo, ma "Kim" come una stringa inglese, dovrebbe diventare "KIM" in maiuscolo.

Ho capito bene?

Esistono altri esempi di punti di codice "sfaccettati" che si piegano in modo diverso per lingue diverse?

Grazie!

UPDATE: Una delle fonti che citano il semplice mappatura caso come lingua indipendente è ICU's documentation. L'ho interpretato come verità Unicode, ma forse è solo una dichiarazione dell'implementazione?

risposta

2

No, una "mappatura del caso completo" è un involucro in cui un punto di codice deve essere sostituito da più di un nuovo codice. Una semplice case mapping è una singola sostituzione del punto di codice.

Se si desidera implementare questo da soli, allora il file Unicode CaseFolding.txt è fondamentale per ottenere questo diritto. Notare il codice del campo di stato "T", specificamente lì per gestire il problema Turco I.

+0

Quindi entrambi hanno bisogno del contesto linguistico, giusto? Uso una libreria di terze parti (PCRE) che non utilizza CaseFolding.txt, ma solo le informazioni del caso da UnicodeData.txt e non richiede il contesto linguistico (né esplicitamente né implicitamente, per quanto ne so). Ho pensato che forse era un compromesso valido nel caso Simple. –

+0

Assolutamente. Come indicato nel file, è necessario sapere quando ignorare i record con il codice di stato "T". –

+0

Per quanto posso vedere, il codice di stato T appare in CaseFolding.txt, e non UnicodeData.txt. Ma stai davvero dicendo che la piegatura _correct_ può essere fatta solo con la conoscenza del contesto linguistico? Sto cercando un compromesso che non richieda il contesto e non sia perfetto al 100% ... Ma forse questo è il primo passo verso il riscaldamento? –

2

Bene ... La combinazione di consonanti "SS" scendeva a "ss" per la maggior parte delle lingue occidentali, ma in tedesco potrebbe diventare la lettera speciale "ß". Questo è solo "potrebbe", ci sono abbastanza coinvolti usage rules da considerare.

Penso che questo non influenzi direttamente l'ordine di collazione (tutti i tedeschi sono ovviamente invitati a correggermi), quindi forse è un punto controverso.

+0

Grazie! Ho capito correttamente la differenza tra la mappatura Simple vs. Full? –

+3

Anche se la "ß" maiuscola ti darà "SS", non ho visto nessun framework che faccia l'oposite (in minuscolo ("SS") per ottenere "ß"). Questo perché a volte dovrebbe essere "ss" e l'unico modo per decidere è di avere un dizionario tedesco completo. E a volte anche questo non è abbastanza (ad esempio sia "weiss" che "weiß" sono parole corrette). In effetti, nemmeno un umano può mettere in minuscolo "WEISS" senza contesto (cosa significa). –

+0

@Mihai - grazie, ha senso. Ho avuto la stessa idea, che alzare sarebbe stato molto più facile dell'abbassare. –

Problemi correlati